Startup vs Waterfall

I grew up on YCombinator anecdotes about startup life. Teenagers shipping a new shoddy website or MVP every day. An environment that favors Ruby on Rails because it lets you get a CRUD app out the door in less time than it takes to unit test one meaty class.

In my professional life, I’ve worked in big projects with many architects, domain experts obsessing over requirement management, architecture concepts, documentation and so forth. Implementation uses serious languages such as C++ or at least C# with an aspiration for thorough testing at all levels.

These projects often aspire to call themselves “agile”.

But once you have a dedicated requirement manager and a big architecture, you are probably not very agile anymore. A workflow built around requirements, architecture, documentation, and design reviews is much closer to waterfall: think carefully, plan everything, and try to get it right the first time.

The problem with this approach is the iteration time.

A Silicon Valley startup can ship a new insecure PHP prototype every week. Today’s vibe coder can do the same in a day. The Lastenheft-driven developer measures his feature cadence in months-long “SAFe 6” product increments.

“First time right” is an aspiration that the agile world discards. We are never right the first time. I think a better goal is “implement it thrice”. Get some slop out, use it to understand the requirements. If it’s useful, rewrite.

The more you scale and the more utility you get out of a program, the more iterations there are to this process. That’s a feature. How many times was Facebook rewritten?