As developers we need to be acutely aware of our end user’s needs. We collaborate with them on system and interface design, we demonstrate progress at frequent and consistent intervals, and we proactively gather their feedback and incorporate it into the final solution. The end result of our efforts, working software, is continually on display to these users and like a Pavlovian dog, we desperately seek their approval of it. This is a very good thing; the most successful products typically spend significant dollars on user research to determine if the final product will delight their customers. When developing software though, the end users are only half of the target customer that developers should be concerned with.

The people who tend to look at our source code most often are not the end users; they rarely if ever see the kung fu we wield within our editor. The audience we need to be concerned with is the group of poor schmucks who have to triage our defects at 3am when the billing system goes down. It is the new guy who was indoctrinated into the group by being tasked to replace all of our table-based layouts with a CSS based approach. Your audience as a developer is the person sitting beside you who one day will have to change your code even though they have no context to know what you were initially thinking when building it. This is the audience we as developers need to cater to and we are horribly averse at gathering feedback from this key group.

I’m obviously speaking generally here, but why are we as developers so averse to showing off our source code? Embarrassment, bruised egos, laziness, and a perceived lack of value are viable and accurate reasons why developers resist gathering the same amount of feedback on source as they do on software. None of these reasons however, can outweigh the dramatic drop in efficiency that comes with producing a complex code base that is difficult to read and maintain. Roger Pressman notes in the book Software Engineering: A Practitioner’s Approach that 80% of software costs occur in the maintenance phase. If the vast majority of our effort will not be in creating the initial solution, but maintaining it, how can we be successful without some level of feedback from our peers on the quality of our source code?

The short of it is, you cannot be successful in this model. Organizations have spent countless iterations creating new solutions, watching them rapidly degrade into systems that cannot be enhanced, and then re-creating a mirror replacement system with new frameworks and languages that are just as apt to be termed legacy as their predecessor. Legacy systems can be built in any language or tool (some more than others, no doubt), it is the responsibility of developers to solicit feedback from their peers to ensure the end product is readily evolved.

If developers can put their egos aside, a number of tools and techniques are at their disposal. Pair programming provides continuous feedback from a member of the target audience. Initially popularized as a quality measure, pairing also gives developers another perspective into the relative complexity and readability of the solution. Code reviews are sometimes deemed unnecessary when pairing is in place, but these two are not exclusive practices. When pairing, developers will communicate and collaborate to progress from a blank slate to a final solution. In other words, both members share a good portion of the context within which they are working. The poor schmuck at 3am talked about earlier does not typically have this context. Code reviews can mimic this blind immersion into a solution and often provide further valuable insight into how quickly others will understand the source.

While legacy source code can be produced in any language or framework, there is no doubt that many languages value essence over ceremony more than others. Ruby has gained significant popularity for this reason and the number of DSLs building on top of this language are expanding it’s presence into testing, building, and integrating within other languages like Java and C#. Even if you cannot leverage Ruby or a higher essence language like it, you can probably still find fluent interfaces, leverage better variable naming, and pick up on many other tools to ensure that the poor souls following in your footsteps have at least a fighting chance. Regardless of the tools used, be sure to get your code in front of other developers and get feedback. Without consistent, unabashed input on how well your source code is understood by your developer audience, you’ll never be able to say that your solution is truly meeting the needs of it’s users.

Trackback URI | Comments RSS