How to sell the benefits of "good code" to management?

Question

I work for a very small company (~70 total w/ 10 actual programmers) with a relatively large (1M LOC in C++) application that is in need of some serious TLC. Because of the size of the company we are driven primarily by what we can sell to customers with literally no time given for maintenance of the code other than fixing the bugs that cause things to fail, and not always fixing them well. Apparently this is how the company has worked for the past 10 years!

How do I convince management that what they are doing is actually costing them money/time/productivity? What kinds of active maintenance strategies exist? Which are good for small companies with scarce resources?

Answer 1

Basically: better code = less maintenance. Less maintenance = more time for developers to develop new features. New features = more revenue.

Also: better code = lower learning-curve for new developers.

Answer 2

I've found there are only three ways to sell maintenance to management:

• Do it without asking, but roll it into a feature development
• Ask it, but say it is necessary to allow for a particular feature or class of features
• Convince them that they'll win back the time spent on maintenance through faster feature development afterwards.

In short: management talks in features, not code.

Answer 3

My experience has been that selling a "Clean up the code base" project will always fail. I'd suggest one of the following:
1. Start allocating time for minor maintenance along with all future work in your estimates. You can use the argument that as long as you're adding a feature to an existing module, you will be able to improve it at that time as you are more familiar. Be sure to express the benefits of improvement over time, and that its cheaper in the longer then a "Clean the code base" project.
2. Start allocating time for minor maintenance along with all future work but don't tell anyone. If anyone catches on, just tell them that you needed to refactor the module in question in order to complete the feature you're adding.

Answer 4

In all my years, every time I've tried to tell managers and team leads that the code we're working on sucks, I've gotten quite a lot of backlash. (I didn't use the work sucks.) Needless to say, your companies are in the business of making money, and in their eyes, if it ain't broke, don't fix it. And, you could make things worse.

However, I did manage to rewrite something by waiting for the opportunity to arise. Some new features needed to be added, and the code had been neglected for a couple of years, and barely even compiled. I sold it to my team lead and manager as it would be a better ROI to add even more stuff in the future. That is, it was faster for me to rewrite the thing, and add their new features, than it was to figure out how the old one worked and jam a solution in there.

Answer 5

Use one of their favorite "Paradigms": Big Picture

This is a term that most of them understand, since they all see themselves as "Big Picture"-type people. Concede the point that doing things the wrong way can, in some circumstances, make more money in the short-term, but in the long-term (or "Big Picture") it costs more to maintain, sell and redeploy bad code and it would be worth the overhead man-hours of doing it right.

i.e. : "You need to look at the 'Big Picture' and see that we are losing money by doing things the wrong way:.

Answer 6

You usually can't convince them with simple discussion. Pretty much the only thing that works is to "show" them by writing clean well documented code (possibly by refactoring small chunks as you fix bugs) and tracking how long it takes developers to fix new bugs in "clean" vs. "messy" code.

This requires a good bug tracking system though including work time entries etc. before you can actually make a chart of the reduction in "bug fix" times and or reduction in "new bugs" in cleaned up code modules.

It's a long road to hoe for sure. :-)

Ron

Answer 7

Can you show that support costs are rising? Either in terms of the number of support incidents, or the % of time developers are spending on support.

Try to identify manageable refactorings that will improve things, and then show how recent bugs would have been avoided.

There is always going to be a difficult tension between what needs to be done to keep the new sales flowing vs what needs to be done long term to improve the software's 'infrastructure'. Proving that the payback from 'infrastructure' work happens in the short term is the easiest way of putting it on management's radar.

Answer 8

Without knowing a lot more about the company my best guess is there is nothing you can do.

The way you are stating it they are not even aware that they have a problem let alone looking to solve it. They are most likely going to see you as someone LOOKING for a problem where they don't think one exists.

Ten years of "experience" is a lot to fight. From their point-of-view, they have a product, it works, sure there are hassles and constant maintenance and customer issues, but nobody can argue with results? Can they? Plus, everyone has these problems right?

Maybe you will have more luck than I, but in less they are looking for it I don't think you will ever get them to see it.

Answer 9

You may wish to consider that the priorities of your company are not conducive toward producing stellar code.

If that's not the case, then make specific proposals, and sell your proposals based on the merits of the specific idea as they reflect the organizations goals.

Answer 10

First, I would recommend seeing if you can do a win-win. By this, find out the gaps where the software does not meet the needs of the company (e.g. does it limit the kinds of business, or do employees have a lot of double entry, or is there a lack of good reporting at the management level) -- and couple a system overhaul with it.

Costing money can be in a number of ways:

1) Lack of actionable data. If reports are slow (to the point of no longer being valid), or inaccurate, or non-existent, that is one area that will make the most sense to managers.

2) If manual entry of stuff or repetitive entry is occurring and it could be automated, determine how many employees are effected by it, how often they are, and guestimate their cost to the company. Then you can derive the loss as the Sum(for each person) of the time lost * the person's cost .

3) Identify areas of opportunity cost -- e.g. where staff or management is limited. Find scenarios where customers haven't been happy and haven't returned due to lack of flexibility in the system.

Answer 11

Sell it in terms of how it helps meet business goals.

Don't say "If we do this, it means once we identify a bug we can manage it quicker" Instead, put it in a perspective that people who don't really care about the technical side will comprehend and understand. Say something like "If we do it this way, we're able to increase our overall revenue and also provide better products".

If you can do that, it means the people making the bigger decisions will generally be more receptive.

Answer 12

Developers write code not managers. I'm sure your manages never told the developers to go write crap code. I think you need to convince the other 9 developers that all new code that is written needs to meet a higher quality bar.

I doubt you will ever get manager agreement to go away and rewrite big chunks of code because you think the quality stinks, However, you should be able to chip away at your co-worker developers and at least get them on the right path.

With the support of the other developers you may be able to convince the managers to allocate spare time to clean up.

Answer 13

The concept of "technical debt" (or "engineering debt") can make sense to businesspeople. Explain that whenever you do something quick-and-dirty, you incur "debt" and thus you pay "interest" every time you make a change later. That's why, for example, adding one little field to a form can take four weeks in a debt-ridden codebase.

Then explain that you can pay down that debt via refactoring (or whatever term you want to use for cleanup), and then the ongoing interest payments will decrease.

Obviously, like any metaphor or analogy it can get strained, but by using business/financial terminology it might tickle their brains more effectively than programmerese will.

Answer 14

I have found the Technical Debt metaphor very useful when trying to talk non-technical people into put money to support the improvement of the code base. The basic idea is that producing more features by letting the quality of the code suffer is like getting a loan in order to take advantage of an oportunity: you can do it, but if you never pay back the loan you will get overhelmed by the interests. Likewise, if you never fix the quality problems, your progress will be less and less, until the point where the application has to be discarded

Answer 15

This depends upon the business model your shop is working within. If you are making the next big video game, the next big IDE, or the next big CRM system for some company, the merit of cleaning a up some codebase can be evaluated in very different ways.

I only have done service development and so I cannot speak to justifying code cleanup under any other business model, but here is my $0.02 on it for service development:

If you are doing service development for some external company, it is very hard to sell a cleanup effort. "You mean you wrote bad code for us? And now you want more money to clean it up?" is a question no shop wants to be in the position of answering. As developers, we don't always realize how much our time is costing clients and they are very focused on tying cost to direct business value.

Thus, a way I like to get code cleanup done in this scenario is to describe the cleanup as "pre-requisite modifications" to some change order or feature request. This allows the business to tie the cleanup costs to some direct value which is the change or feature and allows them to use common cost-benefit analysis that they are familiar with. This buys you time to do some clean-up, but be careful with scope. Opening cans of worms when you have a week to do clean-up can be risky business. Your proposal probably did NOT say, "We will re-write the app, and then implement your feature." Do some risk and expectation management with your client and remain honest and ethical.

Perhaps someone else could answer to this under different business models of software development...

Answer 16

Chances are that they understand the trade-offs and are accepting the risks. I think the suggestion of re-factoring as you go along is probably your only hope.

If they are a small company as you suggest they will be much more interested in staying in business than having nice code. The other 60 no-developers probably have similar gripes (I wish the balance sheet/cashflow reporting/budgeting/marketing budget/sales leads/parking lot was better). Everyone put in a position to decide with real people's jobs and livelihoods on the line (questioner included) would end up taking the jam today. It is the right thing to do when you are a small business.

If you're really lucky you'll find a sympathetic technical ear in the board room so at least you have someone who understands your pain and might allow you enough room to cut some of the really bad code out as a side project or during a major bug release. That person probably won't need a lot of convincing.

Answer 17

Another thought...

Something you may want to do is keep meticulous bug statistics, organized per code component. This way you can either prove or disprove that the lack of quality in the code base is leading to more bugs in the delivered product. If you see a steady rise in the number of bugs reported per month for particular components, you can put it on a chart, and let it continue its rise into the future, to demonstrate to management that eventually half your team will be busy just maintaining that one component.

If you send out a bug statistics report every week or month, this will help your team also, because you'll feel compelled to analyze what caused the bug changes, and to take action accordingly.

Answer 18

Sometimes using an analogy can help non-techies understand.

The best analogy for why code refactoring, maintenance, etc is important I have found is this one. It is taken from a post on Slashdot:

Everybody's thrown a big dinner party and then left the dishes for a few days. Or even worse, had a roommate who did. Turns out this sucks, because if you just want to make yourself a little breakfast, then it's harder to cook. You have to scrape out a pan and chip off a plate just to get started. And cooking is twice as much work because you have to shift the mess around just to get at the counter, and then shift it again to get at the stove.

Then when you're done, you sure aren't going to wash up properly; the sink's filled with dishes already. So you just toss your dishes on the top of the pile, saying you'll get to it "later". Of course, that ever-growing mound of fuzzy dishes is the real-world analogy of half the code bases I've seen. And the giant rewrites that inevitably follow are like tearing down your kitchen and building a new one because that's the cheapest way out of the mess.

Instead, good chefs work clean. They clean as they go. Always. Not because they're uptight freaks, but because if they don't, the mess slows them down and makes them sloppier, eventually resulting in a giant clusterfuck, with all their colleagues yelling at them.

Answer 19

I doubt your bosses will ever understand the true nature of how clean code will earn your company more money unless you work for a company where middle and upper management have actively worked in many different sized software companies as programmers. Don't bother giving them programmer reasons, the just won't understand. Instead you have to give them results.

My advice is to find a project that's small enough to not be completely burdened by legacy code, and select a methodology you believe will help clean your system, and just do it. Track your changes, document how the differences in your process are an improvement, and then monitor your results as they travel through the system. In the end, if you have actually contributed positively to the code lines, and your contributions routinely pass testing smoothly while your coworkers attempts do not, people will listen to you.

Once they see the benefits of the solutions, they'll pay more attention to the problems.

Answer 20

Better code is easier to maintain but, more importantly, it is also easier to maintain by someone other than the original author.

Coding standards allow developers to be more 'interchangeable' - this is good for developers as the hero coders on a product are rarely allowed to ever go work on anything else.

I've been there - you feel really needed and important to the business for a year or so, but soon start wondering why you're always passed over for promotion and never get to work on the interesting new stuff.

As a business you want flexibility and security - you want to keep working if your star developer wins the lottery or finally decides that he's sick of working on the same thing for five years. You want to be able to scale quickly if the big opportunity comes in.

Well written, well commented, standards compliant and unit tested code costs more to write, but has far more value for the business.

Does the manager of any business want to stake its success on one developer or small team staying long term? If yes (are they insane?) then argue that devs move company every 2-5 years and their skill set is 100% transferable.

Your 10 year old code-base probably takes several months before new developers can contribute anything at all. Every time you lose a developer you're actually losing six months of their time (not to mention recruitment). If your team is badly silo-ised you may lose a lot more as all the other guys take weeks to fix small issues in the leaver's code because they've no idea how it works.

There's loads of research into how to build new projects that don't have these problems (I use a custom Agile variant myself) but not that much into changing mid-stream.