I have been thinking about software architects lately. Some, if not most, companies hate to see 'software architect' on a resume, and don't want to hire anyone into that role. My last employer (not my current) always said they wanted me to step up to that role, but also that customers don't pay for architecture, and it is not very important.
Nothing could be farther from the truth. Customers pay big for architecture, but they don't pay for good architecture, they pay for bad architecture. If everything is architected well (like my current job), existing code rarely needs changed, and most new development involves thinking about what the product should do and how it should do it. If everything is architected poorly, all the time is spent fixing the same problem over and over. People blame coders for lacking "attention to detail", when 2000 lines of code are used to do the job of 200. New development is slow and tedious, the "what the product should do and how it should do it" either becomes big upfront design, or becomes an afterthought. Products are released that are unsupportable, and if they crash, the only way to find out what code is at fault is by the whole development team staying hours late going through Dr. Watson logs and spaghetti code. Obviously, products developed this way are more expensive.
What some people think of as good architects are problems to. Big companies pay a few "architects" six figure salaries to sit in a private office isolated from the team, draw fancy Visio diagrams about complex "frameworks" and "reusable components", and tell coders what to code. This make projects more expensive too (although never as bad as the first scenario). These architects are probably responsible for most of the negativity people have about hiring architects. They are probably the architects Joel talked about in "
Don't Let Architecture Astronauts Scare You" - although I blame salespeople for that (more on that later).
So are architects really needed? Read about the most popular real world architecture style -
Big Ball of Mud. Most agile coding (Scrum, XP) seems to frown on (or ignore) architecture. It seems most of the successful projects are those that ignore architecture completely, but end up with a well enough architected code base to avoid the first scenario. But this is far from optimal, and usually happens by chance.
So what is the solution? I remember back to my days being an undergrad, and
Dr Gowda's class. The most important lesson he always stressed was coupling and cohesion. This goes back to Structured Design by Larry Constantine in 1974, before I was even born. With things like "object oriented" and "agile methodologies" becoming more and more popular, no one likes the idea that the solution to most of our problems is over 30 years old. If a complicated and large system, no matter how otherwise badly designed, is loosely coupled, it can be fixed and used and maintained. Once a solutions develops bad, tight coupling system wide (to the point it cannot be decoupled), you have to throw it away, or all your efforts become more and more difficult, and eventually wasted.
I think this is largely the role of architects - to avoid excessive coupling within the system, to prevent it from degrading to this point, and to recognize if this happens. Beyond that, architects are useful to review code, ensure good programing practices are followed, and spend the rest of their time doing development. Is this is best left to one or a few team members designated as "architects" or best done by everyone? I think it is best done by everyone on the team.
