Tuesday, September 8, 2009

Developers shouldn't also be architects

Much of what you're about to read applies only to organizations of some size. In smaller companies, each individual must take on multiple roles. As the entity grows in size, specialization necessarily kicks in, and the roles and boundaries need to become more defined and rigid. In a one-person shop, for example, the one person must be sales, operations, IT, and even janitorial. When the second person comes on board, the roles begin splitting; and so it goes.

Consider this graphic and assume that the area of the rectangle represents the total knowledge, energy, and capability of an individual. If this one person were to run their own company, the total work-load and output would be expressed by the area of the box.

Now the one-person company hires a second worker - the total amount of workload and output of the first person shouldn't change much (there is some loss in the person-to-person interface), even though the breadth of their work is only half what it used to be. With the addition of a second worker, the first person can get deeper, read that better, in the half-work they now have to do.

Let's say the company doubles again to four people. Theoretically, each person will handle a narrower set of duties and by doing so, should be able to excel at their assigned tasks. Now, a few caveats. There is never quite the clean separation of duties as this model portends. The model is illustrative of the true fact that as a company grows in size, the individual jobs tend to become more specialized.

So, as a development team grows, it becomes necessary to separate the jobs if for no other reason than competitive pressures to produce higher quality products. There are other reasons for job separation; for instance the QA testers should not be the same individuals that performed application coding. Programmers should be separate from the deployment staff. I offer only Jeffersonian proof - we hold these truths to be self evident.

Asking a single individual to execute both architecture / design duties as well as programmer / developer work is asking a lot and asking for a lot... of trouble. It's not about intelligence, there are plenty of professionals who are smart enough. No, the reasons for separating the architect and development activities has more to do with tendencies and pragmatics. Developers will tend to choose solutions that fall into one of two categories; technologies they already know, or technologies they want to know.

I know some pretty strong Lotus Domino developers. These folks are sharp. That being said, every business problem brought to them will be solved (i.e. designed) with a Notes Hierarchical database design. Really? Seriously? Hey, before you snicker too loud Mr. J2EE Professional - how many work-flow objects have you written? The answer should be close to zero, especially if you have Notes in your shop.

Good architects translate the business problems into a design that is technology agnostic - but which conforms to sound architecture principles such as loose coupling, abstraction, encapsulation, etc. Now it still takes a strong application developer to put those principles into practice. But the architecture of the solution should not be constrained by what the developers happen to know, or worse yet, what they want to add to their resume.

Again, I am not suggesting that architects are smarter, or that developers can't design, only that (A) the tendency is for developers to implicitly base their designs on their current development skill set, and (B) as an organization increases in size, the need for specialization should drive the design and development activities into separate domains.

No comments:

Post a Comment

Follow by Email