4 ms·

> How do they write the right stuff? The article claims that it is their process, and although they are certainly extremely thorough, I don't buy it. At the ve

by epr 6y ago

> How do they write the right stuff? The article claims that it is their process, and although they are certainly extremely thorough, I don't buy it. At the very least, they cannot be compared to most developers apples to apples. Why? > NASA and the Lockheed Martin group agree in the most minute detail about everything the new code is supposed to do — and they commit that understanding to paper, with the kind of specificity and precision usually found in blueprints. Nothing in the specs is changed without agreement and understanding from both sides. For most anyone working as a developer, could you even imagine what this would be like? Specs not changing or only changing in very small ways that are documented to the nth degree not only is impossible from a practical standpoint for most fields of software development, but such a different process that it's essentially a completely different field of work. > Most people choose to spend their money at the wrong end of the process > In the modern software environment, 80% of the cost of the software is spent after the software is written the first time I would argue that this is largely the result of: 1. Incompetency as far as specifications go (suits don't know what they want, or what they are asking for) 2. Large changes in the specification (moving target)

justaguyhere 6y ago
I guess it all depends on the type of software that one is writing. If there is a bug in NASA's software, it will cost them tons of money and might put them back months or years in schedule. It makes sense to be extremely careful. Same applies to software used in medical devices, cars etc where lives are at stake. If my todo app has a bug or even goes down a full day, the impact is not severe. I guess it is okay to change specs within reason - if a project is managed well and communication between the parties involved is great, some amount of flexibility in specs can be accomodated in most non-life threatening projects.
chrisfinazzo 6y ago
This seems incredibly short sighted. To wit, the fact that Keller - or whoever is in that role these days - has to certify that the code and the system it runs on will work as expected speaks volumes about how serious this is. If it doesn't, things tend to blow up, which is sure to ruin your day. Also, I would be remiss if I didn't mention Therac-25, a medical device which killed or severely injured several patients. https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25 In these cases, arguing over every change to code seems like the only way they can guarantee with any certainty that it works correctly.
- epr 6y ago
  Your response suggests you misunderstand the point I was making. I completely agree with you that there are certain niches which require extreme precision for safety purposes like that which is being discussed in the article as well as your medical device example. What irritated me about the article is that it was comparing these niche fields which have completely different requirements and incentive structures to the software industry in general as if that was somehow a reasonable thing to do. Suggesting that the software field in general is somehow juvenile while failing to consider the vastly different incentive structures that exist for developers, managers, etc. in most fields, which necessarily have a drastically higher tolerance for error, is patently ridiculous.
  - raisedbyninjas 6y ago
    Eh, the article is in FastCompany. The target audience may not be familiar with common software development practices. They contrasted the shuttle group process with normal processes and pointed out its hefty price tag & why the government prioritizes quality over speed and cost. Aside from an interesting article on the space program and process improvement, it was also useful for Joe CEO that regularly complains that, let's see 1996... Windows 95 gets it's IRQs screwed up every time he adds a printer or sound card, etc. "I paid for this software, why doesn't it work?"
  - chrisfinazzo 6y ago
    While I don't entirely 'pay for my shoes' developing software - mostly client side web stuff - it's a part of what I do and I can understand the frustration that other parts of the field seem to have when looking at situations like this. Namely, we're at a point where agile practices have become so common that nothing is ever 'done' and it is acceptable to ship something with errors, assuming it can and will be patched later. Both Mom & Dad started out as COBOL programmers on punchcards, and I've heard plenty of 'war stories' about how these kinds of situations were far less common because an error meant your program simply didn't run. Unlike say a web browser which will mostly spit back out whatever weird HTML and CSS you feed into it, errors and all. In consumer software, it's not, 'we follow orders or people die' but for people working on this, it probably feels that way if your stuff is used by enough people (iOS) or is critically important (medical billing). If it doesn't do what it says on the tin, people are incredibly unforgiving of even the smallest mistakes.
gdubs 6y ago
I'm largely self-taught in programming, so it wasn't until much later in my career that I really groked the value of foundational Computer Science. One day, I stumbled across this book: http://elementsofprogramming.com http://elementsofprogramming.com ... and it was maybe the first time I understood that you very much can explicitly define the constraints, inputs, outputs, etc, of a program. For something like a NASA shuttle, it makes absolute sense that they would have an insanely granular definition of the domain / limits under which their code must operate. Most of us deal in our day-to-day on top of a mountain of abstraction. But there are absolutely scenarios in which a formal, complete spec, is a life-or-death requirement.
codemac 6y ago
There's great research about zero defect software, and my favorite is a weird grey textbook by Capers Jones called "The Economics of Software Quality" In it you'll find that this level of requirements gathering, blueprint/spec writing and code inspection are actually cheaper in a relatively short time (months, not years). Writing specifications that are extremely detailed ends up giving you all the logical failures ahead of time, and makes typing code more of a spell checking exercise. By having the logical failures before the code ever runs, you get to debug & fix them before any code runs. This ends up being faster & cheaper in total than waiting for users to find bugs. However - I understand that for many companies they actually don't care if users find bugs as time to market is more expensive than the future bug finding. But if you have a product already in the market, and you expect to support it for ~year, you probably can do much more detailed design and avoid so much pain.
WalterBright 6y ago
> Incompetency as far as specifications go Building complex software is a learning process, and you'll find that what was specified wasn't practical, you'll find better ways to do things, etc.

by epr 6y ago

justaguyhere 6y ago

I guess it all depends on the type of software that one is writing. If there is a bug in NASA's software, it will cost them tons of money and might put them back months or years in schedule. It makes sense to be extremely careful. Same applies to software used in medical devices, cars etc where lives are at stake. If my todo app has a bug or even goes down a full day, the impact is not severe. I guess it is okay to change specs within reason - if a project is managed well and communication between the parties involved is great, some amount of flexibility in specs can be accomodated in most non-life threatening projects.

chrisfinazzo 6y ago

This seems incredibly short sighted. To wit, the fact that Keller - or whoever is in that role these days - has to certify that the code and the system it runs on will work as expected speaks volumes about how serious this is. If it doesn't, things tend to blow up, which is sure to ruin your day. Also, I would be remiss if I didn't mention Therac-25, a medical device which killed or severely injured several patients. https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25 In these cases, arguing over every change to code seems like the only way they can guarantee with any certainty that it works correctly.

epr 6y ago
Your response suggests you misunderstand the point I was making. I completely agree with you that there are certain niches which require extreme precision for safety purposes like that which is being discussed in the article as well as your medical device example. What irritated me about the article is that it was comparing these niche fields which have completely different requirements and incentive structures to the software industry in general as if that was somehow a reasonable thing to do. Suggesting that the software field in general is somehow juvenile while failing to consider the vastly different incentive structures that exist for developers, managers, etc. in most fields, which necessarily have a drastically higher tolerance for error, is patently ridiculous.
- raisedbyninjas 6y ago
  Eh, the article is in FastCompany. The target audience may not be familiar with common software development practices. They contrasted the shuttle group process with normal processes and pointed out its hefty price tag & why the government prioritizes quality over speed and cost. Aside from an interesting article on the space program and process improvement, it was also useful for Joe CEO that regularly complains that, let's see 1996... Windows 95 gets it's IRQs screwed up every time he adds a printer or sound card, etc. "I paid for this software, why doesn't it work?"
- chrisfinazzo 6y ago
  While I don't entirely 'pay for my shoes' developing software - mostly client side web stuff - it's a part of what I do and I can understand the frustration that other parts of the field seem to have when looking at situations like this. Namely, we're at a point where agile practices have become so common that nothing is ever 'done' and it is acceptable to ship something with errors, assuming it can and will be patched later. Both Mom & Dad started out as COBOL programmers on punchcards, and I've heard plenty of 'war stories' about how these kinds of situations were far less common because an error meant your program simply didn't run. Unlike say a web browser which will mostly spit back out whatever weird HTML and CSS you feed into it, errors and all. In consumer software, it's not, 'we follow orders or people die' but for people working on this, it probably feels that way if your stuff is used by enough people (iOS) or is critically important (medical billing). If it doesn't do what it says on the tin, people are incredibly unforgiving of even the smallest mistakes.

gdubs 6y ago

I'm largely self-taught in programming, so it wasn't until much later in my career that I really groked the value of foundational Computer Science. One day, I stumbled across this book: http://elementsofprogramming.com http://elementsofprogramming.com ... and it was maybe the first time I understood that you very much can explicitly define the constraints, inputs, outputs, etc, of a program. For something like a NASA shuttle, it makes absolute sense that they would have an insanely granular definition of the domain / limits under which their code must operate. Most of us deal in our day-to-day on top of a mountain of abstraction. But there are absolutely scenarios in which a formal, complete spec, is a life-or-death requirement.

codemac 6y ago

There's great research about zero defect software, and my favorite is a weird grey textbook by Capers Jones called "The Economics of Software Quality" In it you'll find that this level of requirements gathering, blueprint/spec writing and code inspection are actually cheaper in a relatively short time (months, not years). Writing specifications that are extremely detailed ends up giving you all the logical failures ahead of time, and makes typing code more of a spell checking exercise. By having the logical failures before the code ever runs, you get to debug & fix them before any code runs. This ends up being faster & cheaper in total than waiting for users to find bugs. However - I understand that for many companies they actually don't care if users find bugs as time to market is more expensive than the future bug finding. But if you have a product already in the market, and you expect to support it for ~year, you probably can do much more detailed design and avoid so much pain.

WalterBright 6y ago

> Incompetency as far as specifications go Building complex software is a learning process, and you'll find that what was specified wasn't practical, you'll find better ways to do things, etc.