| ▲ | Jtsummers 2 hours ago | |
> There are two main schools of thought in software development about how to build really big, complicated stuff. > The most prevalent one, these days, is that you gradually evolve the complexity over time. You start small and keep adding to it. > The other school is that you lay out a huge specification that would fully work through all of the complexity in advance, then build it. I doubt many people (if they stop to think about it) actually fit into either of these two schools of thought, they're both extremist positions. It's like claiming that the US population is filled with people believing in either big government autocracy and communism or small government libertarianism and free markets. That's an absurd position to take, just as these opening paragraphs are absurd. The most generous interpretation is that the author is setting up a strawman. These are extremist positions. No one except a fool would think that they can design a truly large system from scratch before ever writing a piece of code, and no one but a fool thinks they can write the code for a large system without ever thinking about the design. The reality is that it sits in between, the author figures this out by the end, fortunately, but wants something they can't have: > There should be some balanced path in the middle somewhere, but I haven’t stumbled across a formal version of it after all these decades. First, they at least admit that they're stumbling. That's good, groping around in the dark is not an effective way to find an answer, turn on the lights. You aren't the only one thinking about this subject. Second, for small projects and simple projects, or rehashes of projects you've done before, the approach often doesn't matter. This only matters for large, complex, and/or novel projects. Software development is a design process. Again, in case this was missed: Software development is a design process. The idea of separating design from development is foolish (BDUF). The idea of separating development from design is equally foolish (extreme take on Agile, see Ron Jeffries failing at sudoku because he tries to use a development technique, TDD, without thinking about the design). Take the "over 3000 active systems" from paragraph 4. There is no way anyone could have designed all 3000 active systems (either as the 3k systems or in a compressed form) from scratch in a reasonable amount of time. The only reason the author can think of a better design is because they have a design, even if it's not formally documented. The existing software is the design [0] that they can draw from to come up with the better design. But wait, the foolish BDUF people would not try to refine the system, they'd try and build a new system from scratch. Don't be a fool. The foolish extreme Agile people would not look at the whole (or a large enough section) and think about refining it, they'd just add to it or change the existing systems. The sensible person says, "Wait, I acn' | ||