A couple of observations. First, we tend to push to maximize potential output. That means demanding more than could actually ever be done. I've come to the conclusion that if you're writing code that meets all requirements, on time and under budget, you're simply not ambitious enough. Pristine, perfect code is a sign of customer laziness.
The software we create today is tremendously more complex than the software we created back when I started in the 1990s. Part of that is standing on the shoulders of giants (and the libraries of giants), but part of that is also process.
The amount of process required for clear, effective communication increases with the number of parties involved. Creating good interfaces between components and the teams responsible for them is really a very difficult problem. If you're working on a three person team, it's easy. If there are 30, it's much harder. If it's 100, you probably can't even know every single person involved, much less avoid stepping on each other, not without a lot of process.
So what process does is increase the potential scope of a problem above what a small team can do (mostly by breaking it down into several interacting subprojects). That's difficult, important work, even if it's outside the realm of the average HN startup's imaginations and experience.
The software we create today is tremendously more complex than the software we created back when I started in the 1990s. Part of that is standing on the shoulders of giants (and the libraries of giants), but part of that is also process.
The amount of process required for clear, effective communication increases with the number of parties involved. Creating good interfaces between components and the teams responsible for them is really a very difficult problem. If you're working on a three person team, it's easy. If there are 30, it's much harder. If it's 100, you probably can't even know every single person involved, much less avoid stepping on each other, not without a lot of process.
So what process does is increase the potential scope of a problem above what a small team can do (mostly by breaking it down into several interacting subprojects). That's difficult, important work, even if it's outside the realm of the average HN startup's imaginations and experience.