←back to thread

421 points briankelly | 1 comments | | HN request time: 0s | source
Show context
Quarrelsome ◴[] No.43575443[source]
This is extremely fascinating and finally something that feels extremely tangible as opposed to vibes based ideas around how AI will "take everyone's jobs" while failing to fill in the gaps between. This feels extremely gap filling.

I find it quite interesting how we can do a very large chunk of the work up front in design, in order to automate the rest of the work. Its almost as if waterfall was the better pattern all along, but we just lacked the tools at that time to make it work out.

replies(2): >>43575549 #>>43577333 #
skizm ◴[] No.43575549[source]
Waterfall has always been the best model as long as specs are frozen, which is never the case.
replies(4): >>43575820 #>>43575873 #>>43579828 #>>43580347 #
thisdougb ◴[] No.43575873[source]
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.

replies(1): >>43577158 #
1. PaulDavisThe1st ◴[] No.43577158{3}[source]
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.