ITworld.com readers are keenly interested in extreme programming, and that interest has been taken up in our forums. Recently, three members of ITworld.com's Programming Theory & Practice discussion have voiced some doubts about the viability of this methodology. Here are a few of the posts

Are smart coders the enemy?

There is an interesting discussion going on in topcoder.com's discussion groups about what qualities define a good coder. The theme of this site is that coders who can solve complex problems quickly are inherently better and deserve more points. I believe this philosophy is fundamentally flawed, and I would like to launch a discussion here about XP and what it means to be a good coder.

There is the general notion in the software industry that the ability to absorb large quantities of information and grasp high levels of complexity are the most important traits in a good software coder. Although I think these coders are very effective and useful, I do not believe that the rest of us should idealize and worship them. Coders with a high level of tolerance for complexity may also tend to produce complex code; this also increases the intellectual burden on the rest of the team, who must interface with and manage that same code.

The fundamental bottleneck in software development is our limited ability to grasp complexity. We can solve this limitation in one of two ways: we can hire coders who are smarter at figuring out existing complexity, or we can hire coders who are better at writing less complex code to begin with.

Unfortunately, when software gets out of control, many organizations feel forced to hire coders with a high tolerance for complexity in order to maintain productivity. However, these organizations fail to recognize that good software design reduces this burden significantly. But what constitutes good design? A good design is one that everyone can understand without having to wrack their brains. This aspect is far more important than the traditional goals of reusability and extensibility. If code needs to be rewritten, so what? Typing is not the bottleneck. Our limitation lies with grasping complexity. So, rewriting is fine provided we have clear understanding of what needs rewriting and how.

Many supposedly sophisticated organizations tend hire an elite group of architects who put in place an infrastructure that embraces good design so that the less-skilled "bricklayers" can fill in the holes. However, I believe that this approach is also flawed. For one thing, there is no clear conceptual difference between design and implementation. Design exists at all levels of code down to the granularity of algorithms. It is important that high-quality design principles underlie all levels of code.

Furthermore, this role distinction lulls us into the naive assumption that we can get away with hiring relatively uneducated and untrained coders to act as bricklayers. This becomes more problematic when organizations hire masses of uneducated/untrained people under the assumption that a few architects can manage all the significant design complexities. Not only do the bricklayers

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine