Improve Code Quality: Peer Design

As I work on my presentations I enjoy sharing some of my thoughts along the way. This will be the first of a series of entries that talk about concepts I plan to cover in my presentations. This is mostly a practice of thinking out loud but I think, or maybe hope, they will make a good series of blog entries. Of course, my opinions might change as I collect more and more empirical data, I'm very pragmatic, but I just have to share this knowledge pent up in my head!

What I am about to say may well change the way you think. You might think I am am a blooming idiot for saying it but I hope it helps folks improve their code's quality. Unit test do not improve your code's quality. Pause for a second and let that sink in, unit tests do not improve your code quality. They measure and verify code quality but they themselves do not improve the quality of your code. Think about it, running unit tests over and over again will not improve code's quality. I'm not intending to undervalue unit tests but it is important to realize unit tests improve the application's observed quality by ensuring properly functioning code. Unit tests do not improve your code's quality and more importantly maintainability.

Once you come to accept this fact the question you may be asking yourself is how does one improve the code's quality? Coding standards provide a good quality baseline and may serve to enforce some code quality, TDD can help improve the code quality (a node to unit tests), code reviews could certainly help improve quality, and design up front might help code quality as well. The truth is we all have different techniques to improve the quality of our code and I will discuss each one of the aforementioned topics in the future, and in my presentation.

Today I wanted to spend some time discussing peer application design. XP advocates may be keen to note I left off peer, or pair, programming from the list techniques to improve code quality. I did this with good reason, I do not like it. In my experience it is a waste of a developer, I'm not saying it is a bad technique for everyone but I am not an advocate. The reason for my lack of enthusiasm towards peer programming is I favor peer design. In my experience peer programming really turns into peer design only with lots of code being written and rewritten. Peer application design is when a group of developers/architects, not necessarily limited to only the developers of the system, have a design burn down of how the domain(s) should be modeled. It certainly does not need to be limited to the domain(s) but since at Kroger we have a fairly standard framework stack most of the design discusses focus in the domain modeling and not other aspects of an application. Peer design forces us to use our whole brain as we must first internalize our rationals then verbalize, and often times defend, our rationale with others. At the same time, or near same time, we are internalizing others' concepts and mapping them to our own. Peer design has the added benefit of cross training, since we are including peers that are not planned developers on the system in design. Peer designs, just like their big brother JADs, do not generally just happen; they need coordinated and a strong facilitator ensuring the flow and guiding decisions in the correct direction. This is not to say you can not do a quick peer design with one other person at the bar on a Friday night but generally they are slightly more organized than that! Generally the output of a peer design session(s) is some sort of map for development. The map could be as simple as a cave drawing on a bar napkin or as sophisticated as a set UML diagrams. The diagrams, whatever form they come in, are much easier to change and morph than large chunks of code that you will get with peer programming. In a future entry I will talk about code reviews these diagrams can be very important in code reviews.