back to article Dirty code? If it works, leave it says Thoughtworks CTO

Dirty code is a fact of life, and working out which software really needs changing and leaving the rest will help many IT organizations gain at least some of the benefits of going Agile, ThoughtWorks’ CTO told the Continuous Lifecycle conference today. Keynote speeches at software conferences often paint grand visions for …

  1. getHandle

    Wow, she really is a thought-leader

    In stating the bleeding obvious.

    1. Anonymous Coward
      Anonymous Coward

      Re: Wow, she really is a thought-leader

      otherwise known as "If it ain't broke - don't fix it"

      1. Swiss Anton

        Re: Wow, she really is a thought-leader

        10 But this new stuff is shiny, and new, and it will be much much better if you take the hit of refactoring you code to use this shiny new glittery stuff.

        20 Rework code,

        30 Find inexplicable bugs caused by new stuff

        40 Google "I'm having this problem with new stuff"

        50 About 360,000 results (0.60 seconds)

        60 All say variants of "Help, I'm having this problem with new stuff". None have any solutions.

        70 Eventually get bugs fixed by luck and educated guesswork

        80 Wait three months

        90 Goto 10

        1. Anonymous Coward
          Anonymous Coward

          Re: In stating the bleeding obvious.

          Sadly in most of the places I've worked recently the things you call bleeding obvious need pointing out continuously.

          And if making code readable is such a bleeding obvious benefit why is so much of the code out there so difficult for a human to parse?

          1. Prst. V.Jeltz Silver badge

            Re: In stating the bleeding obvious.

            its not called code for nothing!

            Most high level languages seem pretty readable to me - a lot more than various human languages like %any except english%

            I mean whaddya want, something more like this:

            10 open that file bruv, the one with list

            20 go through it , check each entry innit

            30 drop a printout on me desk, giving me the skinny on each thing.

            40 chill

    2. SuccessCase

      Re: Wow, she really is a thought-leader

      Seems to me she is just regurgitating Joel on Software's seminal advice. Old code always looks like inelegant bad code, but it rarely is because it is also something the value of which developers who want to use the latest tools, language advances and code patterns tend to massively underestimate; Debugged code.

  2. Stevie


    Excellent advice.

    In the same vein:

    There's no need to stop for petrol if you have enough in the tank to get you there and back again.

  3. JimC

    And what's the potential security hole risk of the dirty code?

    1. wolfetone Silver badge

      You can have security risks with clean code, you do know that don't you?

      1. Anonymous Coward
        Anonymous Coward

        Clean vs Dirty code

        The dirtier the code the harder it is to find those Zero day exploits.

        One contractor I worked good number of years ago with delighed in making the code he wrote as hard to read and understand as possible. If he could make the code fit on one line then he'd do just that. One application was written with no line breaks. Back then, peer code reviews were just a pipe dream.

        The Support team hated him so much that for years after he moved on, they had a dartboard on the wall in their part of the office. His mug shot was there with darts sticking out of it. anyone finding 'holes' or 'undocumented features' in his code was entitled to vent their anger by throwing darts at him

        He was last heard of in Kiwi land doing the same down there.

        1. Prst. V.Jeltz Silver badge

          Re: hard to read and understand as possible.

          whats the point having it then? may as well just delete it once its been compiled.

          1. wolfetone Silver badge

            Re: hard to read and understand as possible.

            "whats the point having it then? may as well just delete it once its been compiled."

            Some people (I confess to being one of them) argue that it's better to write code that can be thrown away than to continually change and tinker with existing code due to time and cost restraints.

        2. Doctor Syntax Silver badge

          Re: Clean vs Dirty code

          "One application was written with no line breaks."


  4. This post has been deleted by its author

  5. m0rt

    Dirty code?!

    mmmm. Dirty code means what kind of code, exactly? I mean this could be anything from just a pain in the arse to read and back to front logic for most people, or it could be dangerous code that doesn't handle certain conditions well and introduces shite into your data. This smacks of soundbitiness.

    1. AndyS

      Re: Dirty code?!

      Dirty code like Bobby Tables' school used?

      Actually that was probably perfectly clean, easy to read code. Just take the user input, and pass it straight to the database. Could be done nice and simply in a single line.

    2. Valerion

      Re: Dirty code?!

      In my current place of workship, Dirty Code is "anything written before the current development manager started".

      Even today, a request was discussed to add a new field to an existing screen. But because that screen doesn't look great (it's only used internally so nobody cared about making it look good), and is written in older tech, the decree has been to re-write the entire thing into <insert today's new technology>. So the job has become about a week instead of about 3 hours.

      1. Anonymous Coward
        Anonymous Coward

        Re: Dirty code?!

        In my experience there are often "developer" and "support" people's different approaches to fixing or enhancing code written by someone else.

        The "developer" writes a large blister patch based on how they would have implemented the whole thing. This often leads to unintended side effects.

        A "support" person gets to understand the code - and often finds that it only needs a tweak. This is then coded with a method in the spirit of the original,

        On numerous occasions I had to rip out a colleague's large blister patch that had produced new bugs. It took time and effort to understand exactly how the original code worked - and why it failed in a particular case.

        1. Doctor Syntax Silver badge

          Re: Dirty code?!

          It sounds as if neither the original nor the maintenance developer believed in self-documenting code: comments and meaningful names.

      2. Doctor Syntax Silver badge

        Re: Dirty code?!

        "But because that screen doesn't look great (it's only used internally so nobody cared about making it look good)"

        That's not a good excuse if it leads to errors on data entry.

  6. Bibbit

    Oh oh.

    They're back.

  7. Spoonsinger

    Umm... (thought they had died out for a bit),

    You know when a sphere of human endeavour become 'in vogue' in the 'common' sphere. You get a fucking bunch of know nothing arseholes commenting and generalizing on something they don't know anything about and getting paid for it in conferences - and then their ramblings are quoted in the media.

  8. Dan 55 Silver badge

    She's not heard of technical debt

    Come back in 5, 10, 20 years when you've got an unmaintainable mess and say you were right not to refactor.

    1. asdf

      Re: She's not heard of technical debt

      See OpenSSL. Actually pretty amazing what Silicon Valley and many others have done to clean that shit pile up (as for much of its sad sack legacy API well um yeah going to take quite some time if ever to slay that unholy mess).

    2. Kernel

      Re: She's not heard of technical debt

      Part of my job involves fault finding on systems involving a number of integrated servers and applications to produce a single product - this is probably close to 20 years old now, with continuous updating and development during that time and I suspect very little code from earlier versions has been cleaned up.

      We're now at the point where there are so many errors, especially Java errors, in the logs that quite often the only way to tell if an error is relevant or not is to look at a functioning instance and try and work out which errors can be expected and which are not just a result of normal operations.

      Add to that the vast number of code blocks, still present, that apply to obsolete hardware and deprecated processes (or even integrated applications) which result in duplicated config files and dead ends - well, you end up with a nightmare to maintain, but it's all ok, because development cost has been minimized.

      1. cbars

        Re: She's not heard of technical debt

        ah, you work for Oracle

    3. SVV

      Re: She's not heard of technical debt

      "The pragmatist says ignore it, it’ll go away"

      the author obviously hadn't any concept of technical debt when this sentence moved from their brain to their fingers and the keyboard. Sort of like a small child covering their eyes and thinking they're invisible.

      Meanwhile. back in the real world profits are evaporating at an ever increasing rate as the "if it ain't broke domn't fix it" motto continues to be misinterpreted as "if it's a pile of incomprehensible rubbish, but generally works most of the time and we can muddle through, despite the huge cost of maintaining it, don't fix it".

  9. Version 1.0 Silver badge

    Oh cool, so I can keep on used IE4, she's an industry leader and said it was OK. Wait a moment, I just got a call from my bank - the wife says I just bought a new car in China.

    1. veti Silver badge

      Did you read the article?

      Although I suspect IE4 might actually be quite secure. Have you tried logging in to your bank with it?

  10. Herby

    When things get old...

    You just want to wash your hands of it all. The problem is that if you work on code over time that has accreted parts here and there from increasing requirements, you just keep pounding away at adding little things here and there, and the ball of string just keeps getting bigger and bigger. Yes, it works, but very few people "understand" it, or what is going on.

    I suspect that eventually you get shortcuts compiled in, and underground cheats (see VW). Those that actually need to RUN the software and understand its error messages and their context (to correct the environment as necessary) just need to muddle through.

    It is a tough life but we all persevere somehow.

    Don't even ask what software I am relating to, let's just say it is BIG and COMPLEX and EVOLVING, all at the same time.

    Oh, at one time I drove a nice grey VW bug (it wasn't THAT dirty!).

  11. hellwig


    What I got out of this was A) If you don't need to fix the code, don't fix it. B) Hopefully by the time you need to fix it, you don't even need it, and C) Maybe someone else will have fixed it so you can fix it when you need to fix it.

    Or in other words:

    Step One: Ignore Dirty Code

    Step Two:

    Step Three: Dirty Code is fixed.

    1. Doctor Syntax Silver badge

      Re: What?

      D) You'll have changed jobs and it'll be someone else's problem.

      Back in reality - that big hairball you were hoping to replace instead of fix is still needed and you've just been sent a requirement to make a little change in it. Just a little change. Nothing to worry about...

  12. Anonymous Coward

    Blame the lowly IT functionaries

    "This fits in with a world where lowly IT functionaries could not hold up change anymore, but where businesses were demanding systems work the way the business did, she argued."

    It's the lowly IT functionaries that manage to keep things moving despite interference from management types, who require yet another meeeting to decide nothing at all, who won't cross the room to talk to one of their lowly IT functionaries.

  13. a_yank_lurker

    Real World

    Often in the real world, refractoring or rewriting old code sounds very good. But the problem is the revised/new code still needs to be thoroughly tested and verified which is not a trivial task. Thus, code clean up could end up being a bigger mess than leaving the gnarly, dirty code alone.

  14. Anonymous Coward
    Anonymous Coward

    Reminds me of one of the "Doctor in the House" books. Top surgeon Sir Lancelot Spratt tells a young doctor - "It takes two years to learn how to go into the human body - and a lifetime to know when to stay out".

  15. Anonymous Coward
    Anonymous Coward

    When "Quality" was all the rage - the managers complained that we were over-engineering by writing open-ended code. Invariably the customer use changed in a way that vindicated having the flexibility to accommodate it.

    It reminds me of someone discussing their very successful OO implementation of a POS terminal. He said that it worked because their previous systems had taught them all the wrinkles that the customer might need. If you don't understand the customer's needs thoroughly - then you can paint yourself into corner with a "precisely engineered" design.

    Tom Peters had a story in one of his books about several companies producing various major assemblies for a successful missile system. They defined the interfaces between them in a flexible fashion - rather than trying to tie everything down to the last detail.

    I have always been a woodworker rather than a metalworker. Cut the joint close enough - then gently tap it home.

    There were problems in WW2 when it was discovered that some components didn't fit together - although they had been accurately machined to the same specification in the USA and UK. It was discovered that the countries' imperial standard measures were slightly different.

    1. Doctor Syntax Silver badge

      ' If you don't understand the customer's needs thoroughly - then you can paint yourself into corner with a "precisely engineered" design.'

      This, a thousand times. At my last client one of the internal bods - who should never have been let loose on a database let alone design one - came up with a schema closely tailored to the initial requirements. When I retired they were still having to amend that schema and the supporting code every time there was an amendment to the contract.

  16. GrapeBunch

    Dirty as opposed to clean?

    I thought that dirty code was stolen code, as in the code whose functionality you need to replicate using "clean room" methods. So what is "dirty code" in this context? Code written to standards that are no longer fashionable?

    I wrote a program suite in CB-80 to run in CP/M. When the time came to recompile this for CB-86 and DOS, my successor was pleasantly surprised, he needed to change only a couple of lines out of thousands. When "the competition" decided to advance to a new platform, they were down for about nine months. Was my code "cleaner"? No, we were lucky.

  17. ecofeco Silver badge

    Mile high pile of bollocks

    And so are most of the comments here.

    1. ecofeco Silver badge

      Re: Mile high pile of bollocks

      4 people who didn't actually read the article.

      You don't work in IoT by any chance do you?

  18. Moosh

    Agile development hype

    Is it really safe to be agile in certain areas, though?

    Say I work for an automatic enrolment pension company who, despite having millions of members, has still yet to see the largest waves of member enrolment, as that will be when the smallest businesses are rolled into the scheme in 2017.

    We keep to an incredibly strict waterfall timeline and have to keep up clear audit trails through every step of our software testing processes, from design to execution to defect management. We're rapidly reaching a point where we could expect 50+ thousand member enrolments a month.

    Would it be safe for us to adopt an agile process, taking on the burden of low or inadequate documentation and testing of a questionable depth? I can see it being fine for a small city bank rolling out an optional app to about 300k people (an agile project a friend is currently working on), but for the largest automatic enrolment pension scheme in the country? I can't see us developing and testing a new method for members to retire in a single agile sprint. I guess the argument can be made that the continuous incremental and iterative lifecycles allow for constant updates to be made in the case of issues being found... But does that not also apply to issues being introduced? If we find a production incident now, we have a very clear line of traceability to see what went wrong and where, and the issue is then dealt with outside the normal testing lifecycle ASAP (though still with a clear audit trail).

    Sometimes I feel like "Agile" is just an 80's buzzword and I really do think its just jumping on the bandwagon in a lot of instances. Though this is from the point of view of a tester, not a developer, and also from someone who is in an environment where the "customers" cannot just change their mind about what they want or the suitability of developed software.

  19. Fruit and Nutcase Silver badge
    Paris Hilton

    Just remember Knight Capital

    Something new, something old...

    #16, #26

    Clean or Dirty? I'll just ask Paris

  20. The Mighty Biff

    I thought the point she was making was don't make changes for change's sake? If the code is insecure or buggy or unsafe, then change it, but if it's a mess and is working, don't touch it until you have to. I would imagine that most gainfully employed folk don't have time to go around changing code that functions perfectly well. And imagine the joy you'll experience if your shiny new version has bugs in it!

    1. Dan 55 Silver badge

      Where I work there are probably over a hundred hand-tailered slightly different versions of the same 20 year old software for each customer installation. It's a mess and it's becoming unmaintainable.

      There's a new platform which is supposed to save everything, however it's Java and it's not high transaction so customers are rejecting it. They probably went with Java because of Java schools producing Java devs by the bucketload. Again, low dev costs and whatever problems come up will be fixed in the future (except they won't).

      Agile promotes this, "just do enough now to get it out the door" instead of writing quality code now which can cope with future use cases. Layer on layer, over years, until you're stuck. It's shit.

      1. billat29

        It's a mess but it's where your value is. All those different versions, patches, tweaks and kludges represent 20 years investment in understanding what your customers do and all those odd exceptions, minor cases and other surprises that have come up over the years.

        The myth that we all subscribe to is that you can sit down with <user> and apply <methodology of the month> and you will produce a complete new shiny system that will cover all those cases.

        And one that won't be technologically obsolete by the time you finished it

        1. Doctor Syntax Silver badge

          "The myth that we all subscribe to is that you can sit down with <user> and apply <methodology of the month> and you will produce a complete new shiny system that will cover all those cases."

          An alternative approach is to sit down and ask what's the general problem of which this current requirement is an example. It's the basis of the most widely used software, otherwise you'd have compilers only capable of compiling helloworld.c and operating systems only capable of running them.

      2. Anonymous Coward
        Anonymous Coward

        " It's a mess and it's becoming unmaintainable."

        Known as "the spinning plates" problem. Too many plates that need to be kept spinning when there is a common change to apply.

        In one company it was called "the cream problem". The "cream" boxes proved extremely versatile as a base for customers' special requirements. The applications could be quite different - but they could use the same basic box, hardware, and much of its firmware. That meant development time and costs were reduced significantly - but the tree of versions gradually expanded.

      3. Kernel

        "Where I work there are probably over a hundred hand-tailered slightly different versions of the same 20 year old software for each customer installation. It's a mess and it's becoming unmaintainable.

        There's a new platform which is supposed to save everything, however it's Java and it's not high transaction so customers are rejecting it."

        I have a feeling you and I may work for the same company.

        Your name's not Sam, is it?

  21. Anonymous Coward
    Anonymous Coward

    Story about bad code, picture of a 'suspected' pedo/child abuser

    Not sure the picture matches the content, although I am sure they were going for the dirty car as an analog for dirty code, Mr Allen (who has had several accusations of child abuse from various locations) is bad code that should be removed.

  22. HmmmYes


    The quality of code from academics tend to be much worse than code from any long-ish running company.

  23. HmmmYes

    Problem here, as elsewhere, is too much concentration on the implementation. Totally naive. Bullshitter.

    As someone who, for ltast 20 odd years, has effectively been a programmer, I dont worry too much about the language - bit of whitespace here, white space there, they are all much of a muchness (apart from Java which is shit and being used for something for what it was not designed for i.e. only programming set top boxes. Oh and PHP too. Junk).

    What care about is how a system is put together. Is there some sort of structure, where I can pull bits out and swap them in and out.

    How can I test something? Does the system make testing easy?

    Is there a control system in place? As soon as something leaves the door, can you rebuild a previous release easy? Is there versioning - at the software and the product level?

    1. quxinot

      >She said her career has spanned academia and the “real world.”

      Academia has almost exactly nothing to do with the 'real world'. Smells like a marketer.

  24. Christian Berger

    The problem is, often it's to late when you know you need to change it

    Considering that there can be severe security related bugs in said dirty code, it makes sense to regularly clean up code you cannot understand.

    If someone else finds a security bug in your code, it's to late.

  25. kmac499

    Rules of Code Club

    Requirements will change, definitely before you've finshed, usually before you've begun.

    Requirements will change, did I mention that? hardcode nothing.

    Elegance maybe satisfying, Payday is better; know when to stop twiddling.

    The one who will support your code in five years time is a homicidal maniac who knows where you live.

    Good code is like good driving; defensive; everyone else is out to get you so deal with it.

    Copy and Paste is the Enemy of the people, don't do it, that's what functions were invented for.

    Software is never finished, it is always a work in progress.

    Software is never released, it escapes.

    LIve by these rules or forever be condemned to rewrite management reports ad nauseum..

    1. Anonymous Coward
      Anonymous Coward

      Re: Rules of Code Club

      Early in my career my boss once said "I should fire you because you are slower then everyone else. The problem is - when you have finished - it works as it should".

    2. Doctor Syntax Silver badge

      Re: Rules of Code Club

      Development is the process by which software enters the longest part of its life cycle, the maintenance phase.

  26. This post has been deleted by its author

  27. JustNiz

    This is wrong thinking. You wouldn't build a house on a bad foundation, so why would you do so with software?

    Follow this "dont fix bad code" strategy long enough and you get to a point where even small changes take months, have a very high risk of unanticipated side-effects, and eventually even management are forced to agree that the whole system needs totally rewriting at massive cost.

    The problem is that if the code is bad then so are its interfaces, and so are its side-effects. If you have some shit code somewhere in your code it always ends up forcing bad behaviours through the whole rest of the code in a sort of viral way.

    How many times have we been forced to add new code in some screwy way just to comply to some fucked-up underlying code rather than fix the actual problem. So now you just have even more shit code. Not fixing the underlying bad code is just kicking the can down the road to a much larger problem later. I've already lived through it at several different companies that all thought they were being 'smart', and every time they learn their lesson the hard way.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like