January 23, 2007
Architecture vs. ArchitectsOver the last few years, I've become increasingly cynical about software architecture as a doing word. As a "thing" - a characteristic of software and systems - I have no problem with it. Of course anything that has a deliberate - or even unintentional - structure has an "architecture". But when teams talk about hiring someone to "do the software architecture", I get nervous.
The problem starts with the artificial distinctions teams tend to draw between architecture, design and implementation. This drawing of the lines seems to have been spurred on by the industry and by academics who have, for reasons we'll go into in a moment, chosen to elevate the status of the software architect above people who "only do design" and people who "only write code". This research paper, for example, is an admirable attempt to try and persuade us that architecture and design are not the same thing.
The choice of language surrounding contemporary software architecture seeks to elevate it above other concerns. It is the "high level", "big picture", "enterprise" views of systems. Like generals, architects don't concern themselves with the nitty gritty details of individual scuffles and skirmishes. Their time is far too valuable. The expertise that an architect brings to a project or organisation is far too precious to waste on trifling details like class interfaces and choices of algorithms.
This is, of course, a load of old bollocks, and for two good reasons:
1. Most architects I've met have been qualified by age and length of experience and know little if any more about software and system design than the rest of us
2. Most architects I've met have been absolutely obsessed with the little details, to the point where they might as well be writing the code themselves
I'll concede that it is true that many software projects can go pear-shaped because of bad design. Despite what you've been told, that's not confined to Agile projects, either. Plenty of Big Design Up Front projects screw their architecture up, too, as they fall into the trap of forgetting that, no matter how much design we do at the start, 80% of the design decisions will be made after the first release of the system. And I've seen companies call in the architecture big guns to fix these problems. And I've never seen it work.
The only time I've seen projects end up with well-designed code is on those very rare occasions when every developer working on the software had a good grasp of software design principles. That to me suggests very strongly that architecture is every bit an implementation concern as whether to use a stack or a queue or whether to use a for loop or a while loop.
To me, it's an inescapable reality. It doesn't matter how much planning and up-front design we try to do, the ultimate software architecture will emerge out of a massive number of tiny, alledgedly "insignificant" design and implementation decisions made by people who are apparantly not qualified to make them. The fix is not to get in a big picture guy, as my long experience has taught me - and I've been that guy often enough to know how it looks from both sides. The fix is to educate every developer working on the software so he or she can make better design decisions as and when they need to be made.
Only the people writing the code are in a position to deal with an emerging architecture, and the key to scaling this up is not to build an ivory tower and fill it with high priests of architecture, but to get everybody working on code to think more like an architect.
This has been a primary focus of my consulting activities for the last few years. I help teams become better designers by coaching them in design principles, design quality measurement and feedback-driven design practices like test-driven development and refactoring. Whereas in 2001 I would have been invited in to make important design decisions on a project at the start, I now tend to be invited in to help developers make better refactoring decisions after quite a lot of code has already been delivered. This is usually around the time that design quality is becoming a major factor in the team's productivity, as managers finally face up to a mounting- and sometimes crippling - technical debt that they've let build up over the months and years. Many clients still want some architecture bigwig to come in and wave a magic wand. And for many architects, there's still a very good living to be made from that sort of nonsense. But the problem of technical debt is real, and the solution I recommend for dealing with it is realistic.
What triggered my thoughts on this today was a piece of junk mail that landed on my doormat this morning. The headline read:
Put your Christmas debts behind you with a $10,000 loan
And that immediately got me thinking of the problem of technical debt, and how some snakeoil-selling architects try to convince us that they are the solution. Sorry, folks, but technical debt gets paid off at the code face, not in the boardroom.
Posted 14 years, 6 months ago on January 23, 2007