Motivating Beautiful Code
January 9th, 2009 Jeff Howell, Consultant
Beautiful Code (code without ‘smells’)
Dilemma
A developer asked “How to convince someone [an IT manager] of the value proposition of great/beautiful code? (Or at least the value of code smell eradication.)”
This is a very real problem and is especially prevalent (in my experience) in larger, older programs that have met with some success, especially when the management are non-coder folk.
Beautiful Code is not an aesthetic pursuit; the Beauty lies in the fact that the code is well structured, concise, and obvious. This kind of beauty has high business value because it requires less effort and cost to extend with new features and to track down bugs.
All arguments for code smell reduction (let’s call that CSR so as to appeal to folks who like TLAs) require faith: faith in developers, faith in research and it’s applicability to the present circumstance, faith that intangible benefits will actually occur.
All arguments against CSR are posed as risks: it is risky to trust developers or research, and it is risky to bet on benefits that may not materialize since predictions about development budgets and schedules are never correct.
To dissect a layer further, the arguments for CSR come from the initiated. That is, from those who code, who live with bad smells and despite a desire to reduce the stench, cannot seem to make a compelling case to the uninitiated. The initiated do not understand why the uninitiated cannot see that which is so obvious.
On the other hand, the arguments against CSR come from the uninitiated, i.e. those who manage the initiated. They understand that the product is successful, despite the initiated constantly complaining.
So, enter into the Dilbert Zone. Bosses are ignorant and workers are lazy whiners.
Trust
The root problem is about trust. Managers find it difficult to take a risk when they do not trust the advice they’re getting. And workers fail to earn their trust by complaining (even in the most positive sense) and then managing to deliver something acceptable anyway.
Workers try to explain the plain facts of their lives to managers, but seem never to be heard. No rational argument can ever overcome the irrational fear managers have. They are very reluctant to go out on a limb based on the advice of a bunch of whiners. ’Where’s the up-side? How will taking this risk affect my bonus? My longevity?’
Solutions
The solution must be targeted at the managers since they hold the budgets and because they are the no folks in the equation. So how do you compel someone to trust?
The solution should be broken down into steps of increasing size and risk, with the smallest steps first. This allows a manager to accept a small risk on faith. The key is for developers to muster their courage that this time it could be different. Be up-front about what is being risked and how success is to be measured. Success must be measured in terms that the manager appreciates. Celebrate the success and use it to leverage the next act of faith.
So that’s all very nice. But what about the manager who is devoid of optimism? Their problem is fear of risk, so we might try to characterize the experiment of improving in small steps as an alternative to a fear even larger than the fear of failing. This is a tenuous tack because the manager is already reluctant to trust anything developers claim. The crux of the argument is that each new feature requires a disproportionately larger effort (cost and time) then all preceding features. It is incumbent upon the developers to prove this fact to the managers based on the actual history of the product.
The proof that effort required per feature-unit is increasing is likely complicated because estimates were not done well or even recorded, and actual performance may not have been measured. This will take some creativity. In a protracted effort, developers should create their own metrics (I mean record and analyze them, not make them up) to prove the point. Hopefully, this can be accomplished before development grinds to a halt under the big ball of mud that the code base will invariably become.
Entry Filed under: Process and Governance
5 Comments Add your own
1. Brian Gray | January 12th, 2009 at 10:05 am
Really interesting post — and indeed something I have struggled with. One thought I have: is it possible/desirable to motivate a large risk when necessary?
Say, for example, you (the developer) have a large cumbersome class (with no unit tests) that keeps being the source of little bugs. You want to beatify it, refactor, add tests, make it readable — but this will take time and result in a functional match if all goes well (only hopefully without the defects).
The manager sees a large time investment, the possibility of adding new bugs, and really doesn’t see the problem with the mostly functional class that you have to dig into every few months, figure out how it works all over again, and put band-aids on. Is there a good answer here?
2. Jeff Howell | January 16th, 2009 at 3:59 pm
Brian,
You hit the nail on the head. So the answer has to start with “depends” …
One strategy is to find an incremental approach. Manager have an easier time if you can present a case like, “I have several small steps in mind, about 4-8 hours each, that will improve this troublesome code. At the end of each step, the code will be fully working and a little better then when I started”. The point here is to give control of the process to the manager so they can decide if time/budget is available and make a trade off decision.
Another strategy is to attack as you work through bug reports. Each time a bug is investigated, make a deal with the manager that you will make improvements via tests and coding improvements in the specific area of the bug. Like the preceding strategy, the manager is still in control and you are only adding a small incremental effort (since the bug had to be fixed anyway). The increment needs to have value in preventing reoccurrence of the present bug and of future bugs that have similar location or characteristics. The changes/tests will also strengthen the code so that future developers will have fewer problems understanding, extending, and maintaining.
For a real mess, you may have to do some initial work before you can even present a cogent case to the manager:
If you can wrap the smelly class in some tests that verify current functionality, you may be able to incrementally improve it. Structure tests for two purposes: to identify current functionality that your incremental change inadvertently breaks; and to test the incremental change. This will be imperfect, but much safer than without the tests. Also, each incremental improvement adds more tests, so risk is lowered with each step.
You might also try mechanical refactorings like breaking methods into smaller methods, extracting “helper” or “utility” classes. These are quick and relatively low risk and at least reduce the problem. Once you work through some of these refactorings, the intent of the code will become more clear and you can begin to make more targeted refactorings.
Or you may try running a static code analyser like PMD or Eclipse Metrics. Explain to your manager what Cyclical complexity means and try to get approval for incremental improvements that specifically improves the metrics. This may appeal to the manager because it provides feedback of your refactoring activities.
–jH
3. Dan Tasse | January 16th, 2009 at 4:53 pm
One thing that’s really nice is if your manager (and manager’s manager, and so on) is a programmer too. I guess this happens more in software companies than for consultants. It really helps: the discussion becomes not “should we make the code more elegant?”, but “how elegant should we make it?” My manager’s been more than understanding when I’ve been trying to really make code the best quality code that it can be.
I don’t know how this helps the conversation. I hope it’s not just a case of “you can’t know what it’s like to work with good/bad code unless you have done it yourself.” In that case, it is just a trust thing, like a car mechanic. If you trust your mechanic, and he recommends replacing some belt or something even though the car’s working okay now, you’ll let him do it; if not, you’ll figure he’s gouging you, and not do it (and then your car will fail spectacularly in a month). Unfortunately, code is maybe even harder to measure than cars.
In short, I agree!
4. Handerson Gomes | January 18th, 2009 at 4:59 pm
I would add that making the smell public within the organization is another strategy to be considered by the team. In many cases the developers are the only ones being affected and close to the smell, and therefore I can see why some managers don’t value the investment to improve the beauty of the code.
Creating a project/product site with reports including reports like PMD, Crap4J, Cobertura and making it available is one way to show that the smell is there and it need to be fixed.
Continuous Integration is a great way to show and track the evolution of the code base.
5. Jeff stonebrook | January 20th, 2009 at 9:02 am
So - let me speak to this from the perspective of the manager who doesn’t want the code changed.
Often times, the manager is trying to be risk-adverse by not allowing a troublesome piece of code to be changed. But in pushing off the refactoring / beautification - the risk is just being pushed off, not adverted.
But what this is crying for is better unit testing on this piece of code. If you have a robust set of unit tests for a piece of code, managers are much more likely to allow the code to be refactored because your unit tests will help define if the code changes that were made did not break any of the functionality of the code.
Therefore, when dealing with a manager who is concerned about changing the code - think about it from their perspective. They are worried about destabalizing the source code base not just the time investment involved. Combat this with a well-defined unit testing framework and test suite, and I think your arguments to refactor / beautify will be met with much less resistance.
Leave a Comment
Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Trackback this post | Subscribe to the comments via RSS Feed