3 ms·

> For example, if you don’t have a comprehensive requirements spec, how can you possibly know whether you have working software? Short answer: iterative protot

> For example, if you don’t have a comprehensive requirements spec, how can you possibly know whether you have working software? Short answer: iterative prototypes. Long answer: I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project. A "comprehensive requirements spec" is and always was a myth. Agile wasn't even the first to say this bit out loud. Software is always developed by a series of iterative prototypes, only sometimes does the process acknowledge this.

Chris_Newton 5y ago
Short answer: iterative prototypes. OK, but then how do you know what each prototype is required to do? It’s true that you might be lucky enough to work on a project where your employer/client/customer is willing to let you make some of the decisions. In that case, you are effectively defining some of the requirements yourself and hoping that your employer/client/customer will be happy with your decisions. That’s a risk you can mutually agree to take, and sometimes it will pay off royally, and sometimes it will end in disaster, and probably most of the time it will end somewhere in between. However, in my experience, the more important the software you’re building is, the less likely it is that you will have that kind of flexibility for the developers. At the extreme end of the industry, if you’re building something like the control system for medical equipment that will kill the patient if it goes wrong or a billion dollar satellite that you get one shot at launching, you probably aren’t going to be doing it through informal discussions with a “product owner” and relying on TDD to make sure everything is working (where “working” in that case is really a euphemism for “whatever test conditions an individual developer felt might matter”). I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project. Of course, but every time the requirements change, you still need to identify what the change is so you can change your implementation accordingly. There are many ways you can address that problem, some of which involve one big requirements spec document and some of which don’t, but if you don’t end up with some clear and well-maintained spec each time, you don’t know what you’re trying to build and you have no meaningful definition of “working software”.
- marcus_holmes 5y ago
  > OK, but then how do you know what each prototype is required to do? You define an area of exploration for each prototype. Like "we think that the hard part of this problem is getting the encryption right, so we're going to explore that in this prototype". And I thought SpaceX disproved this whole waterfall approach to rocket science? They have used iterative prototypes to build better rockets considerably faster than the waterfall approach used by the rest of the industry.
  - Chris_Newton 5y ago
    I think perhaps you are reading a meaning into my comments that is not intended. At no point have I argued, nor would I ever argue, for some waterfall-based approach and magical everything-fully-known-up-front documentation. My argument is that whatever stage you’re at in your development process, if you don’t have clear requirements, you don’t know what you’re trying to build and you have no way to define whether your software is working or not. The comparison from the Agile Manifesto makes little sense, because having comprehensive documentation of your requirements and acceptance criteria is a prerequisite for even being able to define the working software that the Manifesto says is more valuable. Of course you might do all kinds of prototypes and proofs-of-concept to help you explore the problem space and clarify the requirements in the early stages of your project, and maybe again later if there are significant changes. But this work isn’t about building working software, because you don’t know what that means yet; it’s about doing experiments to help you find out.
    - marcus_holmes 5y ago
      yeah but if your "comprehensive spec" is neither comprehensive or even accurate, how is your software working any better? If "working" means "what the spec says" instead of "what the customer/stakeholder wanted" then your "working" software isn't working. Providing the customer with a working prototype to criticise often (always) allows them to refine their vision of what they wanted and helps them communicate what they need. It's always easier to criticise something than create - saying "the interaction around X doesn't feel right, can we make it cornflower blue?" is a lot easier than "the X interaction must be three shades of grey off cornflower blue" in a spec document. That's been my experience, anyway. Insisting on a comprehensive spec at the start has always been more effort than its worth, because no-one knows what they actually want at the start.
gilbetron 5y ago
The waterfall method (which is what is being invoked when "comprehensive requirements spec" is stated) was, and is, always a fictional story told by people both during and after the project. The entire difficulty of a software project lies in figuring out what needs to be done. Well that and fighting with the tools and modules ;)
- Jtsummers 5y ago
  I’ve said it before, and I’ll probably say it again, it’s not a fiction. I’ve watched millions of dollars get wasted by that approach. It’s a great way to deliver nothing on time unless you know the domain well and your customer really knows what they want. But it is, sadly, quite real.
  - gilbetron 5y ago
    Oh it's real, I agree. What I meant by "fiction" is that the success of waterfall, and the specifics of how waterfall are implemented, is fictional. As in during the "delivery phase", it is found that requirements were missed and so people will retroactively act as if those requirements were actually in the "requirements phase" all along. I did a lot of government contract work and saw the insanity in action. Lots of retroactive changing of gantt charts, too :)
- Chris_Newton 5y ago
  To be clear, having a comprehensive requirements spec has nothing to do with using a waterfall model, and I absolutely was not invoking that model when I used the term. The point is that at any given point in time, either you know what you are currently trying to build or you don’t, and you can only meaningfully define whether your software is working to the extent that you do.
DrJokepu 5y ago
Also, you know, specs can and have bugs. You can have the most comprehensive requirements and specification and a 100% correct implementation of the spec and still end up with software that just doesn’t work, because the spec and the requirements had incorrect assumptions, or worse, had internal contradictions baked into them. Happens all the time. Best to just accept it as inevitable and design the process so that it can cope with it.

Chris_Newton 5y ago

Short answer: iterative prototypes. OK, but then how do you know what each prototype is required to do? It’s true that you might be lucky enough to work on a project where your employer/client/customer is willing to let you make some of the decisions. In that case, you are effectively defining some of the requirements yourself and hoping that your employer/client/customer will be happy with your decisions. That’s a risk you can mutually agree to take, and sometimes it will pay off royally, and sometimes it will end in disaster, and probably most of the time it will end somewhere in between. However, in my experience, the more important the software you’re building is, the less likely it is that you will have that kind of flexibility for the developers. At the extreme end of the industry, if you’re building something like the control system for medical equipment that will kill the patient if it goes wrong or a billion dollar satellite that you get one shot at launching, you probably aren’t going to be doing it through informal discussions with a “product owner” and relying on TDD to make sure everything is working (where “working” in that case is really a euphemism for “whatever test conditions an individual developer felt might matter”). I have yet to see a single project in all my decades of experience in this industry where the requirements didn't change during the project. Of course, but every time the requirements change, you still need to identify what the change is so you can change your implementation accordingly. There are many ways you can address that problem, some of which involve one big requirements spec document and some of which don’t, but if you don’t end up with some clear and well-maintained spec each time, you don’t know what you’re trying to build and you have no meaningful definition of “working software”.

marcus_holmes 5y ago
> OK, but then how do you know what each prototype is required to do? You define an area of exploration for each prototype. Like "we think that the hard part of this problem is getting the encryption right, so we're going to explore that in this prototype". And I thought SpaceX disproved this whole waterfall approach to rocket science? They have used iterative prototypes to build better rockets considerably faster than the waterfall approach used by the rest of the industry.
- Chris_Newton 5y ago
  I think perhaps you are reading a meaning into my comments that is not intended. At no point have I argued, nor would I ever argue, for some waterfall-based approach and magical everything-fully-known-up-front documentation. My argument is that whatever stage you’re at in your development process, if you don’t have clear requirements, you don’t know what you’re trying to build and you have no way to define whether your software is working or not. The comparison from the Agile Manifesto makes little sense, because having comprehensive documentation of your requirements and acceptance criteria is a prerequisite for even being able to define the working software that the Manifesto says is more valuable. Of course you might do all kinds of prototypes and proofs-of-concept to help you explore the problem space and clarify the requirements in the early stages of your project, and maybe again later if there are significant changes. But this work isn’t about building working software, because you don’t know what that means yet; it’s about doing experiments to help you find out.
  - marcus_holmes 5y ago
    yeah but if your "comprehensive spec" is neither comprehensive or even accurate, how is your software working any better? If "working" means "what the spec says" instead of "what the customer/stakeholder wanted" then your "working" software isn't working. Providing the customer with a working prototype to criticise often (always) allows them to refine their vision of what they wanted and helps them communicate what they need. It's always easier to criticise something than create - saying "the interaction around X doesn't feel right, can we make it cornflower blue?" is a lot easier than "the X interaction must be three shades of grey off cornflower blue" in a spec document. That's been my experience, anyway. Insisting on a comprehensive spec at the start has always been more effort than its worth, because no-one knows what they actually want at the start.

gilbetron 5y ago

The waterfall method (which is what is being invoked when "comprehensive requirements spec" is stated) was, and is, always a fictional story told by people both during and after the project. The entire difficulty of a software project lies in figuring out what needs to be done. Well that and fighting with the tools and modules ;)

Jtsummers 5y ago
I’ve said it before, and I’ll probably say it again, it’s not a fiction. I’ve watched millions of dollars get wasted by that approach. It’s a great way to deliver nothing on time unless you know the domain well and your customer really knows what they want. But it is, sadly, quite real.
- gilbetron 5y ago
  Oh it's real, I agree. What I meant by "fiction" is that the success of waterfall, and the specifics of how waterfall are implemented, is fictional. As in during the "delivery phase", it is found that requirements were missed and so people will retroactively act as if those requirements were actually in the "requirements phase" all along. I did a lot of government contract work and saw the insanity in action. Lots of retroactive changing of gantt charts, too :)
Chris_Newton 5y ago
To be clear, having a comprehensive requirements spec has nothing to do with using a waterfall model, and I absolutely was not invoking that model when I used the term. The point is that at any given point in time, either you know what you are currently trying to build or you don’t, and you can only meaningfully define whether your software is working to the extent that you do.

DrJokepu 5y ago

Also, you know, specs can and have bugs. You can have the most comprehensive requirements and specification and a 100% correct implementation of the spec and still end up with software that just doesn’t work, because the spec and the requirements had incorrect assumptions, or worse, had internal contradictions baked into them. Happens all the time. Best to just accept it as inevitable and design the process so that it can cope with it.