Jakub is a Java EE developer since 2005 and occasionally a project manager, working currently with Iterate AS. He's highly interested in developer productivity (and tools like Maven and AOP/AspectJ), web frameworks, Java portals, testing and performance and works a lot with IBM technologies. A native to Czech Republic, he lives now in Oslo, Norway. Jakub is a DZone MVB and is not an employee of DZone and has posted 155 posts at DZone. You can read more from them at their website. View Full User Profile

If You Don’t Do Pair Programming and Code Reviews as Teaching Tools You Waste Money

11.19.2010
| 12948 views |
  • submit to reddit

There is an easy way how to save many man-days and thus also money on a project by adding some work to the key team members. You must be thinking that I’m crazy if I want to add even more work to the already overloaded senior developers and an architect but I’m sure you will agree at the end. The additional work, which will later save you many, many more, are code reviews and pair programming of an inexperienced and a senior developer.

Bad Code Can Kill You

My experiences from a few long-running small- and medium-size projects, where I’m every day struggling with five or nine years old code written by inexperienced developers, lead me to the clear conclusion that if somebody had taught them how to write a clean, high-quality code, we would have saved lot of time wasted later on trying to understand the code and to modify it for new requirements without breaking there something else. And, of course, a bad code has a strong tendency to rot even more because, due to its incomprehensibility, people are afraid of touching it and thus create complex constructions to minimize the extent of necessary modifications and also because, due to its insufficient flexibility and evolvability, new or changed requirements lead to a rapid growth of its complexity. The aforementioned problems are caused by the fact that such bad code doesn’t follow the best practices and ideals of object-oriented programming, such as:

  • Small classes with a small number of short methods
  • Classes having each only one clearly defined responsibility
  • Each class has usually only few dependencies and is unaware of most of the other classes and objects
  • Modularity resulting from this good distribution of responsibilities and good encapsulation of data inside the classes
  • (Thanks to these characteristics it’s also very easy to write unit tests.)

On the other hand, you can usually see a handful of anti-patterns in a bad code, for example:

  • God Class is a very large class that does nearly anything (there is actually also an opposite anti-pattern that I’ve encountered, “Functor” or how to call it, i.e. each method has its own class, usually named doIt or similarly)
  • God Method – too long method doing too much – usually within a God Class
  • Copy & Paste Programming and the resulting repetition of code and C&P errors
  • Monolithic code, where everything depends on everything else (and unit testing is thus essentially impossible)
  • Hard-coded data about the environment (path to a log file, DB driver class, …)
  • Reuse of variables – the same variable or object’s property (or DB column) is used for different purposes so that it’s difficult to understand its actual meaning (wouldn’t you be surprised to find out that SSN actually holds employee’s organization code?)
  • Procedural programing and overuse of static methods where all (usually many) data is passed via parameters instead of an efficient use of the object’s properties

And yes, if you have a weak hearth or a tendency to explode with anger, maintaining a bad code can really kill you ;-)

Learning Clean Coding via Pair Programming and Code Reviews

This is by no means to say that inexperienced developers are stupid or that they don’t care for high quality code (I’ve actually regularly met traces of their – though not always successful – attempts at quality). They just had no practical opportunity to learn how to bring code quality to life and praxis is here the only way how to really learn it. And here we are getting to the point – I firmly believe that code reviews and especially pair programming with a senior developer are by far the most efficient and fast techniques for learning how to create good-quality, clean code. Even just few days of pair programming can open the eyes of the youngling and set him/her on the right track.

By observing the way of working and thinking of a developer who is already a clean code practicioner or even master, and by working under his/her supervision with an instantaneous feedback, I can learn in a rather short time the most important habits (integration of unit tests, starting with a simple design and refactoring as needed, …), the clean code mode of thinking and developing and the most frequent design and implementation patterns as well as the ability to analyse and evaluate the task at hand and to distinguish the important from the unimportant. There is no more effective way of learning this than by personally cooperating with an experienced person on a solution of a real problem and then trying to apply the learned stuff with him/her providing a feedback. You could read many books but they couldn’t give you anything near this experience. After an initial period we can loose the contact and cooperation (unless we are lucky to work in an XP shop) and replace the shared development with code reviews and discussions.

Selling the Idea to the Management

It’s understandeable that a manager would hesitate to use the scarce time of his/her best people on such a low productivity effort as teaching newcomers. But it’s necessary to realize few basic facts, namely that code is written just once but read many times and that the life span of a typical software is usually a couple of years, let’s say 5-10. Thus every time saving during its development at the expense of its readibility and quality will be repaid by a multiple of that time later on. One IBM statistics claims that the cost of maintenance (and further development) is typically considerably higher than the cost of the development of the initial version. You can save during the development for the price of later (much) higher maintenance costs but it’s like living on a loan – by lending from a bank it seems that you have more money now (more time till the deadline in our domain) but you will highly repay it later. It’s the task of a responsible and able manager to explain to a customer that if she sacrifices quality for time or budget, it will cost her much more later. (And any such saving is actually doubtable for on any larger project the bad quality of its codebase will affect you already during its development.)

The top management should thus encourage and support the process of introduction of new developers based on pair programming and code reviews to prevent later considerable losses. And what happens if you teach them but they leave? Well, you should rather ask what if you do not teach them but they stay! (As somebody has pointed out recently on the internet.)

Post Scriptum

I’d like to make clear that I do not consider myself as a master of clean code. I sometimes write terrible code and never a perfect one. But I believe that during my ogoing quest for code quality I’ve learned a few good things that I can help to spread further.

Summary

Young developers usually don’t learn how to create a high quality and clean code at the university and thus in spite of all their efforts they sometimes write code of poor quality, which then causes headakes to many other people and makes maintenance and evolution of the software more error-prone, expensive and slow. But young developers are smart and given the right example and an opportunity to see and apply clean code practices in the real life they can improve a lot in a short while. The best way to give them this opportunity is to let them work in a pair with an experienced developer and later, when they’ve already gaind the right mind set, they can be kept on the right track and encouraged towards further development via code reviews.

Of course both the pair programming (or mentoring) and code reviews must be open, friendly activities where both parties are given equal rights to express themselves and be listened to. The experienced ones shouldn’t forget that they too can be mistaken and that they can sometimes learn a great deal from the young ones.

The main message of this post is that we should not neglect the practical education of young developers because by investing little initial time of our experienced stuff we can enable them to make huge progress and by investing a little more of it continually we can enable them to keep growing rapidly. This will result in a considerably higher quality of their products and consequently will prevent a lot of wasted time and money.

Resources

 

From http://theholyjava.wordpress.com/2010/11/18/if-you-dont-do-pair-programming-and-code-reviews-as-teaching-tools-you-waste-money/

Published at DZone with permission of Jakub Holý, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Igor Laera replied on Fri, 2010/11/19 - 10:20am


I wonder why anybody lets inexperienced programmes write new code, and even
without any tool support? We have all the classic tools in place, like Eclipse-Checkstyle,
PMD and the obvious test coverage reports you get after each larger weekly build.

Usually you start giving people old code to maintain. If they see the "yellow warning dots"
popping in eclipse, because their functions are too long or they have unused variables
or potential null pointer accesses...you can "train" them much faster this way, since they
learn by themselves and can ask good questions if they don't understand the marked problem.

We usually discuss this stuff in our weekly meeting, and even oldshools learn or or two
things. The group discussion about the "usefulness" of certain checks are quite an experience
itself :)

I'm a little uncomfortable with the broad suggestion of pair programming. I see good
results if done by two experienced programmers when you have a critical module.

But pairing a beginner with a pro never really worked for me. If you want to train people this
way, that is fine (if the pro is open to that job - not everybody who writes good code is a
good teacher nor interested in that type of work). Expecting the pro to deliver his usual
share of work while he is training seldomly works - I never experienced it.

In my eyes: codequality is personal standing point, is a part of your expression; not a process
item or something to check off a list. People writing sloppy, bad maintable code and keeping
it that way for month, years just have the wrong job.

A car mechanic working in a manufacturing plant can't simply half-screw a tire. He simply can't.
In software development, there are still too many ways to get away with such things.

 

Jakub Holý replied on Mon, 2010/11/22 - 3:28am in response to: Igor Laera

Thanks for your comment, Igor!

Thanks for the suggestion to train new people on code maintenance (seeing both good and terrible code can certainly teach them a lot), though this is not always possible, and epsecially for the mention of the tools.

You are certainly right that when pairing as a learnign experience, the productivity will be visibility lower and that the "mentor" must be able and willing to do it.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.