Hacker News Reader

We use 'waterfall' (detailed, fleshed out specs in formal language) on the hardware, firmware & backend and 'agile' on the frontend (web/app). So far that served us well and it addresses the difference in developer skills and needs as well. With the danger of generalizing; frontend people are different from backend people who are different from hardware people (in my experience), and this gives all what they enjoy working with.

View on HN

Hardware (and firmware to a lesser degree) almost require waterfall. Moving fast and breaking things doesn't really work well when you have to throw away the physical product you broke as opposed to iterating it to a fixed state.

I can actually see the merit in waterfall for elements of the backend.. though how do you avoid pre-optimisation or even complete wastage building out APIs that end up never being needed?

The two single biggest factors in determining what sort of process you should have are a) cost to ship/deploy and b) cost of mistake.

On one extreme are things that are expensive to change and mistakes cause critical failures and on the other are things that are trivial to change and mistakes are easily mitigated.

Reply on news.ycombinator.com