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

Code Quality Matters to the Customers. A Lot.

04.04.2011
| 5482 views |
  • submit to reddit

Some people argue that the main taks of a developer is to deliever working, value-bringing software to the customer and idealistic concepts such as code quality should not hinder that primary task. They acknowledge that it is good to strive for good code quality but say that sometimes code quality must give way to the quick deliverance of outcomes to the customer. After having worked on the code base so rotten that it drove less resistant programmers mad I have to strongly disagree. Code quality is not an abstract concept that has a value only in the developers’ world, it is a very real thing, which translates directly to money, namely if you are missing it, it translates into great financial losses over the time.

I don’t think I am an extremist. I know that code quality can never be perfect, it can always be improved (as Uncle Bob shows e.g. in CC’s Successive Refinement) and thus it is always important to find the proper level of sufficient quality. And I admit that there is code where quality doesn’t matter that much, like one-shot utilities which you use once and throw away. But when speaking about enterprise software, which will live or 5, 10, 20 years, code quality is not anything that can be sacrificed. You may gain temporary speedup by using a quick hack solution but you are thus creating a technical debt, which will be paid for several times most likely already during the development of the software and certainly during its maintenance and further development over its long life-span. Trust me, I’ve been there, I’ve seen it, I’ve paid the price and cursed the authors of the hack.

What is code quality?

To make myself clear I should explain what I mean by the term code quality:

  • Proper structuring of the code
    • separation, isolation and “condensation” of individual concerns so that one piece of code does one particular thing, which is not done by any other piece of code – thus if you need to change that functionality, you have exactly one place you need to touch
    • short, simple methods, relatively small classes (thanks to not mixing different concerns in the same class) – for long, overly complex classes and methods are very hard to understand and modify
    • minimalization of dependencies between classes and modules so that it is simpler to change any part of the code
  • Readability – expressive method, class and variable names, structuring the code so that it reads as a story – during the lifetime of an enterprise project, many developers will come and go and the code will be read much more often than being written
  • Tests – though not part of the code base directly, unit tests are an enabling and enforcing factor for many code quality characteristics

Regarding code quality, I really appreciate Kent Beck’s Four Simple Design Rules.

You will pay a lot for neglecting code quality

If you don’t care for code quality you will end up with spaghetti code, where different concerns (presentation, business logic, security, logging, different business requirements, …) are so much intertwined that nobody can ever separate them again. Long pieces of code doing thousand different things – the same things at many places via copy&paste programming – containing complicated, multi-level if-else statements, preferably using magic constants and mysteriously named variables, blocks of code without any clear purpose that nobody knows what they are good for but nobody dares to remove them… . Changing anything in such code is highly risky because often you need to change it at many places (which you don’t know about). Trying to understand the code will take you lot of time with the likely result that your brain will burn before you manage to grasp what, why, and how the code is doing. You run a high risk of inadverently breaking something and because you have no unit tests – and cannot create any because the code has no units, it is an organic, amorphic beast – there is nothing to notify you about the problem unless it is too late.

Of course this is worse case scenario, where quality has been neglected both in the large scale, i.e. the architectural structure of the code, and the micro-scale of individual objects and methods. Of those two the first one is worse for it makes it impossible to improve the code part by part but both of them tend to lead to further decay of the code. Developers working on it will learn the wrong habits and contribute further to the fall.

If the software is being used and further evoled during 5, 10 years, many people will try to work on it, and each of them will struggle with those problems and pay for them with time when trying to understand the code, when trying to modify the non-modular, amorphic, copy&paste code absolutely unfit for any evolvability, and finally when hunting bugs caused by those failed attempts. And the time of those people is quite expensive and it is the customer, originaly supposed to profit from the quick hack solutions, who pays the bill.

Conclusion

Code quality, especially on the overall structural level, is an essential property of enterprise software, which translates directly to financial losses or gains as the software is further maintained, modified and adjusted. The customer may not understand this for him invisible property and thus it is our duty as techniciants to explain it and care for it. We must strive for good code quality so that the code will be able to live on without rotting over the time. The quality will never be perfect, but it must be good enough – and this is partly measurable with the various complexity metrics etc. – and we should follow the uncle Bob’s boy scoute rule of code quality: when you are working on a piece of code, return it in a better (and never worse!) state then you got it. That means that you shouldn’t hesistate to do small scale improvements when you see an opportunity for them. The result will be that the overall quality of the code will improve over the time instead of decaying, as is usually the case. The wallet of the customer will love you for that.

Update: I’ve stumbled upon a blog documenting some of the abominations you can meet in a no-quality code: The worst codebase I’ve seen in my life

PS: I’d like like to thank Stig for inspiring me to write this post. Talking about traumatic stuff really helps to get over it ;-)

 

From http://theholyjava.wordpress.com/2011/04/02/code-quality-matters-to-the-customers-a-lot/

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.)

Tags:

Comments

Cristian Vasile... replied on Mon, 2011/04/04 - 2:45pm

Having worked myself with such a code, I absolutely agree. The problem is that many times the decision to implement hacks in taken by managers that do not understand the concept of technical debt at all (it's like thinking borrowing money from a bank is free money). The problem is compounded by fellow developers that also don't understand it. And you end up being among the few that talk about these things and ignored as an idealist.

We need more project managers that were initially developers and understand these things...

Nicolas Seyvet replied on Mon, 2011/04/04 - 2:03pm

Actually Cristian, I think the problem is much more complex than to blame managers. More often than not the problem is coming from SW developers. Yes manager impose the view of doing it cheap all the time, yet it is our responsibility to do what is needed. In my current project, the code base is crap because of the managers AND because of the low quality of the developers or their lack of technical leadership. Too easy to blame someone else for your failure.

Nicolas Seyvet replied on Mon, 2011/04/04 - 2:04pm

To jakub, code quality is extremely important. One question remains is how to measure it?

virtualmachinery replied on Mon, 2011/04/04 - 2:11pm

Absolutely agree with you Jakub. Especially on the matter of cost. Very little code is written once and never seen again - it is modified, fixed, refactored many times throughout its life. This is all done by the most expensize cpu on the planet - the human brain. The longer it takes that brain to read and understand that code the greater the cost, and the more likely it is that the fix/improvement will contain an error.

Many years ago I did a software quality course - the most important thing that I learned was 'Management by fact' - you can only do this by measurement and comparison with previous measurements as part of a continuous cycle of improvement - this lies at the heart of the most efficient engineering production systems.

Personally I think the most important thing is that each functional block of code should be visible in a single screen view in whatever development environment you use - that way there is nowhere for the bugs to hide.

There are an awful lot of things that you can measure but you should at least start by measuring something. You can get some ideas of the kinds of things that you can measure and the reasons why you might want to measure them at the links below -

 

 

 

 

 

 

Anees Ur-rehman replied on Tue, 2011/04/05 - 1:03am

Now days the project managers became the solution architect(so called). I saw some projects which are on for years and not able to finish.. only because the managers desire to finish the stuff fast and SW developers to trash their burden will destroyed the code base. It will become PILE of CODE Garbage .. Now hard to maintain, hard to improve....

Good Solution and Code Architect Must be Needed for a big project to design the standards and someone to check the SW developers to follow the standards

Mariusz Lotko replied on Tue, 2011/04/05 - 5:26am

I'd paraphrase your statement a little bit in order to make it more real:

Code quality is not an abstract concept, but has a value only in the developers’ world.

 And I fully agree with Nicolas Seyvet. I've been working for a while in a team with very low technical skills and they really didn't care that they were creating crappy code everyday. What I noticed is that "management decision" is more than less just a convenient excuse. Yes, managers put pressure to make something fast as well as we sometimes push the taxi driver to drive faster to the airport. If he's customer-oriented, he will probably drive a bit faster than rules allow. We, programmers, tend to drive 200 km/h in such situations. And if we killed some pedestrian passing by, would we say: "my manager told me to do so"? Who should decide about technical scope? Who is responsible for that?

Cristian Vasile... replied on Tue, 2011/04/05 - 12:07pm

Mariusz: I heard this many times before, and on a theoretical level I agree. It is our responsibility to make it clear to the people that can decide, so that they can make an informed decision.

In practice though, they make wrong decisions most of the time, in spite of the developers who explain them the consequences of their decisions. They take shortcuts even after you explain them that it's actually going to take more time in the end. When this happens many time and you are in effect ignored, I don't consider the developers' responsibilty anymore.

Note that I am only talking about the case where there are experienced developers in the project and they actually care about the code. The other developers should be trained into the principles of clean code. If this is not the case, the code will rot regardless of the management.

Jason Marshall replied on Tue, 2011/04/05 - 3:39pm

My father and grandfather were fix-it men growing up, and I paid for part of college by working in a bike shop.  I'm a craftsman by nature, it's just that mostly I craft code.  Unsurprisingly, my analogies about pride in your work, and safety, come from these experiences.  I have two basic ways to discuss this with people who are not taking code quality seriously. 

The Nice Way is to point out that your electrician takes your advice, but at the end of the day you can only get him to cut corners, not do something that in his professional experience is monumentally dangerous.   A real electrician is going to put conduit (a safety feature first and foremost) into certain places, no matter how much you whine about the expense.  Tough cookies, you're getting conduit.  We should all act like this more often.

The Not Nice Way is to say that your boss is never going to put Integrity on the project plan.  You either have it, or you don't.  Your boss is an easy scapegoat for your shortcuts and incomplete work.  He's less to blame for what happens than We are for letting people think it's okay to ask.  It won't stop until we decide to stop it.  And by 'we' I mean you, because I've only rarely had serious issues with pushback.  It's not as hard as you think, you just need to start practicing.

Jakub Holý replied on Thu, 2011/04/07 - 9:47am

Thank you all for the comments!

Comment viewing options

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