174

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?

Desolate Planet
  • 6,038
  • 3
  • 29
  • 38
  • 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 04 '11 at 23:53
  • 1
    Why are you asking for permission to do your job? It doesn't fall on management to clean up code, you should do it for your own sanity. Whenever you touch a piece of code, you should clean it up...if for no one else's sake than your own. Stop whining about what management won't let you do and just do it. – Michael Brown Feb 05 '11 at 04:08
  • 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. – Lawrence Dol Feb 05 '11 at 04: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. – Desolate Planet Feb 05 '11 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. – Desolate Planet Feb 05 '11 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. – Desolate Planet Feb 05 '11 at 11:06
  • @DesolatePlanet What kind of position do you have in your team? Are you junior, senior, lead? And how do the engineers on your team view this problem? Are they cooperative and in agreement, or do you have incompetent slobs who are ramping up the debt and don't care (making it an issue you wouldn't be able to solve on your own unless you are the lead, e.g.)? –  Dec 11 '15 at 04:24
  • 1
    @DesolatePlanet you wont need to face such problem the day your company set a QA department. I have worked for customers with QA deps whoes didn't accept to release our applications if they didn't meet QA requirements first. And the condition for to be paid was, to be able to deploy it in production. No QA, no money. No money, unhappy manager and dev team looking for a new job. It's also about the culture of the compay. If company doesn't care about the QA, **Why shall you?**. You do it because **you are a good technician** but it's not a battle you can win alone.Choose your battles well – Laiv Apr 15 '16 at 13:38
  • 1
    @laiv, unfortunately based on almost 9 years of working in various IT companies from small development houses to large investment banks, I've never seen a successful QA process applied. I'm not arguing that none exist, but even in the places where I have seen a QA team/process, they tend to get pushed to the side when emergency releases, bug fixes for impatient customers etc emerge. – Desolate Planet Apr 15 '16 at 18:24
  • 1
    Then, may be, it's time to look forward and see another possibilities. New challengs. There're companies where the way you see your job fits perfectly. Just matter of willing and time to look for them ;-). Value yourself! – Laiv Apr 15 '16 at 19:09
  • Think about what is in it for them: speak there language. They are not interested in staff moral. Show them how you can speed up delivery time, and reduce costs, by improving quality. To do this implement the boy scout rule, of leave the bit you worked on tidyer than it was when you arrived. But don't try to tidy the world. – ctrl-alt-delor Apr 08 '17 at 22:00
  • This seems more political than technical. If I were you, I would keep a registry of issues and time required to solve them. then after a few months, plot a chart and pop it on a slideshow for the next meeting. – A.Rashad Aug 21 '17 at 15:59
  • I completely agree with @LawrenceDol statement and Michael Brown's point of "Whenever you touch a piece of code, you should clean it up...if for no one else's sake than your own." However I can't find much info on strategies to best deal with other developers who keep adding technical debt to the codebase. – Programster Feb 21 '18 at 13:10

17 Answers17

211

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.

jmort253
  • 9,317
  • 2
  • 35
  • 63
  • 34
    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. – Ken Henderson Feb 05 '11 at 03:28
  • 1
    Agreed. A good technical manager or team leader knows this needs to be done and makes allowances. Code always tends to be written... ok... added / patch / modified / enhanced, generally quickly and getting cruftier as time passes. Eventually it reaches a point where a mop and bucket and some sanitation is needed. The REALLY IMPORTANT point is that above the level of the boss who knows all this, the ones above don't know. And if you explain it they still don't know, or care or understand. So don't tell them. Just do it. – quickly_now Feb 05 '11 at 04:05
  • 2
    I was lucky to have members of management who have Computer Science degrees and experience programming. As a project manager, I've found myself pushing more on production instead of the code and can understand where my managers were coming from a lot better now. In this role, I tell my developers to refactor as they go and just make it part of their normal process. Don't even tell me about it, just do it :) – jmort253 Feb 05 '11 at 07:13
  • 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. – JBRWilkinson Feb 05 '11 at 09: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. – Desolate Planet Feb 05 '11 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. – Matthieu M. Feb 05 '11 at 19:02
  • 1
    @Mathieu - Good point, but as I mentioned in my answer, this will never be perfect. Programming is like living in a bad economy with no money, you are going to accrue some debt. However, by tightening your belt, you can help prevent it from growing too quickly. Cost will always play a part in refactoring decisions, and the decision must be weighed against advantages, disadvantages, and the opportunity cost of spending time on X in lieu of Y. – jmort253 Feb 05 '11 at 20:27
  • 6
    The issue is when some refactoring that is required is large enough that it can't just be tacked on – Casebash Oct 26 '11 at 12:44
  • 2
    +1 for giving it a financial context. This is something that executives understand. – Nathan R Nov 05 '14 at 18:05
  • It's fine that he said that, but does the company reward quality or do they reward speed above all else? – kevin cline Nov 11 '14 at 21:30
  • 1
    It doesn't work well for me, being the single developer on the project, the boss can't understand why it takes me longer and longer to finish tasks, and I'm not even refactor much, because I don't have time, it's just because the old technical debt. – Iulian Onofrei Mar 04 '15 at 09:21
  • 2
    @DesolatePlanet Sounds like you could make better use of the [Scotty Principle](http://ipstenu.org/2011/the-scotty-principle/) – Zibbobz Jun 08 '15 at 16:56
  • This problem is always best solved proactively in the interview process. If code quality is important to you ask about it. Ask a potential employer how they deal with technical debt, ask them about their testing process, ask them how important code quality is to them and then ask for examples to prove it. Most importantly, if the answers are not up to your standards, politely say I'm sorry, but you don't write the quality of code I wish to work with, explain why, and wish them as good day. – backpackcoder Jan 10 '17 at 09:52
  • 2
    Similar to what my company does - we allocate a few days per monthly version to refactoring and optimization. You can really spend forever refactoring, but the timeboxing makes us focus on the important ones. – Muz Jul 03 '17 at 05:25
52

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.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
Bernard Dy
  • 3,188
  • 26
  • 33
  • 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 02 '21 at 22:58
47

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)
Nicole
  • 28,111
  • 12
  • 95
  • 143
  • 8
    +1, although I think the last bullet should be "The good/best team members are leaving" – Ken Henderson Feb 05 '11 at 03: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 '11 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 '11 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 '11 at 17:13
  • 4
    And sometimes it's not technical debt at all, it's just a mess: https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt – TrueWill Jan 13 '14 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.

Simon East
  • 103
  • 4
Karl Bielefeldt
  • 146,727
  • 38
  • 279
  • 479
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.

Péter Török
  • 46,427
  • 16
  • 160
  • 185
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.

biziclop
  • 3,351
  • 21
  • 22
  • 5
    +1 But those 9-5 developers, well, you want the revolving door for them, ideally with some form of accelerator. – Orbling Feb 05 '11 at 00: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...". – quickly_now Feb 05 '11 at 04: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 08 '11 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 08 '11 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. – Mario T. Lanza Jun 19 '14 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?"

Orbling
  • 5,696
  • 1
  • 32
  • 38
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.

EricSchaefer
  • 2,091
  • 1
  • 17
  • 30
  • 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" – Lawrence Dol Feb 05 '11 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.

mindcrime
  • 520
  • 4
  • 6
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.

BЈовић
  • 13,981
  • 8
  • 61
  • 81
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?

jasonk
  • 1,693
  • 1
  • 11
  • 9
  • 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 '12 at 03: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 '12 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.

JB King
  • 16,795
  • 1
  • 40
  • 76
  • 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. – Desolate Planet Apr 06 '13 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. – Desolate Planet Apr 06 '13 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! – James Anderson Aug 15 '14 at 05: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. – reggaeguitar Apr 01 '21 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.
tp1
  • 1,902
  • 11
  • 10
  • 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 '11 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. – Desolate Planet Apr 06 '13 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 07 '14 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".

James Anderson
  • 18,049
  • 1
  • 42
  • 72
  • 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. – Desolate Planet Aug 22 '14 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. – Tom Harrison Jr Dec 31 '15 at 19:52
  • This is the most negative, depressing answer I've ever read on StackExchange, would downvote if I had enough rep – reggaeguitar Apr 01 '21 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. – James Anderson Apr 02 '21 at 07: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!

Matt Cashatt
  • 3,315
  • 5
  • 24
  • 35
  • 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 '14 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. – Matt Cashatt Nov 11 '14 at 19:48
  • 1
    per my reading, [top answer](http://programmers.stackexchange.com/a/43967/31260) 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](http://i.stack.imgur.com/mOFCT.png "example") – gnat Nov 11 '14 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. – Matt Cashatt Nov 11 '14 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.

Jay Elston
  • 2,680
  • 22
  • 30
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.
Steve Barnes
  • 5,270
  • 1
  • 16
  • 18