SERVING THE QUANTITATIVE FINANCE COMMUNITY

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

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'.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Here is a quote with which I disagree completely. It is very, very bad:

"I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate."

In fact, answering this question show that you can break a problem into independent subproblems and that you create language-independent model;s before jumping into coding marathons.

This would never happen more mature software development. It leads to

“A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.”

Anecdotal evidence suggests that computer scientists and PhD mathematicians have great difficulty with divide and conquer techniques,
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

bearish
Posts: 5791
Joined: February 3rd, 2011, 2:19 pm

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

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.”

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

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.”
That's not even wrong what you are saying.  But if you are serious, then God help us all.
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.
Last edited by Cuchulainn on May 25th, 2020, 6:35 pm, edited 1 time in total.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Manager's nightmare (but you know it makes sense, unless you have money to burn).

Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Even Aristotle knew what decomposition was

https://en.wikipedia.org/wiki/Functional_decomposition

It will never catch on, it became lost in action in the 1990s.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

bearish
Posts: 5791
Joined: February 3rd, 2011, 2:19 pm

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

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.”
That's not even wrong what you are saying.  But if you are serious, then God help us all.
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.
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?

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Like Brooks said, throw away the first prototype. That's what Imperial did with their code, 13 years too late.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

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.”
That's not even wrong what you are saying.  But if you are serious, then God help us all.
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.
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?
Forget Shakespeare; he knew twat about computers.
It depends how you define 'successful'; 3 times over budget, 5 years too late and satisfying 30% of the requirements is quite common. Most of my projects back then were fixed price. So I had to become a good requirements analyst and become savvy at project estimation (I used PERT with the triangular distribution. Client did not pay project overruns $\ne$ consultancy.

Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

A while back a customer (manufacturer of large printers) converted muddy C code to C++ using modern design. 80% of code could be removed and the new code was very flexible.

Balls of mud tend to become  brittle and ossified unless you give them water every day. To this end, you need hordes of maintenance programmers, help desk folk etc.

Change control management of mud balls is a nightmare.

A common misconception is that having a PhD in applied maths is a guarantee of being a good designer/programmer.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Law of Software Gravity #1

There is no time to get a software project right first time but all the time in the world after that.

Footnotes
1. Even big mudball projects can be salvaged if we agree on commandment #1.
2. Throw out the gold plating features and erroneous assumptions that caused project failure in the first place.
3. New $project estimate[n] = 3 * project estimate[n-1]$ for $n \ge 1$, in any case for $n = 1$.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

“The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers.”
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Why do (quite a few) applied mathematicians and epidemiologists hate to programs and if they do they create balls of mud?

You shake my nerves and you rattle my brain
Too much C code drives a man insane
You broke my will, but what a thrill
Goodness gracious, great balls of mud

I cut my nails and I quiver my thumb
I'm real nervous 'cause it sure is fun
Come on baba, you drive me crazy
Goodness gracious great balls of mud
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl

Cuchulainn
Posts: 62892
Joined: July 16th, 2004, 7:38 am
Location: Amsterdam
Contact:

### Re: Grammar-Pattern Programmers: Is Over-Abstraction Delivering Projects Faster Or Slower?

Cargo cult programming is a style of computer programming characterized by the ritual inclusion of code or program structures that serve no real purpose. Cargo cult programming is symptomatic of a programmer not understanding either a bug they were attempting to solve or the apparent solution (compare shotgun debugging, deep magic).[1] The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some program code from one place to another with little understanding of how it works or whether it is required.

Cargo cult programming can also refer to the practice of applying a design pattern or coding style blindly without understanding the reasons behind that design principle. Examples being adding unnecessary comments to self-explanatory code, overzealous adherence to the conventions of a programming paradigm, or adding deletion code for objects that garbage collection automatically collect.
Step over the gap, not into it. Watch the space between platform and train.
http://www.datasimfinancial.com
http://www.datasim.nl