3 ms·

The only software project I ever worked on in which the customer didn't report so much as a single bug had the requirements done properly, up front, and agreed

The only software project I ever worked on in which the customer didn't report so much as a single bug had the requirements done properly, up front, and agreed all round. Of the thousands of identified requirements, I think less than ten changed over the lifetime of the project, and each change underwent significant examination for consequences. The project was waterfall all the way. The quality of software that can be built if you know before you start what it's meant to do, and that doesn't change, is astounding. Truly astounding.

temac 7y ago
The funny thing is that most people never even attempt to do that, and then still manage to complain about it being impossible. Yes in some projects that can be harder, but I'm not buying the ambiant: "in most projects". I actually think in that in most projects, a good part of requirement analysis can be put upfront, and of course a tiny bit will still evolve, but not enough to prevent doing things properly. That does not impose to have too long projects, btw. Just cut them in phases and/or pieces. Feedback cycles are important, but this is still an equilibrium, and in some projects I don't see how 2 weeks feedback cycles without proper requirement engineering would be any good. Maybe one problem of software development is that it is an ever growing industry, so the mean programmer is always young and inexperienced. Maybe things will be less impulsive with the eventual end of that growth.
- BlueTemplar 7y ago
  The number of feedback cycles is pretty much what defines waterfall vs agile. And it's hard do do a proper waterfall when you hardly have an idea of how to even approach the problem.
matsemann 7y ago
I have worked on huge government projects that has been specced and planned for years before arriving at my team's desks. It takes a few days before we will have questions. Things not defined good enough, inconsistencies, glaring holes etc. I think having all reqs upfront is a utopia that will not happen. Those projects I was involved in would have been better if the reqs and scope was done in conjunction with us implementing it.
- EliRivers 7y ago
  We had some good requirements people. Really good. They didn't just write things down. There was a lot of examination and analysis and plotting and so on, and they were good at it. They'd all begun their careers as software engineers and gradually specialised into being really good at requirements. I think having all reqs upfront is a utopia that will not happen. What can I say? It happened to me. Only with one company in seven or so worked for so far. I would not be surprised if people worked two dozen jobs and never experienced it. You do need high-quality customers, though, and they are hard to come by. I've worked for a company that has turned down customers on the grounds that the potential customer just isn't good enough; they worded it differently, but that's what it was.
- zo1 7y ago
  The fact that you immediately had questions of the requirements means they were not properly thought out and/or not well-defined (regardless of how many years they spent in the planning/gathering stage). Both of those (well defined, thought-out requirements), along with reasonable people evaluating them, would have yielded a much better outcome overall. Just like spaghetti programming, you get spaghetti requirements analysis & process-engineering. And even then, they hardly consider some of the things that developers do. Almost as if the developers that encode the rules in a "hard format" such as a program/system need to be the ones dictating the processes/requirements. I would definitely see that as separate to "reqs and scope done in conjunction with devs developing them".
jefftk 7y ago
"Take a government contract I worked on years ago. It is undoubtedly the most successful project I’ve ever worked on, at least from the standpoint of the usual project management metrics: it was completed early, it was completed under budget, and it completed a scheduled month-long acceptance test in three days. This project operated under some unusual constraints: the contract was denominated and paid in a foreign currency and was absolutely firm fixed-price, with no change management process in the contract at all. In fact, as part of the contract, the acceptance test was laid out as a series of observable, do-this and this-follows tests that could be checked off, yes or no, with very little room for dispute. Because of the terms of the contract, all the risk of any variation in requirements or in foreign exchange rates were on my company. The process was absolutely, firmly, the classical waterfall, and we proceeded through the steps with confidence, until the final system was completed, delivered, and the acceptance test was, well, accepted. After which I spend another 18 months with the system, modifying it until it actually satisfied the customers needs."

temac 7y ago

The funny thing is that most people never even attempt to do that, and then still manage to complain about it being impossible. Yes in some projects that can be harder, but I'm not buying the ambiant: "in most projects". I actually think in that in most projects, a good part of requirement analysis can be put upfront, and of course a tiny bit will still evolve, but not enough to prevent doing things properly. That does not impose to have too long projects, btw. Just cut them in phases and/or pieces. Feedback cycles are important, but this is still an equilibrium, and in some projects I don't see how 2 weeks feedback cycles without proper requirement engineering would be any good. Maybe one problem of software development is that it is an ever growing industry, so the mean programmer is always young and inexperienced. Maybe things will be less impulsive with the eventual end of that growth.

BlueTemplar 7y ago
The number of feedback cycles is pretty much what defines waterfall vs agile. And it's hard do do a proper waterfall when you hardly have an idea of how to even approach the problem.

matsemann 7y ago

I have worked on huge government projects that has been specced and planned for years before arriving at my team's desks. It takes a few days before we will have questions. Things not defined good enough, inconsistencies, glaring holes etc. I think having all reqs upfront is a utopia that will not happen. Those projects I was involved in would have been better if the reqs and scope was done in conjunction with us implementing it.

EliRivers 7y ago
We had some good requirements people. Really good. They didn't just write things down. There was a lot of examination and analysis and plotting and so on, and they were good at it. They'd all begun their careers as software engineers and gradually specialised into being really good at requirements. I think having all reqs upfront is a utopia that will not happen. What can I say? It happened to me. Only with one company in seven or so worked for so far. I would not be surprised if people worked two dozen jobs and never experienced it. You do need high-quality customers, though, and they are hard to come by. I've worked for a company that has turned down customers on the grounds that the potential customer just isn't good enough; they worded it differently, but that's what it was.
zo1 7y ago
The fact that you immediately had questions of the requirements means they were not properly thought out and/or not well-defined (regardless of how many years they spent in the planning/gathering stage). Both of those (well defined, thought-out requirements), along with reasonable people evaluating them, would have yielded a much better outcome overall. Just like spaghetti programming, you get spaghetti requirements analysis & process-engineering. And even then, they hardly consider some of the things that developers do. Almost as if the developers that encode the rules in a "hard format" such as a program/system need to be the ones dictating the processes/requirements. I would definitely see that as separate to "reqs and scope done in conjunction with devs developing them".

jefftk 7y ago

"Take a government contract I worked on years ago. It is undoubtedly the most successful project I’ve ever worked on, at least from the standpoint of the usual project management metrics: it was completed early, it was completed under budget, and it completed a scheduled month-long acceptance test in three days. This project operated under some unusual constraints: the contract was denominated and paid in a foreign currency and was absolutely firm fixed-price, with no change management process in the contract at all. In fact, as part of the contract, the acceptance test was laid out as a series of observable, do-this and this-follows tests that could be checked off, yes or no, with very little room for dispute. Because of the terms of the contract, all the risk of any variation in requirements or in foreign exchange rates were on my company. The process was absolutely, firmly, the classical waterfall, and we proceeded through the steps with confidence, until the final system was completed, delivered, and the acceptance test was, well, accepted. After which I spend another 18 months with the system, modifying it until it actually satisfied the customers needs."