Programmers who want to change how we code before catastrophe strikes

Post by burntsushi » Thu, Sep 28, 2017, 11:24 AM UTC

shubb wrote: post #219

skgoa wrote: post #216

Earlier quoted context omitted.

I almost always write the major steps as comments (beginning with 'TODO:') first and then do the implementation once I'm satisfied that I know what a good solution looks like. Over the years I have had the misfortune to discover way too many functions that just were 50% implemented or simply did something that was not at all what they were supposed to do. I don't doubt that conscientious developers can arrive at good…

That's more like the carpenter drawing marks in the wood to tell him where to cut. I feel like, complexity is a problem when there is more software than one person could write. At this point, you probably need to do some Business Analyst type stuff. For instance, we are aware of race conditions in code, and maybe we can avoid them by writing purely functional programmes in rust or whatever people do these days. But w…

Post by mac01021 » Thu, Sep 28, 2017, 11:34 AM UTC

amag wrote: post #152

valuearb wrote: post #104

"For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” I almost always dive in, but I almost always write my code twice. Essentially the first round…

Me too. The very few design specs I've seen during my 15+ yrs as a programmer are typically high-level enough to be the mechanical equivalent of "cogs needed here, and springs!". What kind of cogs, e.g. diameter, teeth count, diameter of the center hole (should the hole even be in the center?) and what kind of springs are never mentioned. If you ask the customer about functionality their response is "we want it to wo…

Post by mac01021 » Thu, Sep 28, 2017, 11:45 AM UTC

HumanDrivenDev wrote: post #203

A lot of it comes down to the fact that this isn't engineering, and we aren't engineers.[0] The field has a very low barrier to entry (much lower than a bachelors degree). The standards are low, the expectations are low, and there's a strong anti-intellectualism streak. Don't believe me? try talking about "esoteric" stuff like category theory, logic programming, LISP or writing functional specs. At the workplace most…

Post by cup-of-tea » Thu, Sep 28, 2017, 12:19 PM UTC

Latty wrote: post #107

valuearb wrote: post #104

"For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” I almost always dive in, but I almost always write my code twice. Essentially the first round…

Exactly. This is ignoring the fact that code is a more useful blueprint than anything else for programs. I'm sure if architects had the ability to magically conjure building materials out of thin air and try things in real life for free, architecture would involve a lot more trying and a lot less planning. Of course, I'm sure the article is talking about people just rushing into production code without thought, and I…

Post by arjie » Thu, Sep 28, 2017, 12:34 PM UTC

HumanDrivenDev wrote: post #203

A lot of it comes down to the fact that this isn't engineering, and we aren't engineers.[0] The field has a very low barrier to entry (much lower than a bachelors degree). The standards are low, the expectations are low, and there's a strong anti-intellectualism streak. Don't believe me? try talking about "esoteric" stuff like category theory, logic programming, LISP or writing functional specs. At the workplace most…