176

This is a question that I often ask myself when working with developers. I've worked at four companies so far and I've become aware of a lack of attention to keeping code clean and dealing with technical debt that hinders future progress in a software app. For example, the first company I worked for had written a database from scratch rather than use something like MySQL and that created hell for the team when refactoring or extending the application. I've always tried to be honest and clear with my manager when he discusses projections, but management doesn't seem interested in fixing what's already there and it's horrible to see the impact it has on team morale.

What are your thoughts on the best way to tackle this problem? What I've seen is people packing up and leaving. The company then becomes a revolving door with developers coming in and out and making the code worse. How do you communicate this to management to get them interested in sorting out technical debt?

13
  • 6
    "working with developers" "communicate this to management" Which are you asking about? Developers or managers? Who's behavior do you want to change?
    – S.Lott
    Feb 4, 2011 at 23:53
  • 47
    Technical debt is like financial debt - it's much easier in the long run to simply not accumulate it to begin with. Pay all your technical bills once a week. Feb 5, 2011 at 4:25
  • 8
    Mike > I think you live in much less restrictive world as deadlines and limited budgets dominate the world I live in. If software doesn't adapt well to future needs and requires a lot of work to fix, then management are often more concerned with ignoring it and keep bolting on features. Now a lot of companines I've worked in put timesheets in place so developers need to record their work and if time isn't being invested in where management sees the potential business, then you are wasting your time. Feb 5, 2011 at 11:00
  • 5
    I guess you could say it's a problem with short term benefits vs long term benefits. If a software team tidied up a system in such a way that new features took under an hour to implement instead of a day, that is an immediate benefit. If management see you trying to improve the code and going against what they want, you are being a bit of a rebel in their eyes. I dunno really what the best solution is, but it seems like such a common problem and I've seen what it does to teams. Feb 5, 2011 at 11:03
  • 4
    Scott > To answer the question, it's managements attitude I'd like to change. Developers know the code and have first hand experience as to what code be improved upon to make things easier. In a previous job when we released a new version of an app, the number of bugs kept increasing at an awful rate. I've tried hard to get test strategies in place, but it often feels like a lost cause. Feb 5, 2011 at 11:06

17 Answers 17

213

When I met with my boss to discuss this, he said I should include refactoring in all my estimates. He said it's not a problem he wants to think about. Instead, I should handle it.

This isn't a problem that management in general wants to think about. They aren't the engineers, you are. Just make this an unspoken part of all of your estimates, and you'll find that the technical debt decreases.

It will never be perfect though. Technical debt, like credit card debt, is an investment in getting customers faster and gaining market share over your competitors faster. Like credit, if managed properly, it can make you quite successful.

14
  • 35
    my experience is generally along the lines of this. The technical debt gets cleaned up as new features are added. Sometimes the estimates for certain 'related' fixes/features are padded to include cleaning up these things. Feb 5, 2011 at 3:28
  • 8
    Good answer. I'm yet to see a business who are happy to sign off a 'refactoring' project that would yield no benefit to the customer, only tidier code. Refactor-as-you-go. Feb 5, 2011 at 9:06
  • 9
    "When I met with my boss to discuss this, he said I should include refactoring in all my estimates." - This is the attitude I take and the stance many developers in teams I've worked in take. However, when these 9 till 5 developers as we call them are concerned with their reviews and pay rises, they aren't going to create more work for themselves. They are going to follow whatever management thinks, after all, that's who pays them. Feb 5, 2011 at 11:27
  • 11
    @jmort253: there is one (slight) issue with this otherwise excellent policy -> it's not possible for extensive changes (ie, changing the database as said by the OP). Those must be explicitly addressed. Feb 5, 2011 at 19:02
  • 6
    The issue is when some refactoring that is required is large enough that it can't just be tacked on
    – Casebash
    Oct 26, 2011 at 12:44
53

It's like Gandhi said when asked if his tactic would work with someone like Hitler. He said, "It would be difficult." But I think there's a fair argument that the answer really is "No." Sadly, I don't think what you are trying to do can be done. It's not that I'm trying to be pessimistic, but rather I'm trying to be honest.

The problem to me is not that managers need convincing. The better ones already understand that debt can be a killer if not managed. But whether they understand it or not, whether they're good managers or bad, they all face the pressure to deliver, and that delivery is judged by their bosses against a date. Quality only matters if it's extremely bad, in which case it's the developers' fault, or extremely good, in which case it's management brilliance that made it happen. Quality just needs to be "good enough."

I think I like what Renesis said in his answer, because it's one of the few that understands that management thinks very differently than engineering. And I think we've all seen the progression of companies to become date-driven and more project-managed as opposed to customer and quality focused. By this, I mean typical companies, not the really stalwart ones that have the guts to say "It'll be done when it's done" (like Apple Computer or id Software - and yes, I understand that sometimes people aren't at liberty to take that approach).

But here's the thing: companies that take the quality-first approach...what do you notice about them? That's right, they're run by engineers, not salesmen, marketers, project managers or accountants. Think of HP, Apple, id, Google, Microsoft, and IBM. All started and made successful by engineers, not salesmen, though salesmen certainly played a part, and I'm sure many would debate having Microsoft associated to quality :). And of those, the ones that went downhill got away from engineering-driven leadership. There's a whole host of arguments in that statement though, as there are plenty of technical companies that ultimately failed due to an inability to adapt to changing times and manage their own growth. I don't see engineering-based leadership as the cause for those failures, to me that's an issue of skills and business acumen that are independent of someone being a developer or an accountant. I think generally speaking, however, that there is a dedication in engineering to the rigors of accountability and discipline that benefits companies where engineering is a component.

Seriously, look around. IT leadership is sorely lacking. Focus is always on cost and time, and rarely on quality as long as it's good enough. IT leaders rarely report to the CEO anymore, now it's always the CFO. IT is stuck doing production support and increasingly beholden to project managers whose focus is on smaller, more digestible, and measurable chunks, not significant changes of revolutionary value (not that this is necessarily wrong; divide and conquer is a good thing, but the vision needs to be there for the big picture).

Sorry to take so long on this post, but in the end I think your question, about how to make management care about technical debt, is often better solved by finding the right leader, rather than changing the existing one. Explaining technical debt to standard thinkers means changing the focus to money and cost, as Renesis said, and I think that loses a lot in translation; even if you were successful at it, it would only matter if the top leader in the company bought it. Convincing your middle manager to do the right thing will probably only get him fired.

1
  • 1
    One factor that you're not really addressing is that poor-quality code often takes significantly longer to maintain due to complexity, and also typically has a high bug count. Thus, poor quality will eventually severely impact things managers value, but management often is unaware of the degree to which their slipped deadlines and lost customers are actually due to past practices of not maintaining a reasonably clean code base. Experienced managers who really value "money and cost" also understand that they can, and should, often proactively spend some money now to save a lot of cost later.
    – Some Guy
    Apr 2, 2021 at 22:58
48

First thing to do is change the wording. Calling it "technical debt" gives management the idea that allowing it is an investment of some sort — when really it's more like a virus. (I'm like the Dave Ramsey of technical debt.)

Allowing it to go unpaid comes with a huge cost which can't be seen or easily quantified.

List problems such as the following for management:

  • New features estimates are way higher than they need to be. Or, impossible altogether.
  • Bad code spawns more bad code
  • Bug list grows even if developers are always fixing them
  • Team members are leaving (this itself can show that there is a problem as explained in this excellent answer)
5
  • 9
    +1, although I think the last bullet should be "The good/best team members are leaving" Feb 5, 2011 at 3:29
  • 12
    Bit technical debt is an investment sometimes. If you're racing with another company and who launches first gets the market for themselves, then it makes sense to make shortcuts in the code to launch faster. Nobody will care that you have perfect code if you have zero paying customers.
    – quant_dev
    Dec 23, 2011 at 10:59
  • 5
    @quant_dev if you see this as a dichotomy between "faster" and "perfect code" then of course you'll think that way. There is no reason why shortcuts can't be technically sound in which case they are not considered technical debt.
    – Nicole
    Dec 23, 2011 at 17:07
  • 2
    @Renesis "There is no reason why shortcuts can't be technically sound" -- that's just not true.
    – quant_dev
    Dec 24, 2011 at 17:13
  • 4
    And sometimes it's not technical debt at all, it's just a mess: sites.google.com/site/unclebobconsultingllc/…
    – TrueWill
    Jan 13, 2014 at 19:01
32

My management has actually started making a serious effort to address technical debt, which is one of the reasons I like working there, but it's a long term effort and it never hurts to remind them why the effort is worth it.

One way I keep the pressure on is whenever I am asked for an estimate, and time could have been saved if I didn't have to deal with specific technical debt issues, I include that in my estimate. For example, "This bug will take me 2-3 days to track down, but if we had already addressed these 2 other 'low priority' bugs that have been in the queue forever, it would probably take less than one." Often, the response will be to go ahead and fix those other ones while you're at it.

I also agree with other answers about just considering improvements part of your job and doing them as you go if it's not too disruptive. My current task involves making additions to some very poorly designed code. Rather than adding to the mess by writing my new code to match, I'm spending a little time up front consolidating common functionality, so sending a packet becomes a one line function call instead of constantly repeating 15 lines of slightly modified copy-and-paste boilerplate.

I know for a fact it is going to save some maintainer's sanity further on down the road. I know because I'm that maintainer today. However, I also believe it's going to speed up my own current task of getting this feature in and debugged now.

Another technique I've used in the past and should do again is to keep a refactoring DVCS branch around in a separate working tree for that down time when you're compiling, waiting for a long test, or just need a change of pace for a bit when you're burned out on a bug. As long as you occasionally merge from upstream so you don't diverge too far, you can take as long as you want on refactoring changes with very little marginal effort. 15 minutes here and there per day can really add up over time.

0
21

You could try the credit card analogy. Ask them "do you feel comfortable leaving your credit card statements unpaid over an extended period of time?"

Managers understand costs and benefits, but (usually) not the technical terms used by us developers. The term "technical debt" was already invented to help overcome this communication barrier, but you may need to articulate it clearer. Most managers know very well (often from own experience) that overdue credit card payments grow with a horrible interest rate so it hurts to leave them unpaid. This may help them get the seriousness of the issue regarding software entropy.

But if this doesn't convince them, try to gather factual evidence and make some calculations. E.g. how much does it cost for the company - both in hard cash and lost time - to replace a leaving employee.

13

Nobody will give money for replacing something that works with something else that (with any luck) also works.

What you can do is to propose replacing it with something that does more, i.e. bundle the servicing of technological debt into an upgrade that brings instant and tangible business benefits.

Of course you should be open about it, we're not talking about "sneaking it in" a new project here.

I find the other side, that of the developers' harder to handle. Basically it boils down to this: for some developers, making sure your code is the best possible code you can come up with is a matter of professional pride. For others, this is just another job and the aim is to get it done quickly and go home.

No amount of convincing will change that situation, and if you introduce a mandatory code quality standard, your nine-to-five developers will find a way to work the system, while your dedicated developers will inevitably be annoyed by the whole procedure (which isn't aimed at them, but you can't say that developer X must obey the rules, while Y can do whatever he wants).

What works, but can still be very frustrating is to have your more dedicated and knowledgeable developers overseeing the codebase, probably a good tradeoff between going forward and tidying up what's alrady there.

5
  • 5
    +1 But those 9-5 developers, well, you want the revolving door for them, ideally with some form of accelerator.
    – Orbling
    Feb 5, 2011 at 0:42
  • 3
    @Orbling: +1. If they don't care enough they really should be working somewhere else. Its GREAT having devs come to you with "I just had this idea...". Feb 5, 2011 at 4:07
  • 3
    @Orbling In certain areas of development they can be useful. I'm not at all a fan of "developer snobbery", but you have to find everyone's niche for them to be of any use. The worst you can do is to assume everyone's like you.
    – biziclop
    Feb 8, 2011 at 18:23
  • Personally, I think the industry is heavily overstaffed. Where I am based most software jobs get a good 300 candidates applying these days. With that level of competition, an employer can afford to hire employers who go the extra mile and are better than average.
    – Orbling
    Feb 8, 2011 at 19:13
  • "Roll upgrades into a refactoring to offer tangible benefits (selling points)" is what I keep hearing from our Chief Architect so I'll have to second this. Jun 19, 2014 at 15:36
13

The fact is, in a lot of companies, particularly given the current economic situation, every hour must be billed to someone.

Or they go down, fast.

Unless the existing clients are willing to pay for the refactoring, which is deeply unlikely unless it comes with significantly upgraded performance or features. Then it will not happen on the older codebases. You may be able to sneak it in to the budget for newer projects, if the clients have deep pockets, but unless you do not need to change the APIs in the refactoring, it will be of no use to older projects and may well introduce a situation where the company is supporting two codebases, which causes further headaches and cost.

As an engineer, I would love to refactor old code, which is no longer truly fit for purpose, every time something became obsolete or deprecated. But as my MDs in all companies I've ever worked in have said to me: "Who will pay?"

13

I always try to clean up as I go. I am not done until the code is clean. The problem with technical debt is that most people do not understand it. The best way to tackle it is to not accumulate any of it. If your managers trust your developers to decide how to solve a problem you can make code hygiene part of every programming task. If you never check in bad code you do not accumulate debt. If you also follow the Boy Scout Rule (always leave code cleaner than you found it) your existing debt will vanish slowly.

I don't see refactoring as a task separate from implementing features. It is an integral part of it.

1
  • 5
    I could not agree more: "Technical debt is like financial debt - it's much easier in the long run to simply not accumulate it to begin with. Pay all your technical bills once a week" Feb 5, 2011 at 15:12
7

If you're dealing with non-technical managers, it would help if you can cast your discussion into terms they understand. If you can construct a realistic case for a positive ROI on the work spent to pay down the technical debt, you might get somewhere. That exercise will depend on your circumstances, but an example might be something like this:

Analyze how much time developers are forced to spend helping Support with production issues, then make the case that fixing crufty old code would A. reduce the number of support issues, B. make it easier for Support to resolve issues without escalating to Development, and C. reduce the time Development spends on production issues when they do arise. Put it in terms of dollars saved by not having developers tied up doing support work. Also point out that every hour a developer spends doing support is a "double whammy" because not only are you paying a developer to do support, but you're burning the opportunity cost of what that developer could be doing (adding new features, etc.)

Yeah, some of the numbers will be voodoo / smoke-and-mirrors... that's OK, the dirty secret of management is that they know that the majority of the numbers they sling around are total B.S. Just as long as you give them something seemingly concrete to work with, so they can get it in their heads, you have a fighting chance.

7

After this explanation of technical debt, your management should be convinced to pay it off :

Imagine that you have a very dirty kitchen full of crap. Before preparing a meal, you have to first spend one hour cleaning. And it is like that every time you want to eat. Also, when preparing a meal, you have to be extra careful, to make sure the crap does not fall in your meal.

The kitchen is your code, meal is your product, and eating is selling your product.

If they can afford to wait longer for a change to be implemented, without a safe-net of unit tests, then there is something wrong in your company.

5

It has to be a very convincing argument, in terms of the original product and business case, that I couldn't use that money now to do something more important to me. Like it or not, your management or your customers are paying for this and you need to be able to sell to aka convince them.

Let's rephrase this to position yourself as a customer. Good old role play.

Suppose you were buying a refrigerator. And you could buy a fridge for $1000 that worked OK from Acme Corp. Or a fridge for $2000 from Acme Deluxe Fridges that looked the same on the outside and had the same technical specs, but had lower maintenance costs due to a cleaner internal architecture.

As a customer, which would you yourself buy?

And what do Acme Deluxe's engineers think is the better answer?

2
  • 5
    I'm having a hard time determining your stance on this. I think your answer is "it depends on what the customer wants". The problem is, not every customer understands that the lower cost refrigerator is going to leak melted, nasty gunk from the freezer section, make loud noises, and eventually stop working after 5 years, while the other one will run smooth and quiet for 20 years and not be replaced until it's deemed out of style by owners that will resell it in exchange for a new model. Still, I like the question you posed. It's thought provoking. +1
    – jmort253
    May 23, 2012 at 3:10
  • 1
    First line - "It has to be a very convincing argument [] that I couldn't use that money now to do something more important to me." I use the fridge example as frankly, I don't care about what goes on inside my fridge. I just want an outcome. (cold food at a reasonable price). To be blunt, I don't care if the fridge engineers think it's a better product internally. I might consult them but it's really not their decision.
    – jasonk
    May 23, 2012 at 21:56
3

"Technical debt" can be a tricky subject to present to management as they may not see the need for it. The question could be framed as whether or not there is a champion in the company to state, "Look, we are taking X% time to work on the technical debt here. Give us 3 months to show you this works well," or something similar. There is a claim towards autonomy there but also a time frame as otherwise management may wonder how long until they see some results which is rather dangerous territory.

The first point though is whether or not they see this as a problem. If the person with poor vision knows nothing of eyeglasses and what kinds of changes they can provide, how are they to understand why an eye test could be valuable? Same idea here where the subject is rather technical and not easily quantified unfortunately.

4
  • I agree with this fully and find it more and more. Recently, I've been gathering up a a list of defects that have been reopened because a proper fix wasn't put in place or defects of a similar nature. Hopefully the developers put in time spent. Sometimes they do, sometimes they don't, but this kind of data is a useful foundation for showing management how an unhealthy product is impacting their business. Apr 6, 2013 at 19:07
  • 2
    In my current workplace, overtime is allocated for the wrong reasons. If time was invested in keeping the app healthy instead of firefighting problems, money would be saved on overtime and developers would be more empowered rather than burnt out and annoyed at management. Apr 6, 2013 at 19:09
  • But the management (in most cases correctly!) sees it this way. I have a 1980s magimix which still works and your telling me to replace it just because its old and the color is unfashionable! Aug 15, 2014 at 5:06
  • @JamesAnderson your analogy doesn't really work because no one is adding new features to their magimix. In most businesses they are actively modifying and adding new features to their legacy code base. Apr 1, 2021 at 20:55
2

You should just stop complaining about it.

Here's why:

  1. They never plan to use the software longer than a year
  2. it's just waste of time tweaking it if their plan is to dump it afterwards
  3. there's some real problems that need fixing now
  4. programmers just need to learn to deal with maintainance, even if it's not always fun
  5. complaining that you know better what needs to be done is arrogant - someone else makes the decision, and you should be happy about it
  6. They anyway trust you to write good code

So best way forward is:

  1. When they give you new task, try to implement it as well as possible in the given time
  2. Write it perfectly the first time. If you need to change it afterwards, you made a mistake the first time and any change is always going to wrong direction - and it's a learning opportunity for programmers when you make mistakes.
  3. Don't ask extra time for it, you wont get it, there are deadlines you know.
3
  • 3
    I mostly agree except that it is well-known that even crappy software has a tendency to survive far longer than its creators expect. But you're right, it is better to not complain. Instead, if you see some limited-scale re-factoring that will help the comprehensibility of the code it might be worth it to go ahead and make the changes WITHOUT PERMISSION during your maintenance/bug-fixes (and incur a risk doing so).
    – Angelo
    Oct 22, 2011 at 23:32
  • 1
    @Angelo - Would it not be better to voice your concerns rather than allow the team to suffer in silence? I've seen what this problem does to team morale and also with the amount of time/money wasted on overtime. I don't see it as "moaning" as such. You are simply pointing out project risks and if your ideas can speed up delivery times and streamline processes, then why not at least try to voice your concerns? If this falls of deaf ears, then at least you know where you stand. Apr 6, 2013 at 19:13
  • 3
    You must complain about it loudly, otherwise it's your fault if other people's code break ("You knew this was a mess and didn't tell anyone ?"). Standing up and going "Hey boss, this shit will sooner or later hit the fan" is vital to keep a dev team functional.
    – Alex
    Aug 7, 2014 at 13:41
2

I take it you have never been involved in a project to re-write/replace or even upgrade and existing system.

These are some of the hardest projects to complete successfully. Some of the problems you will come accross are:

  1. Business rules are lost in time.
  2. Documentation and implementation are totally out of sync.
  3. What you see as a bug the users see as a feature.
  4. Conversely many "features" will be viewed as defects by the users.
  5. You will not get user buy in -- they will regards your "fact finding" as "nerds asking stupid questions", they will regard the testing effort as a waste of time, they will insist on adding new features thus lengthening a project will will already be behind schedule.
  6. Chances are the source code does not match 100% with the running executable.
  7. While your department is messing around refactoring development the business actually wants is not being done.
  8. Chances are that your re-factoring will involve "cleaner improved interfaces" thus dragging other projects into your quagmire of late delivery and failed tests.
  9. After the project is canned (well over 50% of these efforts fail completely) you will have lost all creditability -- you will need to move to another company in another town to find someone prepared to listen too you.
  10. If the project "succeeds" everyone will remember what a nightmare it was -- you will .......

I urge you to avoid any re-writes/refactoring projects like the plague, they can be some of the most dispiriting experiences in any professionals career.

There is much wisdom in the phrase "If it ain't broke don't fix it".

4
  • 1
    "I take it you have never been involved in a project to re-write/replace or even upgrade and existing system" - Wrong, 7 years of it. Aug 22, 2014 at 18:16
  • 1
    I completely agree that a full re-write is often a disaster. But I have three examples over the last 8 years of my career. One was a long slog that resulted in us being able to maintain the product better but provided no business value; another was a short rewrite that was a total success; the third was a decision not to rewrite, which ultimately killed the company. Choose your poison. Dec 31, 2015 at 19:52
  • This is the most negative, depressing answer I've ever read on StackExchange, would downvote if I had enough rep Apr 1, 2021 at 21:06
  • @reggaeguitar -- sorry but that is what real life is like. On a brighter note "evolution not revolution" is the way to go. One of the major banks I have an account with is running a mainframe COBOL application written in the 80's, which was ported to a Unix environment ( no source code changes!), which is now running in an AWS cloud with minimal source code changes. Just because it not the latest fashion does not stop code from working. Apr 2, 2021 at 7:54
2

For the life of me I can't understand why some people are so blindly afraid of change--it smacks of lacking confidence in your own abilities.

I watched a show last night on Yosemite National Park and it was remarked that from 1940 through the late 1990's not a single new Sequoia tree sprouted. It was discovered that the reason why was that there was a strict policy against letting forest fires to burn and that Sequoia pine cones needed the heat from fire to open and release their seeds.

You see, a fire every ten years or so was healthy. It cleared out all of the accumulated deadwood and bramble to keep healthy the existing trees (processes) and make room for new ones (features).

I am on a project right now that has a clear case for rebuild: The legacy software was written entirely using .NET webforms. Almost all of the business logic is co-mingled with HTML/server tag view logic and can not be extended into other applications now that the business has grown.

Management is behind the task because they have an appropriate amount of trust in their developers which, I realize, is a rare luxury.

Yes, ask yourself if a rebuild is truly necessary. Do your best to reuse existing code that works where you can. Integrate that code into the rebuild if necessary. Just don't let anyone convince you that being afraid of making bold changes is the only way to exist as a software developer.

Good luck!

4
  • 1
    how does this answer the question asked, "How do you communicate this to management to get them interested in sorting out technical debt?"
    – gnat
    Nov 11, 2014 at 19:17
  • 2
    @gnat: How do most of the "answers" answer that question directly? See, for example, answers by James Anderson, tp1, or any answers at the top with the most votes. But to answer your question, I provided an alternative analogy the OP can use. Seems to me that you simply disagree with my opinion on the matter. That's fine, but no reason to downvote. Nov 11, 2014 at 19:48
  • 1
    per my reading, top answer you refer appears to directly address the answer asked, based on relevant experience "When I met with my boss to discuss this..." As for your opinion I rather tend to agree with it, but I vote based on content quality, not on whether I support particular opinion or disagree. Stack Exchange Q&A voting model is quite poor when (mis)used for opinion polls
    – gnat
    Nov 11, 2014 at 19:58
  • 2
    I recommend reading it again, then. Describing a conversation had with one's boss regarding a method for covering technical debt by padding estimates for future work does not answer the question, "How do you communicate this to management to get them interested in sorting out technical debt?" either. Nonetheless, I didn't down vote the answer because it added to the conversation. So, all you have succeeded in doing is muting an opinion on the matter with which you agree for no substantial reason. "Programmers" should be a place where we can have a conversation. Not everything is binary. Nov 11, 2014 at 20:04
2

You need to give your management a financial reason to deal with technical debt, and a framework for managing reducing that technical debt.

Maintaining a technological roadmap is one such framework. Starting out with a roadmap will help you keep you from piling on technical debt, and can also help you reduce existing debt as well.

Many successful long-term projects have associated steering committees and roadmaps to guide development. These are especially helpful when there are multiple development teams and stakeholders involved.

My suggestion is that you discuss this strategy with your managers (and if possible those who make decisions on where money gets spent).

The general approach to creating and managing a roadmap are straightforward, but it does require the support of your management team. First, define a goal. Define the elements of the technical debt, and develop a target system architecture that reduces elements of your technical debt. Remember, it doesn't have to be perfect, just workable and better than what you currently are. Take into account software, development tools, hardware platforms, major new features that may be added to the system. Do a cost analysis. If you have the desired architecture, what are the tangible benefits of performing the refactoring? (Benefits would include reduced test time, more reliable software products, more predictable development cycles, etc.) If you can show enough benefits to performing refactoring, you can get management support.

Once you have a roadmap and management support, develop a series of steps (also called a plan) that you need to take to get to this desired state. It may be a good idea to put together a steering committee that maintains the roadmap, trains and educates the development teams on the roadmap, and periodically reviews changes for architectural integrity.

Roadmaps are really useful, and perhaps the 13th question on the Joel Test should be "Do you have a roadmap?"

Here is a video of the first hour of a recent Red Hat Linux roadmap session.

2

Having already been involved in a major rewrite, (not just refactor), I can agree that getting the financial guys to agree to the project was one of the major hurdles. Getting over that hurdle required me to write, present and defend a report that pointed out a number of issues that meant that the companies business was going to be dead in the water in the near to medium term.

Key factors in getting the agreement to go ahead:

  • Existing code was in a no longer supported tool chain, (MicroPower Pascal), that only ran on nearly unsupportable development platform, (PDP11-23).
  • Finding developers who could work on tools and targets was becoming almost impossible.
  • The target hardware was no longer available if spares were needed and the and the manufacturer was growing ever more reluctant to provide a repair service.
  • Issues in the code were resulting in readily identifiable customer dissatisfaction and direct servicing costs.
  • Adding new features or even bug fixes were becoming almost impossible due to limitations of the target hardware resulting in the need to refactor other areas so as to provide space when addressing issues.
  • With an 8 hour build time developing and testing any changes was costly.

The report detailed the issues, with estimates of ongoing costs, and offered 3 options:

  1. Freeze where we were with possibly not even bug fixes in the near future.
  2. Optimise the code for space only, with no regard to maintainability, pointing out that anybody attempting to maintain the optimised code would have to be smarter than whoever did the optimisation.
  3. Re-implement, with testability and maintainability as high factors, in an industry standard, widely taught, language, (ANSI C), on new, low cost, COTS hardware, (PC-104), with multiple vendors available with an in house designed interface card to allow it to work with the remaining existing hardware. Adding a limited set of new features as a part of the development such as non-volatile storage, a watchdog timer to provide automatic restart in a fault condition some units were crashing multiple times a day and requiring a £40 service call out to reset, better diagnostics in the process.

Having got the go ahead for the 3rd option my 3 month contract turned into 3 years of very hard work, both developing the new software and hardware, but with a very good outcome.

For cases with less extreme technical debt I tend to adopt what I call guerrilla refactoring:

When there is an issue with a specific module:

  1. Write a set of tests that demonstrate the problem that are also likely to fail without refactoring
  2. Refactor as a part of the development pointing out that the tests are still failing.

Not the answer you're looking for? Browse other questions tagged or ask your own question.