When I first started in dev, on a Unix OS, we did 'waterfall' (though we just called it releasing software, thirty years ago). We did a a major release every year, minor releases every three months, and patches as and when. All this software was sent to customers on mag tapes, by courier. Minor releases were generally new features.
Definitely times were different back then. But we did release software often, and it tended to be better quality than now (because we couldn't just fix-forward). I've been in plenty of Agile companies whose software moves slower than the old days. Too much haste, not enough speed.
The difference between agile and waterfall only really matters at the start of a project. Once it is deployed/released/in-use, the two approaches converge, more or less.
sure, but if you're generating the code in a very small amount of time from the specs then suddenly its no longer the code that is the source, its the specs.
That's what waterfall always wanted to be and it failed because writing the code usually took a lot longer than writing the specs, but now perhaps, that is no longer the case.
When I first started in dev, on a Unix OS, we did 'waterfall' (though we just called it releasing software, thirty years ago). We did a a major release every year, minor releases every three months, and patches as and when. All this software was sent to customers on mag tapes, by courier. Minor releases were generally new features.
Definitely times were different back then. But we did release software often, and it tended to be better quality than now (because we couldn't just fix-forward). I've been in plenty of Agile companies whose software moves slower than the old days. Too much haste, not enough speed.
Specs were never frozen with waterfall.
The difference between agile and waterfall only really matters at the start of a project. Once it is deployed/released/in-use, the two approaches converge, more or less.
sure, but if you're generating the code in a very small amount of time from the specs then suddenly its no longer the code that is the source, its the specs.
That's what waterfall always wanted to be and it failed because writing the code usually took a lot longer than writing the specs, but now perhaps, that is no longer the case.
Specs aren't done until the product is retired, thus, code ain't done either.
Only if you don't learn anything while developing. Which is also never the case.
Many companies now engage in serial waterfalling.