5 ms·
I think part of the problem is that Software Architect is a bad term. An Architect makes a blueprint. That blueprint can be given to many different builders who
by learc83 11y ago
I think part of the problem is that Software Architect is a bad term. An Architect makes a blueprint. That blueprint can be given to many different builders who can then all construct basically the same building.
If you tried to build equivalently detailed software blueprints, you end up just coding the whole thing. The problem is, the software is the blueprint.
Casey Muratori summed it up best in a handmade hero episode. He thinks that a better analogy for software architect is an urban planner. I think that if you approach your design phase more like urban planning, you'll accomplish most of what the article author is going for.
- protomyth 11y agoWasn't Microsoft's M supposed to act much like a blueprint?
- learc83 11y agoFrom what I've heard of it, that was their plan, but these types of projects always run into the same issue. If you build a high level system powerful enough to generate code that can solve general problems, the high level system eventually becomes a general purpose programming language itself.
- kyllo 11y agoThe title of Architect only makes sense in enterprise Java or .NET OOP software projects where the architect's work product is UML diagrams and dataflow diagrams, and the implementation of the classes is delegated to a large number of developers. I think that whole paradigm is a bad idea, but I also think that if you've already decided you're going to use one of those languages and run your project that way, it does make sense to have a person responsible for the high-level system design.
- learc83 11y agoI agree, but my point is that I think those UML diagrams are much more analogous to the work products of urban planners than architects. Actually trying to live up to the title of architect and including blueprint level detail into those high level diagrams is asking for trouble.
- arethuza 11y ago"architect's work product is UML diagrams and dataflow diagrams" IMHO this is one of the worst ever ideas in software development - largely as if you never actually get your hands dirty with real code and the whole messy business of getting it developed, deployed and actually used you never actually see what actually works and what doesn't.
- saint-loup 11y agoInterestingly, in french enterprise IT, "urbanization" means an even more abstract layer of information system design: their evolution and lifecycle (https://fr.wikipedia.org/wiki/Urbanisation_%28informatique%29 https://fr.wikipedia.org/wiki/Urbanisation_%28informatique%2...).
- bottled_poe 11y agoThe thing about architects is they often aren't bound by engineering realities. Let's take your analogy a little further... A builder could construct a small house, and they wouldn't be described as an architect. But if you want to build a skyscraper, you would hire a team of architects, engineering specialists, etc. The point is, the larger the project, the more important it is to invest in the right expertise at the beginning. The problem we have in software engineering is that successful projects almost never start from a position of major financial backing. Instead, the usual process is, start lean and cheap, hopefully gain traction, grow the product, get the investment, hire the talent. Honestly, I think it's a miracle if these types of projects are ever recovered.