A common misconception with software architecture and software design is assuming that this is somehow separate from your program and something you create befor

A common misconception with software architecture and software design is assuming that this is somehow separate from your program and something you create before you start programming. In most projects, this is limited to some preliminary scribbling on a whiteboard and some random musings in a wiki or issue tracker. But it used to be that people were very serious about waterfall and wasted lots of time on this. But if you think about it, an architectural drawing for a building is essentially an executable recipe for building a house that the construction team uses to build it. I.e. it's actually very similar to a program. It tells the team of builders all they need to know to build the building. In the software world, the blue prints actually are executable. That's the whole point. The job of programming is essentially just creating a very detailed blueprint in some language. The compiler/interpreter then generates the executable from this blue print. The only difference here is that we replaced the team of construction workers with another program the construction process is automated and does not involve any people. This wasn't always the case, the word compiling refers to people stacking together punch cards in the right order. The first computers were humans flipping switches, doing calculations, and messing around with cables, punch cards and what not. The word debugging refers to removing actual live (or dead) bugs from circuitry. Writing a program used to mean creating a plan to task these people to do all these things. Having a plan for that is kind of crucial. Exactly like having an architecture blue print for a building is important. That's what a program is: a blueprint for creating/generating instructions that a computer can work with. Ada Lovelace, widely recognized as the first programmer, never even had access to a computer. She was designing software for a machine that did not yet exist. But she was a programmer and not an architect. Having a separate program for producing the program just isn't a thing (well except for meta programming of course). Just like having a blue print for a blue print for a bridge or a building is not really a thing. There's just the blueprint. And just like programmers have to do a lot of problem solving while they create their blue prints (programs), architects have to do a lot of problem solving while they are creating their blueprints. It's this problem solving that make their jobs hard and unpredictable. Once you have the blueprint, things get relatively straightforward and predictable. But before that, buildings are just as risky and unpredictable as software programs are. You have to deal with requirements, budgets, regulations, flaky customers, etc. This can get really complicated and risky. That's why large engineering projects run over budget so often. And ironically, agile engineering is actually a thing too now. E.g. SpaceX iterates on their rockets rather than designing them years in advance: real world engineering is learning from software engineering.