back to article A developer always pays their technical debts – oh, every penny... but never a groat more

Picture the scene: you're a developer looking at someone else's code for the first time, and you can see that a lot needs changing. Performance bugs mean it won't scale for much longer. The code design makes it difficult to port to another language, which is going to cripple that Latin American business expansion. Its …

  1. Anonymous Coward
    Anonymous Coward

    CEOs are fed up with their jobs being at risk because some programmer screwed something up

    Meanwhile, in the real world, programmers are fed up with their jobs being at risk because the CEO ... screwed the company | decides to cut costs | outsources them.

    1. fandom

      Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

      But the point is that is it always someone's else fault

      1. 0laf

        Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

        Well that strategy worked well for Trump

    2. Claptrap314 Silver badge

      Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

      Really? Just how many CEOs have been fired for reasons that could be traced to such a thing? I've never heard of it. Heck, you need to be an Experian-level ****-up to get fired at all. And anyone want to put odds on whether or not the programmers had been screaming bloody murder about problems for months or years before this went done?

      1. Anonymous Coward
        Anonymous Coward

        Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

        It's much easier to identify a good developer than it is a good manager. We can quantify features delivered and reliability of code, but measuring the effectiveness of business decisions, that are mostly implemented by other people, is tricky.

        Finding a competent team of management to work for is tricky. I found one about 15 years ago and stayed with them for 10 years. As in all areas of business, if you can find competent people you can trust to work with then stick with them!

    3. paulf
      Mushroom

      Re: CEOs are fed up with their jobs being at risk because some programmer screwed something up

      This aspect of the article goes on to say, "The liability issue makes technical debt a governance issue. "CEO jobs are on the line for something that they don't even begin to understand," Curtis points out."

      Perhaps if CEOs spent a bit more time understanding how their fucking company achieves the things they bill customers for and less time on the golf course they would better appreciate what their Devs (and other employees) are up against. To moan about a CEO being blamed for something they don't understand and not holding the CEO at least mostly responsible for not understanding it in the first place is absolute bollocks.

      I'm not saying a CEO in a business with many disciplines should be a crack kernel coder (nor VHDL author or whatever) but they should at least appreciate what coding involves and how Dev work their magic to write software. Only then will a CEO understand why cutting this corner or outsourcing that team causes pain far beyond saving a few beans.

      At the end of the day the CEO is ultimately responsible for what happens (or not) in a company. If you, as CEO, can't explain why the merde hit the fan then it serves you right and don't let the door hit you on the arse as you leave.

  2. Aitor 1

    Critical job and payment

    So they do recognize that they have quasi random ppl building the critical parts of the company.. yet fail to grasp that tight control should be applied.

    And worse still... the payment still goes to eh PHBs, not the architects of the company..

    We obsiously have a huge disconnect.

    1. This post has been deleted by its author

  3. Pete 2 Silver badge

    If it was hard to write, it should be hard to understand!

    > he points out that a developer's familiarity with the code, rather than the code itself, would affect the level of technical debt based on that measurement.

    The greatest amount of technical "debt" is the lack of documentation. Whether that is a complete lack of it or - often worse - stuff that is out of date but looks right. At least when you have nothing, you won't follow the assumptions implicit in what was written down. And documentation isn't just about explaining what the code does, or what the author thinks it does. It isn't even about what the designer hopes it will do.

    It is also about preserving the thought process of why certain design / code / implementation decisions were made. Sometimes some unbelievably bad ( or obscure - frequently the two are indistinguishable ) hacks come about due to limitations that were discovered during development, but that nobody thought to record for posterity. And as well as describing the method that works it would be kinda handy to know what other approaches were tried and rejected.

    1. myhandler

      Re: If it was hard to write, it should be hard to understand!

      Nice idea but who's going to pay for all that documentation?

      (not talking about comments, talking about a full description and record)

      On many projects it will need to be continually updated.

      Over the long run, let's say 5 years, while that cost should be justified, it does load that cost to the front of the project.

      1. Doctor Syntax Silver badge

        Re: If it was hard to write, it should be hard to understand!

        "Nice idea but who's going to pay for all that documentation?"

        As ever, the correct question is "who's going to pay for not having it?".

        1. Aitor 1

          Re: If it was hard to write, it should be hard to understand!

          Not the person who did not write it.. or mostly not that person.

          Yo can also write useles documentation that passes al the requirements...and keeps the less skilled person in the team with a job (albeit a thankless one)

      2. Pete 2 Silver badge

        Re: If it was hard to write, it should be hard to understand!

        > Over the long run, let's say 5 years, while that cost should be justified, it does load that cost to the front of the project.

        True, but if the cost was front-end loaded, maybe we would only get software projects that were actually worthwhile?

        Whether that would be a good thing - for whom: the programmers or their employers - is part of the never-ending debate

        1. Claptrap314 Silver badge

          Re: If it was hard to write, it should be hard to understand!

          This thread seems to only accidentally touch a critical issue: documentation of code itself generally is technical debt. Allow me to explain.

          One of the basic rules of XP is "Don't repeat yourself." This is a central tenant of maintainability. The code itself is already a communication. According to Knuth, successive programmers should be the primary targets of this communication. Documentation outside the code source is a second communication. This is why in much of the ruby community, documentation is considered a code smell. "If you need to explain it, you need to simplify it."

          The Apprentice/Journeyman/Master distinctions matter. Documenting the business case that lead to a particular implementation is a very different matter. Doing this can help later programmers understand when things really have changed.

          Of course, for real-time code, or for the implementation of complex algorithms, the balance changes. But even then, the correct solution is likely to be pointers to timing analysis work and or algorithmic descriptions.

          1. A K Stiles
            Coat

            Re: If it was hard to write, it should be hard to understand!

            "One of the basic rules of XP is "Don't repeat yourself." This is a central tenant of maintainability."

            Sorry, I think the word you are looking for is 'tenet'. I only point this out because another tenet of maintainability is clarity of communication.

            going now...

            1. Claptrap314 Silver badge

              Re: If it was hard to write, it should be hard to understand!

              Ouch. Well and truly done, sir.

          2. Anonymous Coward
            Anonymous Coward

            the ruby community, documentation is considered a code smell

            How incredibly convenient for them

            1. Milo Tsukroff
              Pint

              Re: the ruby community, documentation is considered a code smell

              How convenient, indeed. Job Security. This whole thing about "The interest is the ongoing IT cost that those flaws are generating." is what Job Security is all about.

              Well-written code with well-written documentation leads to ... wait for it ... Programming jobs becoming redundant. I've done that to myself, so I should know.

            2. Claptrap314 Silver badge

              Re: the ruby community, documentation is considered a code smell

              Taken out of context, you can reverse meanings! Most excellent job, sir.

              Now, let me say it again:

              The work of simplifying code is _hard_. It requires effort and discipline. It much easier to write an explanation somewhere (and call it documentation). But... the low road is not the road to long-term success.

              If your code needs an explanation, then what it really needs is to be simplified.

              The above line precisely matches the pattern of "code smell".

              If you disagree with the claim "simplifying code to the point that it does not require an explanation is better for code health than explaining complicated code", I would very much like to see why.

      3. Anonymous Coward
        Anonymous Coward

        Re: If it was hard to write, it should be hard to understand!

        "Nice idea but who's going to pay for all that documentation?"

        The same people who've commissioned the software, since to any real dev, documentation is part of the product being built. I am currently working in a place where documentation is avoided - our documentation system has been down for a month and nobody (but me) cares.

        "Over the long run, let's say 5 years, while that cost should be justified, it does load that cost to the front of the project."

        Yes, if the person requesting the software doesn't understand that, then explain the article to them : If we do not incur this cost now, you'll incur double the cost later plus delays on any enhancements you request while we figure out what wasn't documented in the first place. Your choice, please sign here (so I can shove it in your face when you're moaning to my management about the delays to the enhancements you need 6 months from now).

        1. TheMechanicTurk

          Re: If it was hard to write, it should be hard to understand!

          Living this ‘dream’ now as we speak!

    2. Doctor Syntax Silver badge

      Re: If it was hard to write, it should be hard to understand!

      "And as well as describing the method that works it would be kinda handy to know what other approaches were tried and rejected."

      Probably from Dr Dobbs or the like, the rubric went something like this:

      Apprentices' comments say what the code does.

      Journeymens' comments say why it does it this way.

      Masters' comments say why it doesn't do it some other way.

    3. Tim99 Silver badge

      Re: If it was hard to write, it should be hard to understand!

      We use to run projects based on the "Rule of Two":-

      Write code be twice as easy to understand than the team is capable of producing. Never put two or more expressions in the same line. Never write a function that addresses two or more business rules. Always write at least two lines of documentation for every function (Or, even every line of code). Always wait for at least version two of the tools that you are going to use to put software into a production environment. Stop writing code at two o'clock in the afternoon, then use the next two hours to check it (Then, if necessary, have a meeting about it - Which will be short because everyone wants to go home/down the pub).

  4. Christian Berger

    One way to avoid technical debt: experience

    Essentially most things developers do in the real world are utterly trivial. There rarely is an actual challenge. That's why developers often get bored and try to solve the trivial probems in more and more complicated ways. A good example are web applications. The web was made for (quasi) static "pages" of "rich text" with hyperlinks. Somehow people now try to cram interactive applications into this. That way, things that could be done in Delphi via the built-in "create a database application" wizzard within seconds, now take months.

    If you have experienced programmers, which have worked in different areas, you can reduce your technical debt. Just let them choose the propper tools for the job. Let them build prototypes so the users can already play with the product long before any details are set in stone.

    1. Marcus Fil

      Re: One way to avoid technical debt: experience

      Let them Help the customer understand the importance of, and cost of, prototypes so the users can already play with the product long before any details are set in stone. FTFY

      Sadly customers, especially start-ups, consider every penny spend on code as one more step on the path to glory. Diversions and dead ends don't exist because they think they cannot afford them.

      1. Christian Berger

        Re: One way to avoid technical debt: experience

        Well I don't think it's even possible to do decent software development in an outsouced environment. Software development without knowing in depth what the software has to do and what it's all about is utterly fruitless.

  5. craigh

    Our challenge is determining and tracking opportunity cost

    I like the separation of cost into principle and interest but I think that is still missing another cost that needs to be taken into account.

    Most often we need to decide how much time we invest in adding or extending the functional or non functional capability of the software.

    This often boils down to where we make the change and we talk about stretching what we have to just achieve what is needed now vs significantly changing an element that will allow it to go further than is currently demanded much more easily.

    In order to be worth the conversation the rebuilding cost (almost always time) needs to be markedly higher than what is needed for the stretch significantly delaying other things the team are being asked to do. Here we face two different costs, the certainty of any cost that the delay will cause vs the possible (but almost always eventually realised) cost of having to do what we could have done in the first place in order to deliver that further capability.

    I am tempted to call it opportunity cost but no doubt someone else will have a better name and take on this problem.

  6. teknopaul

    if it works

    One measure of technical debt is unittest coverage and closeness to full ci cd.

    However bad code is, if it works its ok until you need to change it. If it has full unittests and can be trivialy deployed. It can be changed. Therefor its debt can be paid off.

    Just a metric. But test coverage + cd readiness is imho a good one.

    1. ratfox

      Re: if it works

      I would say it differently: Working unit tests means everything is fine, if you will never need to change it. If you know you will need to change the code, but you don't understand how the code currently works, then you have a problem, and working unit tests are not going to help you.

      1. teebie

        Re: if it works

        "Working unit tests means everything is fine"

        Working unit tests means everything that you have thought to test is fine, which is a low bar I would want to put any weight on.

    2. Adam 1

      Re: if it works

      He called it a measure, not a silver bullet to fix all debt. And on that basis I think his point is strong. Quite strong.

      The sorts of organisations* that don't value unit testing** are highly correlated with the organisations that are too focused on the here and now to allocate time to resolving this technical debt.

      It's understandable at one level because resolving technical debt is expensive. The only thing more expensive is to not resolve it and then attempt a fix/improvement. But don't expect the business to recognise that the week spent on fixing some deficiency here has saved them two weeks on other projects over the following 6 months.

      *I speak of organisations because individual developers within those organisations may well be pushing the proverbial uphill trying to get the business onboard, but if they can't be convinced of the benefits of unit testing then they are likely to see any attempt at technical debt reduction as developers taking liberties with valuable company time.

      ** By value, I don't mean platitudes about their merits. I mean actually invest time into doing it, as well as investing in some sort of ci that runs them on every commit, as well as actually being prepared to rewrite code so badly coupled that unit testing is nigh impossible, as well as actually using the facts about whether an individual developer is consistently decreasing coverage as a KPI at their performance reviews.

  7. Whitter
    Devil

    CEO jobs are on the line...

    The liability issue makes technical debt a governance issue. "CEO jobs are on the line for something that they don't even begin to understand," Curtis points out.

    Perhaps the board should begin to accept that the board should not be full of people who don't understand the company?

    1. FlossyThePig

      Re: CEO jobs are on the line...

      Perhaps the board should begin to accept that the board should not be full of people who don't understand the company

      I'm getting old now. When I started in the business, called "Data Processing" then, there was an effort to get someone with DP knowledge on the Board. I believe this was reasonably successful. Unfortunately they have all now retired and have been replaced with accountants, bankers or other non-technical bods.

  8. Zippy's Sausage Factory
    Devil

    It needs fixing – badly.

    And often, if you need it done fast, and cheaply, that's what it gets: fixed, badly.

  9. Anonymous Coward
    Anonymous Coward

    Most of my technical debt is in code I wrote back when I first started working here and was a very inexperienced programmer. At the time I had my name on the contributor lists for a couple open source projects, just enough to prove that I did know the basics despite being self taught. 15 years and an actual CS degree later I occasionally go to update a really old project from early on and shudder at some of the naive choices I made back then.

    For the record, I've stayed where I am mostly because getting a higher paying job would involve moving. There just aren't any jobs in the area for programmers - which was probably a factor in me getting this job before I had a degree - and there are half a dozen reasons I don't want to move.

    Anon for, I think, obvious reasons.

    1. Richard 12 Silver badge

      If you don't think your early work can be improved

      Then you have learned nothing.

      It's a good sign when you think code you wrote a decade ago was pretty awful.

      If nothing else, there's been a lot of basic algorithm research, and huge changes in the languages themselves.

  10. Anonymous Coward
    Anonymous Coward

    Technical Debt - Arrrrgggghhhh

    One Project Manager I had the misfortune to work for on a supposedly Agile project (sic) called anthing that was identified as 'Technical Debt' as the 'Won't Fix List'.

    There never was any time to go back and look at the Technical Debt before we were onto the next sprint and piling on more TD almost every day.

    In the end productivity ground to a halt because of a whole raft of reasons most of which were languising on the 'Won't Fix List'.

    It came back to bite the PM as he was let go (he was a contractor) and was replaced by someone who at least understood a bit about software development. In the end it was all moot as the company was taken over before the system went live and all development was shipped to India. They invented their own solution that never worked but that is another story.

    Glad that I'm out of the SW Dev biz. There is no future in it in the UK.

  11. Will Godfrey Silver badge
    Meh

    Pragmatic Decisions

    There is code I wrote that has been working apparently correctly for years, but looking at it now I'm frankly horrified by it. Were modifications now needed and I was to work on this again, to do the job 'properly' would require a major re-write. However, if I apply patches with extreme caution, and very very thoroughly test everything, it is likely to carry on working - apparently correctly - for many more years.

    I haven't (yet) had to make such a decision.

  12. a_yank_lurker

    Another Area of TD

    One area of TD that is overlooked is when the requirements change significantly but some of the old code is still needed. You might really need to rewrite the code completely.

    Another area of TD is when the system does not allow the easy solution and any working solution is nasty kludge at best.

    Not all TD is due to poor programming or shaky specs.

  13. doublelayer Silver badge

    You need good programmers, and you need to let them work

    In many cases, this debt can come from decisions that require code to be out immediately. Sometimes, that's actually required for the situation, but in other situations the two days now will save two weeks later. However, in my experience this can result in a cycle of project managers messing things up, as they assume that, since working code was shipped successfully, the new features can be pushed along the same way. For an example, consider the recent MacOS releases. I think many of us can agree that 10.13 High Sierra has problems. Some of it works fine, but there have been a lot of bugs, including one that in my case cyclically bricks my laptop for a few days. That seems to be a firmware problem with their new disk format and my old machine. Even if that's just a me thing, we all remember the root password bug. These problems seem to happen rather frequently now that apple is making their developers push out a new big version every year or so, and I think the debt of this is the cause. Remember how nice 10.11 was? That was the version in which they didn't try to add as many features as they could think of, and instead focused on reliability and performance. In other words, paying down debt. A solution that does 90% of the job and crashes 0.1% of the time is better than one that does 95% of the job and crashes 10% of the time. If companies could realize that, we would have better code.

  14. David Leigh 1

    Grammar please

    ;A developer always pays their technical debts...' How on earth can anyone expect any respect when their grammar is so dreadful. Illiteracy is the bane of modern journalism. It should read 'Developers always pay their technical debts'. Unbelievable.

    1. Ken Hagan Gold badge

      Re: Grammar please

      There is nothing ungrammatical about the original. "their" is a third person singular possessive pronoun.

      On this subject, I was reading the biography of Helen Keller the other day (as you do) which was written roughly a century ago and I was struck by the consistent use of "him" and "his" to refer to a child when the passages, though couched in general terms, were clearly talking about Helen's childhood and Helen's teacher's particular approach to educating her. Certainly in my part of the world, such usage is now almost laughable.

    2. Anonymous Coward
      Anonymous Coward

      Re: Grammar please

      Not to mention that it's clearly a reference to phrase "A Lannister always pays their debts" from the Song of Ice and Fire novels. Ya doofus.

  15. Daniel von Asmuth
    Paris Hilton

    All words and no numbers.

    The national debt of the United States of America currently stands at 21 T$. How much is their national Technical Debt? Is it included in the former figure? How much technical debt is due to Microsoft Windows? The Intel x86_64 processors? How do I calculate the technical debt of my project?

  16. Claptrap314 Silver badge

    It's not just experience.

    Experience and skill are not strongly substitutable. The guy that's been on the project for decades might be garbage as a programmer.

    A potential employer brought me in for a three day working interview. The project? Implement a script to initialize new ruby projects with a one-liner. Set up the github project, hook it to jenkins, bring in & flesh out the skeleton files.

    What did I do? I implemented a platform for project initialization and a ruby module. I was hired, and over the next twenty months, we received regular requests to extend the capabilities. Java project? No problem. Scala? np. Two git repos? np. Two jenkins jobs? np. I never had to touch the core code.

    The skill involved in doing that was not just programming. It certainly was not captured by tests, nor by documentation. It involved understanding that the business problem that was being addressed was only hinted at by the ticket--and architecting the code to address the business problem first.

  17. Claptrap314 Silver badge

    Lack of tests is not techinical debt

    Look at the definition of technical debt in the article. Technical debt is about architectural and design decisions which have become outdated.

    Violating fundamental principles of programming is not technical debt. It is like building a building on a foundation where the concrete has too much sand. Whomever selected that mix is going to get sued and maybe prosecuted.

    Mixing data and code is not technical debt. It is programming malpractice. Promoting untested code--unless it is the only way to stop an issue which is actively being exploited by hostile actors--is not technical debt. It is programming fraud.

    And if you give time estimates to program managers that do not include the time required to adequately understand the ticket and test the code, you are part of the problem. If they argue that you are taking to long, you can explain to them that the bad condition of the code is the culprit.

    1. Gerry 5

      Re: Lack of tests is not techinical debt

      I was once sacked, as a contractor, when I was "taking too long" with a job someone had estimated would take 2 days. On reading the requirements I realised that this was in fact an enterprise application integration job no one had realised at the time of the estimate, and would probably take 6 months or more. Even giving an estimate would have required at least a week's investigation of unstructured T-SQL code running into 10s of thousands of lines of code containing undocumented business rules.

  18. Stevie

    Bah!

    So, no-one writes specs any more?

    Maybe that's the problem right there.

    1. Gerry 5

      Re: Bah!

      Oh yes they still write specs! Just so long as it fits on a piece of a 13.5 x 8.0 cm post it note.

  19. Anonymous Coward
    Anonymous Coward

    All code is written by offshore idiots to the lowest price

    This shitty code is in your medical devices, cars, industrial systems, phones and most devices in your homes. It's present on every website you visit.

    Insecure by negligence and stupidity, it's everywhere in your life.

    But hey - psychopaths are running the companies that make this stuff & they don't give a shit. They are cutting cost to get paid. You are not the 1% so fuck you.

  20. goldcd

    Technical debt is a problem

    BUT - Agile does have a mechanism to deal with it - developer self-interest/autonomy.

    In a happy-clappy-perfect-agile world, dev get a US for a sprint - but it's in an epic, that's tied to a feature, that's tied to maybe a nice wiki page explaining the business case.

    Sure, they could bang out the minimum to hit the done critera - but the stuff outside the US exists for a purpose.

    Read the context, see what's coming up next in the backlog - and 5% extra effort now, will make the next US 20% easier.

    Prior to release, when the shit hits the fan, then yes shortcuts are taken. However under 'normal conditions' devolution of design is supposed to incentivize everybody to avoid debt for a more pleasant life in the next sprint.

    1. Loyal Commenter Silver badge
      WTF?

      Re: Technical debt is a problem

      And that's Agile Buzzword Bingo!

  21. Deltics
    Coat

    Like any Debt, Not all Technical Debt is equally bad

    Weigh the debt against the cost to repay and the value/cost of delay over the life of the debt.

    A credit card debt is a wholly different class of liability than a mortgage.

    For example.

    1. volsano

      Re: Like any Debt, Not all Technical Debt is equally bad

      > A credit card debt is a wholly different class of liability than a mortgage.

      And a technical gambling debt or technical payday loan needs to be prioritised before your technical leg gets technically borken.

  22. John Savard

    Old Words

    IIRC, a groat is 4d, or 1 2/3 new pence.

  23. Anonymous Coward
    Anonymous Coward

    Realistic release targets matter

    When the project manager is saying "one month" but everyone knows that's impossible, it pushes people into taking unnecessary shortcuts and incurs huge debt.

    Worse is when one part is very behind, the temptation then becomes for the product managers to add more features into the other parts... making the whole thing later and worse.

    Worst is when formal testing doesn't start until "feature complete"... Waterfall is bad enough, but that makes it unworkable.

  24. Anonymous Coward
    Anonymous Coward

    Obvious News Shocker

    Some descisions made at any level of a company may have a negative effect on that company....

    Wow, never saw that one coming. Ah, I get it, you spun this to specifically target Technical Debt. As opposed to incompetence debt, mismanagement debt, which all basically lead back to the same thing.

    This is not something magically special to DevOps, or even development. The debt incurred by employees, managers and stupid decisions is not limited to technical, but hey, new Buzzwords, we gotta be on them...

  25. hatti

    on the increase

    The future of tech dept is likely to expand with javascript frameworks coming out seemingly at a rate of one a week via npm. Possibly we're working to a point where no one understands how to fix anything.

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