Architects
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.
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.
posted by Brad at 6:24 AM
2 Comments:
In the early days of my career, I was in a project which was almost dumped due to the application's complexity and the inexperience of the team members. We really were having a "big ball of mud" by then. At that time, a new person was hired into the team. What he did was to re-design and implement the whole application framework, threw away all the code that was bad, and guided the team to re-implement them in a better way. He performed regular seminars and knowledge transferring sessions, introducing us to design principles and showing us how they could be applied into converting the current mud into something better. He moderated code inspection sessions in which he helped everyone to be better coders. He reinforced the applying of unit testing, continuous integration etc. to eliminate many of the problems we had at that time.
And every of us in the team called him an architect, although he was not actually staffed into the project with that role: he was staffed in to be the project manager. The software community seems not to agree on what a software architecture is and what a person needs to do to be an architect. But my opinion is if anyone can do what the guy I mentioned can do, s/he is an architect.
Architects are needed, but not the kind that sit in separate offices. I've served as an architect on many projects, usually embedded. And to me, that meant deciding what parts of the system did what, what functionality would be broken into separate parts of the system. Once this was done, usually involving the other sr. developers (if any) on the project I'd be deep into the code working on frameworks and APIs.
I don't really understand how you can remain an architect without digging into the lower level stuff at times. You need to do that to keep abreast of advances in languages, services provided by the OS, etc. to do a better job architecting your next project.
Post a Comment
<< Home