Page 12 of 12

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

Posted: November 23rd, 2018, 3:07 pm
by Cuchulainn
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'.

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

Posted: January 12th, 2020, 3:10 pm
by Cuchulainn
Image

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

Posted: May 25th, 2020, 6:25 am
by Cuchulainn
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,

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

Posted: May 25th, 2020, 3:24 pm
by bearish
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.”

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

Posted: May 25th, 2020, 5:56 pm
by Cuchulainn
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. 

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

Posted: May 25th, 2020, 6:24 pm
by Cuchulainn
Manager's nightmare (but you know it makes sense, unless you have money to burn).

Image

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

Posted: May 25th, 2020, 6:29 pm
by Cuchulainn
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.

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

Posted: May 25th, 2020, 9:23 pm
by bearish
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?

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

Posted: May 26th, 2020, 10:36 am
by Cuchulainn
Like Brooks said, throw away the first prototype. That's what Imperial did with their code, 13 years too late.

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

Posted: May 26th, 2020, 12:55 pm
by Cuchulainn
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.

Image

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

Posted: May 26th, 2020, 1:13 pm
by Cuchulainn
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.

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

Posted: May 27th, 2020, 7:52 am
by Cuchulainn
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[$].

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

Posted: June 11th, 2020, 11:07 am
by Cuchulainn
“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.”

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

Posted: June 18th, 2020, 8:57 am
by Cuchulainn
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

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

Posted: June 30th, 2020, 8:15 pm
by Cuchulainn
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.