If You Don't Use Pair Programming and Code Reviews as Teaching Tools You Waste Money
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.
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.
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.)
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.
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.)
- 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
- ...
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
- experience :-)
- R.C. Martin (ed.) - Clean Code: A Handbook of Agile Software Craftsmanship
- M. Fowler - Refactoring
- Principles, Patterns, and Practices of Mediocre Programming
- Effective Code Reviews Without the Pain