The Solution to Technical Debt

(Translations: Russian)


How do we feel about the quality of our code?






Now you need to ask yourselves some tough questions.

Do we want to have it this way?

If not, what do we want the code quality to be? Most developers want a quality level of 4 or 5. Yes, the scale is arbitrary and subjective but it’s still useful.

If opinions vary strongly then you need to have a discussion about what you mean by quality, and where you want to be as a team. You can use Kent Beck’s 4 rules of Simple Code as a reference point. It’s hard to fix the problem if you can’t agree on where you want to be as a team.

What is the cause of this problem?

This is just a rhetorical question, because the answer is clear.

“Things are the way they are because they got that way!” -Jerry Weinberg

Crap gets into the code because programmers put it in! Let me make that crystal clear: Crappy Code is created by programmers. The programmer uses the actual keyboard to punch the actual code into the actual computer. Irregardless of other circumstances, it is the actions of the programmer that determine the quality of the code

The first step in solving technical debt, is to admit and accept this fact.

“but wait, we inherited a bunch of crappy legacy code. We did NOT write it!”

OK, fair enough. The relevant question in that case is: “is code quality improving or getting worse?” Rate that on a 5 point scale (where 1 is “getting worse fast”, 5 is “getting better fast”). Then reapply this article based on that question instead.

Why are we producing crappy code?

The answer will vary. However, I’ve asked it many times and I see some very strong trends.

It’s probably not because you WANT to write crappy code. I’ve never met a developer who likes writing crappy code.

It’s probably not because you don’t know HOW to write clean(ish) code. The skills will vary, but it’s enough that you have a few people in the team with good skills in writing clean code, and a willingness from everyone else to learn. Combine that with a habit of code review or pair programming, and most teams are perfectly capable of writing code that they would rate a 4 or a 5, if they take the time they need.

It may be because of broken window syndrome. Crappy code invites more crappy code, because people tend to adapt their new code to the quality of what’s already there (“when in Rome…”). Once you realize this, you can decide to simply Stop It, and introduce code review or pair programming to police yourselves.

However, the most probable reason for why you are writing crappy code is: Pressure.

I often hear comments like “we don’t have time to write clean code” (<rant>that statement is at worst a lie, at best a lame excuse</rant>). The truth is, you have 24 hours per day just like everyone else, and it’s up to you what you do with it. Face it. You do have time to write clean code, but you decided not to. Now let’s keep examining this concept of Pressure.

Where does pressure come from?

You might want to do a cause-effect analysis of this. Is the product owner pressuring you? Why? Who is pressuring the product owner? Who is pressuring the person who is pressuring the product owner? Draw the chain of pressure.

Then ask yourself. Is this pressure real? Do these people really want us to write crappy code? Do they know the consequence of crappy code (I bet you can list many), and do they really think it is worth it? Probably not. Go ahead, get on your feet and go ask.

Sometimes the cause of the pressure is the programmers themselves. Developing a feature almost always take longer than we think, and we really want to be a Good Programmer and make those stakeholders happy, so the pressure builds up from inside.

NOTE: sometimes there is business sense in writing crappy code.  Sometimes technical debt is Good. We may have a critically important short-term goal that we need to reach at all costs, or we may be building a throw-away prototype to quickly test the market. But that should be the exception, not the norm. If you clean up the mess you made as soon as the short-term goal is reached, or you actually throw away the throw-away prototype, then you won’t end up with a chronic case of Code Crapiness.

Shall we decide to stop this nonsense now?

This it the most important question.

If you are a programmer, the fact that you (as programmer) are responsible for the problem is actually Good News. Because that means you are perfectly capable of Solving the problem. And the solution is simple:

Stop Writing Crappy Code

(Just what the world needs – a new acronym: SWCC™)

“but but but but but…. we don’t have time… the PO bla bla bla, our release date bla bla”

No, spare me the excuses. Just Stop It.

Well OK, you might actually decide to continue writing crappy code. You might decide that this battle is not worth fighting. That’s your decision. If so, at least don’t call yourself an agile development team, and do challenge anyone else who thinks you are agile. One of the fundamental principles of Agile software development is Sustainable Pace. If you are consistently creating Crappy Code, development is going to get slower and slower over time. There is no business sense in this, and it is certainly not agile.

But assuming that you do want to stop, let’s explore what happens.

As a team of programmers, you can take a stand: “We Will Stop Writing Crappy Code”! Write it up on the wall. Shake hands on it. Add “no added technical debt” to your Definition of Done.

Tell the world, and the people who you believe are pressuring you into writing code: “We have been writing crappy code. Sorry about that. We’ll stop now.” Trying saying it loud. Feels good!

Stop Writing Crappy Code

Look at these two curves.

Yes, this is a simplification, but the difference is real. If you Keep Writing Crappy Code, you get slower and slower over time (as you spend more and more of your time wrestling the code). If you Stop Writing Crappy Code, you get a more sustainable pace. But there is velocity cost – you will slow down in the short term.

As team, you decide how much work to pull in – that pull-scheduling principle is fundamental to both Agile and Lean. It’s built into the agile methods. For example, in Scrum Sprint Planning the team chooses how many backlog items to pull into a sprint, same in XP Planning Game. In Kanban, the team has a work-in-progress limit and only pulls in the next item when the current one is Done. Basically, the team has full power and responsibility over quality. Use the power!

In concrete terms: If you are doing Scrum, and you’ve been delivering about 8-10 features per sprint, try reducing that. Only pull in 6 stories next sprint, despite any perceived pressure. Ask yourself at each sprint retrospective. “What is the quality of the code that we produced this sprint (scale 1-5)”. If it is less than 4-5, then pull in fewer stories next sprint. Keep doing that until you find your sustainable pace.

This has business implications of course. The product owner (or whatever you call the person who makes business priorities) will have to prioritize harder. She’s used to seeing 8-10 stories come out of each sprint. Now she will only see 6-7, so she needs to decide which stories NOT to build.

Yes, this will lead to arguments and tough discussions. The real source of pressure (if there was any) will reveal itself. Quality is invisible in the short term, and that needs to be explained. Take the battle! Stand by your decision. If programmers don’t take responsibility for the quality of their code, who will?

Code quality is not Product quality

Code isn’t everything. There’s more people involved in product development than just programmers. There’s business analysts, testers, managers, sysadmins, designers, operations, HR, janitors, and more.

Everyone involved is collectively responsible for the quality of the product being built. That includes not only the code, graphical design, database structure, and static artifacts like that. It includes the whole user experience as well as the business result of the product.

Code quality is a subset of product quality.  You can have great code, but still end up with a product that nobody wants to use because it solves the wrong problem.

What about vice versa – can you have a great product, but crappy code? I hate to admit it but, Yes, technically you can build a great product with crappy code. Somehow teams seem to get away with this sometimes. However, improving and maintaining the product is slow, costly, and painful, because the product is essentially rotten on the inside. It’s a lose-lose proposition and over time the best developers will leave.

What about the Old Crap (a.k.a Legacy Code)?

OK, so you’ve stopped writing crappy code. Congratulations! You’ve stopped accumulating technical debt. You’re still paying interest on your existing debt, but at least the debt has stopped growing.

Next step is to decide – can you live with the existing technical debt, or do you want to do something about it?  If you decide to reduce technical debt, the consequence is that you will slow down even further in the short term, but speed up over the long term. Like this:

Sometimes it’s worth it, sometimes not. The answer is not obvious, it’s a business decision, so make sure you involve the people who are paying for it.

If you decide to reduce your current technical debt, make that a clear decision: “We will Stop Writing Crappy Code, and Gradually Clean Up The Old Code”.

Once you agree on this (and that’s the hard part), there are plenty of techniques for how to do it. Here are two techniques that I’ve seen work particularly well:

  1. Add to your Definition of Done: “Technical debt reduced”. That means whenever you build a feature or touch the code, you leave the code in a better shape than you found it.  Maybe rename a method to make it more clear, or extract some duplicate code to a shared method. Small steps. But if the whole team (or even better, all teams) does this consistently, code quality will noticeably improve within a few months.
  2. For the larger cleanup areas, create a “tech backlog” & reserve time for it. For example, list the top 10 areas of improvement and commit to fixing one every week or sprint, before building any new features.

Just keep in mind that, however you do it, repaying technical debt means Fewer Features in the short term. Adapt your velocity forecasts and release plans accordingly. Just like any investment, there is a short-term cost. Make sure everyone is clear on that.

You need to Slow Down in order to Speed Up.

Final words

Bottom line: code quality is the responsibility of the people who actually write the code (otherwise known as Programmers).

As programmer, you own the problem, and you own the solution. There’s no need to fret or be ashamed of the past. Instead, stand proud and use your power to do something about it – make a loud decision to Stop Writing Crappy Code. That will start a chain of events and Good Stuff will likely follow in the long term. It’s hard and it takes courage, but I don’t know any other way to solve technical debt.

Good luck!



Is technical debt always bad?

No. Having some debt can be fine. See my other article Good and Bad Technical Debt (and how TDD helps).

The problem I’m talking about here is chronic, out-of-control, continuously growing debt. I’ve seen so many companies drowning in technical debt, moving painfully slow, losing key developers, and regretting bitterly that they didn’t take code quality seriously from the beginning because it’s so much more expensive to fix it afterwards. Cutting quality gives short term benefits, but the long term is longer than the short term, and most companies do want to survive in the long term.

What is technical debt anyway?

Anything about your code & development environment that slows you down. For example:

  • Unclear, unreadable code.
  • Lack of test automation, build automation, deployment automation, and anything else that could be automated that you do manually today.
  • Duplicate code.
  • Tangled architecture & unnecessarily complex dependencies.
  • Slow, ineffective tools.
  • Uncommitted code & long-lived branches (hides problems that will slow you down later).
  • Important technical documentation that is missing or out-of-date.
  • Unnecessary technical documentation that is being maintained and kept up-to-date.
  • Lack of test environments.
  • Long build-test cycle & lack of continuous integration.


French translation

60 responses on “The Solution to Technical Debt

  1. About: ‘Is this pressure real?’ :
    yes, sometimes this pressure is real.
    In many cases managers without any connection to the technical side, imposes arbitrary deadlines on the programmers: ‘you have to finish by day x, otherwise the client won’t pay us and if we deliver later, we will have to pay compensations to the client!’.
    If the programmer refuses or tries to argue about this, sometimes he is facing only one option: to be fired, on spot, and after that to face 1 month without salary until he find (maybe) another company.
    This is the real world in many countries..

    1. Negotiate. “OK, we will do this, but we will need to reserve 2 sprints to cleaning up the mess after the deadline.”

      Nevertheless, I agree that sometimes the pressure is real. But sometimes it’s not, so it’s worth examining.

      1. maybe in your country. That is why outsourcing is so popular. Because you get code cheaper then dirt , you can treat your employees as a slaver and if they leave you can simply get others. And no they do not regret letting go of developpers until the company goes into a financial crysis. And pressure is not real sometimes is real always, especially in the agile environment.

        1. If the customer does not need maintenance, then it probably a good deal for “him”, but as Henrik pointed out, the velocity will decrease over time if you don’t do something about it and an intelligent customer would understand this…
          It is a little like if you have a stupid customer who buy a car and comes every week and require that you add a new layer of car paint on the car without taking the time to remove the old paint, the customer will eventually run into trouble (not hard to imagine) – if he is really stupid he will just buy a new car and continue all over… I believe that the quote “Insanity: doing the same thing over and over again and expecting different results.” is pretty good here… 🙂

  2. Henrik,

    This is a really great article I’ll certainly be sharing inside my company. Still, I believe there’s one business reason you seem not to account for, whereas this reason, I believe, causes a great deal of crappy code to be written.

    I am talking about the modern pace of conquering new markets and market niches, especially where the competition is fierce. While I do totally agree that a product that is rotten on the inside is a nightmare to maintain down the road, the business reality sometimes is that if you don’t release something really quick, someone else will and you will have nothing to maintain in the first place.

    Development costs-wise, there’s also considerable pressure, especially in start-ups. I hope you’d agree it takes a seasoned (and thus, expensive) programmer to write clean code quick, so if a business has a really tight budget and timeline to launch a new product, they might decide to hire cheaper and less experienced staff and go down the “quick & dirty” route just to have something up & running at the minimum time and cost.

    The above creates quite a probability for ending up in the “old crap” scenario pretty quick. Now, if the competition remains fierce after penetrating the market or it remains unknown how long the product’s life will be, I assure you no business would spend money on reinvesting in quality. This is unfortunate for us developers but nevertheless the reality of modern software development.

    1. I think that we should unite in busting the myth that junior developers are cheaper!

      IMO it takes about 5 juniors to replace 2 senior developers when it comes to producing a working solution fast. The best code is the code you don’t write, and juniors simply don’t know what code to not write!

      The other problem with juniors is that the code they produce is crappy from day one!

      As a senior, I master not only the latest hyped script language, but also a plethora of battle-proven languages, frameworks, databases and toolkits from the last 2-3 decades.

      So when it comes to producing a working solution for a startup, I’d say that hiring 2-3 so-called “expensive” seniors will be cheaper than recruiting 5-6 juniors.

      From day one, and forever. Amen 😉

      1. “The best code is the code you don’t write, and juniors simply don’t know what code to not write!”

        Thats a great anecdote! I remember when just starting out how a senior would sit with me, and make mincemeat of something I would have spent 2 days on (with mostly case statements).

        I think that time is definitely a factor, but not always the distinguishing one.
        I’ve found a senior’s cadence is more predictable, and in moments where they
        are at most 2x faster than a hoard of juniors are creating a solution with legs where as
        a less experienced team may just be creating debt.

  3. Excellent article! I totally agree with all of this, but then I got to clients still in their Agile transitions and come up against some hard realities. While pressure to write more code in less time is a definite factor to how much crappy code gets into the system, in large complex products with multiple teams, lack of communication is another one. Each team has its own mix of skill sets and experience with the current system and coupled with poor touch points with other teams they end up stepping all over each other (sometimes not even knowing it). While this can also be a side effect to pressure (“I can’t run everything I do by all of the other teams, that would take forever!”) it is also the lack of interaction. I have a client where this is happening and I found a similar approach to the one you outlined at Spotify has helped a bit with getting team members to be better at cross team and discipline collaboration.

    Do you have any good real world references to larger clients with multiple teams working on a fairly complex code base with a decent amount of legacy “crap” and the practices they put in place to turn it around? That sounds like a great follow up article!

    1. Yes, I mentioned two such practices in the Legacy Code section. I’ve seen it work nicely in a real multiteam complex legacy code situation. Took several months, but we definitely saw results.

  4. Congrats on writing this great article.
    Everything I read was exactly how I feel about it and I kept on reading to learn what arguments I could use to promote this way of thinking.
    However, then you write “Basically, the team has full power and responsibility over quality. Use the power!”.
    We are usually an agile team on most projects, and we have all achieved great things when we could truly work agile. But now we are a bunch of good agile developers, working for a non-agile customer, who couldn’t care less as long as we deliver.
    And we do deliver, but it’s costing us velocity everytime we allow our client to make these decisions (against our recommendations).

    Would you suggest to first focus on becoming more agile, so our team is empowered once more? Or would you suggest to stand strong with our entire team, and only deliver non-crappy code from now on, counting on the fact that in the end our customer will see that we deliver less bugs? Or maybe you’d recommend something completely else even?

    Looking forward to your reply.

  5. Great article Henrik!

    Those practices should be standard in an agile company. In that context the programmers own the code and have the power to deliver good or bad code. So in an agile company it is purely the responsibility of the programmers and the root cause of bad code would probably be sloppy or no refactoring, inconsistent TDD or other practices gone bad or left out.

    However in a non-agile environment I have seen the “pressure” developers talk about almost every time. It is far to often that these companies do software development planing in a deterministic fashion with fixed time and fixed scope. Under such circumstances the developers have little to play with. In fact the only component they have power over is quality which unfortunately is very hard to quantify in the short term or in the context of a single project. What is obvious to everybody outside the dev team is late delivery and diminished scope. So when the shit hits the fan no developer wants to take the blame (diminishing her individual value or security) and since quality is not visible in the short run developers use it as a buffer.

    In my experience the root cause of bad quality and technical dept is non-agile practices which very often are perceived as external “pressure”… and fixing that is probably beyond an article 🙂

  6. This is so important and it makes fantastic results. I tried it in a team and a product a couple of years ago and iterated until we had only 4s and 5s. When we reached high level of pride in the code, the team could for real work agile with continous deployment as a result, the level of work on bugs was drastically reduced = work on added value increased. And most of all, the team gained pride and kept the code clean!

    Thanks Henrik for sharing this!

    Product Manager

  7. Thanks for this Henrik. All crappy code must die! 🙂

    It is an illusion that there is anything quick about dirty. It is amazing how quickly the dirty code slows you down. After a short while you start to think that “the problem is complex” or “unclear requirements”, perhaps “bad luck” while you really is just in the mess of crappy code.

    There is a very clear difference between agile and not, when you get told a deadline or if you tell it. The latter is agile and you came up with the pressure yourself – stop whining.

    — Per

  8. Hi,

    Thanks for the post Henrik.

    One of the main problems is that technical debt affects maintainability. That is, the messy code reduces productivity, increases the time to make changes, the risk of touching code, etc.

    When we found lots of messy code in very large legacy software we have to be careful in how we conduct cleanup messy code.

    Most often it is impossible to clean absolutely everything messy code, no time or money for it.

    Therefore, we have to know how to locate the code most damaging messy.

    For example, clean code which is very messy but that takes years without being changed that does not produce great returns on investment.

    Clean code which is not very messy but on which the team works daily generate higher ROI.

    – Javier Garzás

  9. As Dmytro said, if you don’t write code fast, usually you either won’t have to maintain it (because it won’t be used) or you won’t be there to maintain it.

    This is one reason why write-fast-and-damn-the-maintenance languages are so popular. Yes, you know them, all them dynamic languages, that allow to hack any object to have it do anything at any time without having to ask anyone. Also duck typing, who cares about dragons masquerading as ducks if it allows you to get your unicorn in the pond?

    If your project is successful, you’ll have enough money to rewrite it from scratch or hire enough people to maintain it. If it fails, well, at least you didn’t invest into making a clean useless bunch of code.

    As for long running applications and existing code bases, it’s a similar opportunity cost: should you invest more in maintaining old stuff that won’t make a world of difference, or should you invest into new stuff or rewrites that can make a real difference in the future?

    Could writing crappy code be a rational choice after all? 🙂

    – Eric

  10. Good article Henrik! But I don’t agree with the part that all programmers can write good code. It takes years of experience. Many programmers have worked on a crappy codebase their whole career and even if they know that it’s crappy they just lack the experience to see how it should be improved. Cleaning up crappy code is one of the hardest challenges in software development, and if you have never seen something like what you’re aiming for it’s even harder.

  11. Fantastic article. I’ve always viewed technical debt the same way I view financial debt: going in to debt makes sense some times, but you have to manage that debt *and* pay it back. Take on too much debt, and technical bankruptcy is inevitable.

  12. great article – but missing one – in my perspective important – part that is also creating technical debt:

    YAGNI – you ain’t gonna need it
    – stuff that is there that is not necessary (frameworks, …)
    – covering potential future requirements, that will probably never come …
    – solving problems that have not yet appeared, but probably could appear …

    so it is not just crappy code, but also good code that is not required …

    but honestly … most of the time it is crappy code that is not even required … the worst of all 🙂


  13. Thanks for this article.

    I don’t think most developers intentionally start writing crappy code to be faster. Have you heard about the second system effect? Coding is learning. Learning to code and learning about your problem domain.
    Most of the time when you finished a task (implementing a story or whatever) you look back and might say: ok, If I knew what I know now, I would’ve implemented it differently. But at some point you can’t rewrite all of it. You have to deliver it.
    And who says if you rewrite it, it will be really “better”? Does it need to be 100% clean? What is 100%? You know that achieving 100% from whatever is costly. So 80/20 rule applies here. It should be good enough to work for the client and don’t give you too much headaches.
    If you ask developers if their code can be improved, there will be always a positive answer. You can always improve and find a more shiny solution. But you have to stop at some point. Otherwise you burn resources without a benefit.
    I think code reviews and pair programming help a lot to reduce crappy code in the beginning.

    1. Good point. I usually ask developers to rate their code on a 5-point scale, and then ask them where they want to be. Most say 4 is fine. That’s the 80/20 rule 🙂

      The problem I’m seeing though is people with code quality averaging around 2. That’s usually a lose-lose proposition.

  14. Great article on addressing crappy code, however Crappy Code == Crappy Code; Technical Debt == Good Code based on an admittedly incomplete understanding of a problem. These are two entirely different things. Ward Cunningham coined the “The Debt Metaphor” as an analogy for shipping solid software that represents the current understanding of the problem, allowing for the fact that you’ll learn more later (so you’re borrowing against future knowledge) and need to use that learning to revisit the design. It is explicitly _not_ about shipping crappy code. See (at roughly 3:15) to hear it in Ward’s own words.

  15. I think it’s a good measure to ask each developers how they would rate the code base. That is a good exercise. It’s also true that we tend to write crappy code sometimes when motivation is absent, as the broken window analogy explains. But I don’t think that responsibility of crappy code is *entirely* on the programmer’s shoulders and other factors are just an excuse. That might not be what you meant and I assume it’s not, but the post’s tone sounds like it. It’s too simple. David Chelimsky and Peter Storch already added more depth to the reasons:

    1- Limited resource (Kent Beck himself recently twitted the following: “coupling reduces a designer’s degrees of freedom but buys e.g. efficiency. it’s a tradeoff between freedom lost and value of what is gained.”)
    2- The code only represents the current understanding of the problem and domain. It’s the best advantage during the rewrite of an application. Although one has to be careful about the second system effect, which is *not* a positive effect, as this is a syndrome of one that wishes to make a system too perfect and falls into common pitfalls such as features creep.
    3- Team’s pool of skills and knowledge. Is there any process to even those among team members?

    I would add:

    All these new features we add to the code base does not always fit in an existing system. Sometimes, it needs coordination between team members to rewrite certain part of the application. The social skills of the team will then determine the quality of the upcoming refactoring and feature integration and this social interaction will require even more time. You can have a perfect code base at one point in time, but a new feature that seemed easy to implement will end up shaking the parts of the code base. You have 2 weeks to deliver and you can make it in that time, but you know you would need 2 months to rate your code base again at a minimal 4.

    So, feature integration and team interaction would be two more points. Sometimes, things are done in a certain way really because they had to be done this way, considering the factors that played in the past. Hacking it in 2 weeks or doing it properly in 2 months might mean the difference between a start-up ability to acquire more customers or its death. Writing sub-optimal code is not an excuse anymore but a conscious one (efficiency versus flexibility), and it does not mean it will turn out crappy, but it will increase technical debt. That is the important part I think, to be conscious about it, and then make sure to allocate re-evaluation and refactoring sessions, as pointed out at the end of the blog post and as prescribed by the agile methodologies.

  16. I’m surprised nobody’s taken umbrage with the 24 hour/day comment. Sorry, but the pay scale is set at 40 hours/week. Are you actually suggesting people subscribe to work for $0/hour to write cleaner code?

    1. I wrote “you have 24 hours per day just like everyone else, and it’s up to you what you do with it”. I’m not telling you what to do with your time, just pointing out that it’s your choice and not someone else’s. That includes both the time at work and the time outside.

  17. Hi Henrik

    the key point for me here is about ownership of the problem.

    It’s not ok for management to own the ‘tech debt’ problem. The team should own it. The programmers and the other functions should own it.

    Also I tend to think of tech debt as part of a bundle of work I like to call ‘capability building’ – things we can do to either free us to do better or speed us up – the net effect is the same – increased capability. So it is not about code quality entirely. I really like the list you have at the end.

    I also tend to favour the ‘pay as you go model’ over the negotiate a block of time to build capability. The former is much more likely to happen than the latter (which in my experience hardly ever happens). Also when I have seen teams dedicate a sprint or two to paying down tech debt, deep boredom and complacency can set in.

    Cheers and keep doing good work.

    ps. we should catch up soon.

  18. Great article! I am with you 100%. Below is my story.

    My organization (or should I say the organization I work for at the moment) has mountains (a lot) of “Crappy Code” resulting in enormous Technical Debt (we are probably at the level of our government’s debt load). There are a few primary reasons for this as I will describe below. I fear that many organization can relate to one or more (hopeully not all) of these reasons. Therefore, Is it possible to get out of the ‘Big ball of mud” mess we are in? That is a retorical question because I know the business will not pay for a complete redo.

    * Business runs the show
    According to our executive management, we are not an IT company. I beg to differ. All of our processing is electronic and the company could not operate without IT. This seems to be an excuse by many organizations to NOT make proper investments in IT. When you cut funding for IT, it hurst if not cripples the organization and the management seems to be OK with it. Makes me wonder…

    Also, Business controls our work to the degree of arbitrary target dates without consulting IT, scope creep, all the sins we know and love! And they will not listen when we try to convinvce them to change how we do things, to reduce the risk, so we can get some quality code (TDD, etc). Falls on deaf ears.

    * Overuse of Consultants
    Much of our code base was developed using a myriad of consulting companies over the past 10 years. Many of us know what happens in this situation. Consultants are like polititians, they will not be here very long so how much do they really care.

    * Employee moral
    A company that treats their IT staff like sheep in the heard will pay the price eventually. How much would you care if you worked for an organization for 10 years and got a total of 3% increase? How much would you care about Technical Debt, quality coding, etc.?

    * Code Neglect
    We are still using very old technologies, most are not supported anymore. Let’s talk about risk, scarce development resources and spider webs.

    My organization is a financial data management service and the state of our code is not good. What does this say about Corporate America? Our Financial Institutions? How does your bank measure up? Just a few thought provoking questions.

    Greed has taken over and we are all subject to it’s rath.

    I have taken it upon myself to assist in learning good coding practices, auto build and auto deploy tools and the like. When possible, I write TDD, learn now techniques, and consult with my coworkers to gather ideas. We have to take the bull by the horns and ride it out.

    I am open to comments on this. Please feel free to reply.

  19. Henrik,

    Interestingly, you do not mention the enforcement some code metrics by continuous integration, such as maximum cyclomatic complexity, function paramater count, etc.
    Only “human tools” are mentionned such as pair programming and code reviews.

    What about these automatic tools vs “human tools”?

    1. Yeah, those types of tools and metrics can certainly help, but they are only proxy indicators of quality. The key thing is the attitude of the team, and their conversations about technical debt and code quality. Once a team decides to take ownership of quality they typically start experimenting with tools like this to support the process.

  20. Good article Henrik!

    I think a lot of it comes down to habit. Make it a habit to put a proper solution in. Most of the time it is almost as fast to put a good solution in as it is to add a crappy solution. You don’t really save that much time – especially if you consider that the crappy solution most likely will have to be fixed later on. Don’t copy-paste in code and create duplication. Refactor it into a common method instead. Fixing old duplications can take a long time, but not adding it in the first place is pretty much as fast as adding it. I think it was Kent Beck that said “I am not a great programmer. I am a good programmer with great habits”.

  21. “I often hear comments like “we don’t have time to write clean code” (that statement is at worst a lie, at best a lame excuse). The truth is, you have 24 hours per day just like everyone else”

    – do you have a girlfriend or family?


  22. The flip side of this is the decision as to what is bad code can be very subjective.
    I’ve seen too many developers start on existing projects and declare it needs refactoring very early on.
    All technical debt should be justified as technical debt, it’s not enough to say “it’s hard to maintain”, a developer should be able to demonstrate why it’s hard to maintain, including trying to maintain it in the first place rather than setting to with code rewrites.

  23. Although overall a good article I do not like how all the fault is shifted from managers and Scrum Agile to the programmers. This is passing the buck. First of all let’s get some things clear:
    1. a task sometimes cannot be actually completed in one sprint. And running a task on multiple sprints raises questions to managers who do not know shit about programming and usually will get you fired.
    2. agile is designed to account for the time you spend working. If you have a long task that lasts more than one sprint you will be reprimated for not doing anything.
    3. In my country the work hours are 8/day 5days/week. How did you come up with 24 hours in a day slaver?
    4.there is great preassure from managers and so on to finish tasks in time even is crappy code
    5. The problem is with the agile system itself because it assumes some stupid things :
    a) every task can be divided successfully in subtasks
    b) independent developped subparts of a task wil assemble perfectly with poor or no initial documentation (agile documentation is work it as we go on so is beyond poor)
    c) there are no problems that arise in code development that can delay a task
    d) programmers are not humans but robots and as such we do not take into account holidays when making assesments.

    As a conclusion what I hated most what your slaver atitude when making the stupid and false assesment that there is time to write clean code. Having time to write code means allocating 2 times more time for a task than it is estimated it will take. I have yet to see an agile manager do this. In non-agile development (and no, non-agile does not mean necessarily waterfall, it actually almost never means waterfall) there are cases when managers do this, but not in the agile world.

  24. Oh yes, work 24h per day. Against the working laws and your health. You have ca. 8h per day. And a sprint oriented development is focused on features. It’s not trivial to keep the code clean in a team with vary skills and management pressure. The first interest of customers is a working software with visual changes. No customer can see the code and nobody tolerate a delay for clean code. … But anyway. This is an issue to get better day for day. – I like your charts and the fact that we have to visualize the problem. Everyone in the team has to understand it. And the management just need the time / date when a software will be done. It’s up to you to plan it with keeping the code clean. Short deadlines are generally critical and can be fail. This is the real life. – For the humans, you have to automate much to prevent human error. Like automatic code formatter, linter, etc. – You should do this during the regular working time. Do not crunch. Your statement with 24 hours is not constructive and demotivates your team.

Leave a Reply to Jimmy Royer Cancel reply

