How many software developers use these quality metrics as drivers of their software projects?
https://iso25000.com/index.php/en/iso-2 ... /iso-25010
These affect the 'bottom line'.
That's not even wrong what you are saying. But if you are serious, then God help us all.To further quote the authors: “People build BIG BALLS OF MUD because they work. In many domains, they are the only things that have been shown to work. Indeed, they work where loftier approaches have yet to demonstrate that they can compete.”
I was just quoting verbatim from page 35 of the big ball of mud paper, adding no personal opinion. That being said, I’ve been involved in this sort of stuff since the early 90’s (albeit mostly from the quant end of things) and have observed that the most “successful” systems usually have ball of mud characteristics. They just don’t stay successful forever and tend to be replaced in crisis mode. The first attempt at replacement usually fails, followed by involuntary staff turnover. Which leads to some kind of Shakespearean question: is it better to have had a successful system that crashed than to never have had a successful system at all?That's not even wrong what you are saying. But if you are serious, then God help us all.To further quote the authors: “People build BIG BALLS OF MUD because they work. In many domains, they are the only things that have been shown to work. Indeed, they work where loftier approaches have yet to demonstrate that they can compete.”
Balls of mud are caused by indiscipline and inexperience.
You probably never had to maintain large libraries. BTW I worked on one of the first Risk systems in 1992 (C++). It wasn't a ball, it was a jungle.
In fairness, software 'engineering' is not real engineering.
The Ferguson code was a 15 KLOC dung hill. Seems that Microsoft recycled it to 11 smaller, more dedicated globules.
Forget Shakespeare; he knew twat about computers.I was just quoting verbatim from page 35 of the big ball of mud paper, adding no personal opinion. That being said, I’ve been involved in this sort of stuff since the early 90’s (albeit mostly from the quant end of things) and have observed that the most “successful” systems usually have ball of mud characteristics. They just don’t stay successful forever and tend to be replaced in crisis mode. The first attempt at replacement usually fails, followed by involuntary staff turnover. Which leads to some kind of Shakespearean question: is it better to have had a successful system that crashed than to never have had a successful system at all?That's not even wrong what you are saying. But if you are serious, then God help us all.To further quote the authors: “People build BIG BALLS OF MUD because they work. In many domains, they are the only things that have been shown to work. Indeed, they work where loftier approaches have yet to demonstrate that they can compete.”
Balls of mud are caused by indiscipline and inexperience.
You probably never had to maintain large libraries. BTW I worked on one of the first Risk systems in 1992 (C++). It wasn't a ball, it was a jungle.
In fairness, software 'engineering' is not real engineering.
The Ferguson code was a 15 KLOC dung hill. Seems that Microsoft recycled it to 11 smaller, more dedicated globules.