5 ms·

Designing a bug free software to meet requirements that are ever-changing is hardly a solved problem. If you specify a system correctly upfront it is indeed po

by seer 7y ago

Designing a bug free software to meet requirements that are ever-changing is hardly a solved problem. If you specify a system correctly upfront it is indeed possible to make something very very reliable. But a big part of building nowadays software is requirement gathering as you build (or worse - deploy it) nobody knows what it should do beforehand, and in a lot of times it is impossible (or very very expensive) to know. The whole thing called XP and agile came out as a way to deal with it. I can still remember the time when devs battled hard to make business people / clients provide requirements up front - the waterfall model. The Apollo program was brought up constantly as a proof that this is the way. And then we went “fuck it its never going to happen, lets design a process that recognizes this and allows for _some_ sanity” What NASA used was the latest iteration of a process that has been in use for hundreds of years, quite well understood. Agile and the like are still in its infancy but I think it has a lot more potential for evolution. And its more recognizing what is that wishful thinking of what could be if human nature was different. And its not like waterfall is banned or anything - you can practice it to your hearts content, for some domains this is even a good idea (implementing protocols comes to mind, financial, medical etc.). We’ll see who goes to market, gathers business intelligence and answers the customer’s needs faster/cheaper/better.

arethuza 7y ago
In the overwhelming majority of projects I have worked on - the challenge was less building the right thing incorrectly but building the wrong thing correctly. As a senior management at one company once told me: "That may be what I asked for, but its not what I want" - which is an extreme view but not untypical in lots of domains.
thraxil 7y ago
It's also important to keep in mind that most of the projects that NASA works on/worked on like Apollo 11 aren't just software projects. They involve massive scales of cutting edge hardware that is developed by independent teams and needs to come together, operate in extreme environments and physical constraints, and all be complete and tested and ready for a relatively narrow launch window. Not to undersell the importance of the software component or the skills and talent of those who developed it, but it's usually only one part of a massive effort. Waterfall with intense requirements gathering and up-front design makes a lot more sense in that context. It's very different than developing software to run on commodity hardware to meet potential needs of a wide range of potential users who may have conflicting needs that they don't even understand themselves. In that case, time to market, extensibility, and the ability to iterate with actual user feedback and production data become much more dominant.

by seer 7y ago

arethuza 7y ago

In the overwhelming majority of projects I have worked on - the challenge was less building the right thing incorrectly but building the wrong thing correctly. As a senior management at one company once told me: "That may be what I asked for, but its not what I want" - which is an extreme view but not untypical in lots of domains.

thraxil 7y ago

It's also important to keep in mind that most of the projects that NASA works on/worked on like Apollo 11 aren't just software projects. They involve massive scales of cutting edge hardware that is developed by independent teams and needs to come together, operate in extreme environments and physical constraints, and all be complete and tested and ready for a relatively narrow launch window. Not to undersell the importance of the software component or the skills and talent of those who developed it, but it's usually only one part of a massive effort. Waterfall with intense requirements gathering and up-front design makes a lot more sense in that context. It's very different than developing software to run on commodity hardware to meet potential needs of a wide range of potential users who may have conflicting needs that they don't even understand themselves. In that case, time to market, extensibility, and the ability to iterate with actual user feedback and production data become much more dominant.