The fifth agile manifesto – “We value craftsmanship over crap”
Why would something that would seem so obvious to an uninitiated observer get so much attention? Bob Martin’s proposal is being discussed here and in other blogs listed below
The reason why this proposed element in the manifesto receives so much attention reflects on the state of code being written and the lack of quality thereof. Almost every one in the keynote audience at Agile2008 conference where Bob Martin dramatized this proposal by flicking a card high up in the air had faced the problem of code quality.
There are three agile principles apparently in contradiction with each other. “Build quality in” – which expects the developers to get it right the first time. “Re-factor vigorously and continually” which allows them to write code that needs improvement and “Build fast before the requirements change” which puts time pressure. A good developer should strike balance between these opposing forces. Agile practitioners are advised not to use the license to re-factor as a reason not to get the right code quality the first time. Though all three principles make sense to me and seem worth practicing; its easier said than done.
When we write code we don’t want to have the pressure of getting it right the first time . We want to deliver working code quickly before the requirements change. We feel better if we have the freedom to do something “quick and dirty” now which can be re-factored later. May be this “later” never happens and the patchy code remains waiting forever for some one to find the time to re factor it. Time is more precious in a time boxed iteration; and one can understand why the “plan to re-factor” remains just that – a plan ; embedded as “to do” comments in the code at best and in the concerned developer’s head at worst.
That’s probably why Bob Martin proposed the fifth agile manifesto in his keynote address at Agile2008 international conference at Toronto. He proposed that agile should value “Craftsmanship over Crap”. Good clean code is the order of the day. Our customers would not tolerate any more “crap’ delivered as “working code”. Here are a some suggestions for developers to follow.
1) Write less code: Its found that 67% of the features are never used and 13% of them are rarely used. So its our job to diligently go to the root of the real customer value we are trying to deliver before we start coding.
2) Follow design patterns: Good coding practices have been embodied in design patterns – so try to analyze the problem enough till you find a suitable standard design pattern that you can apply.
3) Review code: Spend more time reading code than writing. Study of code smells and anti-patterns will improve your ability to detect flaws. You can also use automated tools like Find bugs or PMD.
4) Integrate frequently: Don’t assume that others will understand and use your code the way you expect them to. Gaps in understanding will surface when you integrate your code with others’ code. Frequent integration by regularly checking in and building the code will reduce this gap.