they have a lot of advantages over the rest of the software world. They have a single product: one program that flies one spaceship. They understand their software intimately, and they get more familiar with it all the time. The group has one customer, a smart one. And money is not the critical constraint
Not that the methods here don’t have their place, but it seems to me that this is a point by point list of exactly why the methodology used by this team is not used generally.
The average software project may involve many different products and many different programmers, making it difficult for anyone involved to become intimately knowledgeable with the work or for standardized programming practices to be enforced everywhere. There are usually very tight deadline and budget constraints, and the clients may or may not know exactly what they want so specifications are usually impossible to nail down and getting quick user feedback becomes very important.
The software design classes at my university teach Agile software development methods. The main idea is breaking a project down into small iterations, each one implementing a subset of the complete specification. After each iteration, the software can be handed off to testers and clients/users for evaluation, allowing for requirements to change dynamically during the development process. Agile seems to be the exact opposite of what is advocated in this article (invest money and resources at the beginning of the project and have a concrete specification before you write a single line of code).
People are less well understood than physics, so it makes sense that interfaces need to be tested on people at earlier stages of development than a program which is just interacting with non-sentience does, even without getting into the problem of making a product for people who don’t quite know what they want until they’re shown something that isn’t it.
Not that the methods here don’t have their place, but it seems to me that this is a point by point list of exactly why the methodology used by this team is not used generally.
The average software project may involve many different products and many different programmers, making it difficult for anyone involved to become intimately knowledgeable with the work or for standardized programming practices to be enforced everywhere. There are usually very tight deadline and budget constraints, and the clients may or may not know exactly what they want so specifications are usually impossible to nail down and getting quick user feedback becomes very important.
The software design classes at my university teach Agile software development methods. The main idea is breaking a project down into small iterations, each one implementing a subset of the complete specification. After each iteration, the software can be handed off to testers and clients/users for evaluation, allowing for requirements to change dynamically during the development process. Agile seems to be the exact opposite of what is advocated in this article (invest money and resources at the beginning of the project and have a concrete specification before you write a single line of code).
People are less well understood than physics, so it makes sense that interfaces need to be tested on people at earlier stages of development than a program which is just interacting with non-sentience does, even without getting into the problem of making a product for people who don’t quite know what they want until they’re shown something that isn’t it.