Sign in / up

back to article Software shortcuts: Pay down your tech debt. It's time to fix a price

Technical debt: we probably create it every day. It happens when you do things that might get you closer to goal now, but which create problems that you’ll have to pay for later. The concept “technical debt” in software design and development comes from Agile development guru Ward Cunningham. He described what happens when you …

COMMENTS

Post your comment
House rules Send corrections
Add to 'My topics' unstar *
  1. Glad Im Done with IT

    Full steam reversal?

    “Let’s not wait till we’re 10 spins into the cycle,” he continues. “Let’s make sure the dev team, the ops team and the biz team are in the room saying this is what we need to build on day one.”

    So back to proper requirements and throw out the devops??

    23 1 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: Full steam reversal?

      I don't think that the problem is due to devops, but rather that devops, to a degree, exacerbates it.

      I think that the underlying problem is deep integration because it requires, even in modular systems, complex and specific interfaces which, because of their complexity and specificity, become fragile. A quickly changing environment, as with devops, just accelerates the process.

      I'm of the opinion that loosely integrated systems are more easy to adapt and maintain but the usual downsides are higher interface overheads and lower performance.

      8 0 Reply
  2. Anonymous Coward
    Anonymous Coward

    In the days of Crosby Quality - it was deemed over-engineering to cater for anything other than the specification required. Making a design "open ended" was severely criticised as a waste of resources.

    When OO became the norm - it could prove fatal if the specification had failed to cover a particular case. There could be no bending of the object model - it was often a tear down and start again.

    6 0 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      re: it was deemed over-engineering to cater for anything other than the specification required

      It still is in my book. Why are you writing software that goes beyond the specification? Who's paying for your time to do this? Where's the value to the business?

      0 5 Reply
      1. Ken Hagan Gold badge
        Reply Icon

        Re: re: it was deemed over-engineering to cater for anything other than the specification required

        "Why are you writing software that goes beyond the specification?"

        Because any fule can see that version 2 will need some of the extensions that you are now making room for and unless you are *planning to go out of business* you need to be able to deliver version 2. Adding new features is always cheaper during the planning stage, so it makes sense to plan version 2 whilst you are writing version 1.

        "Who's paying for your time to do this?"

        Your *next* customer. (Ideally, that is your current customer in a year's time. I say "ideally" because existing customers are easier to find than new ones.)

        "Where's the value to the business?"

        Staying in business. Not having to find a completely new product, design and implement that product from scratch, and then find customers for that product who haven't met the customers for your existing product that is now tanking badly and dragging your reputation through the mud.

        Of course, if you are the kind of IT pro who jumps from one job to another every couple of years to avoid the trail of shitstorms you are leaving in your wake, the future of your current employer may not be important to you. But your employer might care.

        9 0 Reply
      2. handleoclast
        Reply Icon

        Re: re: it was deemed over-engineering to cater for anything other than the specification required

        Why are you writing software that goes beyond the specification? Who's paying for your time to do this? Where's the value to the business?

        Some of us try to avoid painting ourselves into corners. We try to anticipate, a little, how things might evolve in future releases. So if we see two ways of doing something, with little to choose between them except that one paints us into a corner and the other does not...

        3 0 Reply
        1. Bronek Kozicki
          Reply Icon

          Re: re: it was deemed over-engineering to cater for anything other than the specification required

          There is also this little thing called "non-functional requirements". Things like scalability, logging and monitoring subsystems, deployment and test tools, etc. Things which are rarely, if ever, mentioned by the project stakeholders, but if ignored during design and development then the final product is guaranteed to fail.

          2 0 Reply
      3. Anonymous Coward
        Reply Icon
        Anonymous Coward

        Re: re: it was deemed over-engineering to cater for anything other than the specification required

        Because in the absence of a genuinely collaborative approach, a Requirements Bible (the "specification") is typically a minified version of what is actually required, pared back to meet budgetary, time or capacity constraints (called "priorities" by the business) despite the protests of the implementors who have to deal with the reality of delivering an actual working system, not painting numbers in a spreadsheet/project document to represent some accounting notion of what building a system looks like.

        The time is paid for by getting as creative with time in the timesheeting system as the business are with the idea of "requirement" in a requirements document.

        The value to the business is that they get a system that does what they need rather than only what they say they require.

        In theory.

        1 0 Reply
  3. Joe Werner Silver badge

    "Technical Dept"

    I call this "screwing your future self"...

    9 0 Reply
    1. Commswonk
      Reply Icon

      Re: "Technical Dept"

      I call this "screwing your future self"...

      Pity you mistyped the title. A good "Technical Dept" should be treasured, not eliminated.

      10 0 Reply
  4. Anonymous Coward
    Anonymous Coward

    Tom Peters in one of his "Excellence" books in the 1980s gives an example of a complex missile project that was split between three companies. Instead of a rigid interface specification for the three components - it was deliberately left to be somewhat fuzzy. The result was the components were flexible enough to fit together without too much adjustment.

    In my support career it was always a case that the more detailed the documentation for something - the more likely it was to be wrong in some detail. Usually a principle hadn't changed in the product's continued evolution - but the implementation had.

    7 3 Reply
    1. kend1
      Reply Icon
      Facepalm

      it was deliberately left to be somewhat fuzzy

      RE: Anonymous Coward

      "Tom Peters in one of his "Excellence" books in the 1980s gives an example of a complex missile project that was split between three companies. Instead of a rigid interface specification for the three components - it was deliberately left to be somewhat fuzzy. The result was the components were flexible enough to fit together without too much adjustment."

      How fuzzy?

      http://edition.cnn.com/TECH/space/9909/30/mars.metric.02/

      2 0 Reply
  5. Pascal Monett Silver badge

    Fail fast and fix it

    "Agile development makes the idea of rapid failure much more acceptable because you’re looking at continuous improvement as a way to fail fast and fix it"

    I can't help but think that this sentence contradicts the one later on that says that devs should say what they need from day one.

    That said, I have worked on a few large projects myself, and no amount of planning can cover all the bumps you encounter during development. So, in a way, I concur with both statements in as much as you plan all you can beforhand, then you fix whatever potholes you encounter during development.

    Still, all the articles I read about DevOps, this one included, make a lot more noise about developing, fixing, developing and fixing fast, rather than writing proper specs and having an execution plan that doesn't involve regular week-end marathon sessions.

    9 0 Reply
    1. Anonymous Coward
      Reply Icon
      Anonymous Coward

      Re: Fail fast and fix it

      To me Agile is a framework for rapid prototyping internally and/or for only the cutting edge areas that can handle it - certain trading desks as an example where you need to try to keep ahead of the competition. In a more general software environment if I were a customer getting "fail fast and fix it" code I might be just a little pissed off as it's the fails that make you lose momentum in your working day.

      1 0 Reply
  6. Anonymous Coward
    Anonymous Coward

    Think of this in terms of smartphones

    Both iOS and Android are 10 years old now, and a lot of early design choices made due to the limited CPU power, memory, etc. back then are baked into their basic design. Sure, it is possible to leave some of that behind as you drop support for older versions, but some changes are harder than others.

    For instance, the way iOS was designed to "know" the display resolution, so that as higher DPI displays were used they did 2x and then 3x scaling of some UI elements. Using PDF or vector graphics for display would make the most sense if you were going from scratch today, as the CPUs/GPUs have sufficient horsepower and displays are high enough resolution that any artifacting would not be visible, but neither was true when it came out in 2007 (let alone when they began the project in 2002) The 1x displays are EOL, as are the 3.5" sizes, but it is still a detail that adds work for app developers today.

    4 0 Reply
  7. Anonymous Coward
    Anonymous Coward

    i feel your pain

    Excellent write-up man. I am a mobile app developer myself & I can surely understand the limitations we sometimes face while dealing with the customers. The most annoying part is, when we want to develop something but the client fails to understand our vision. As one of my friend who works in an app development agency (https://www.branex.com/mobile-app-development/) said it best "Ask the price of your experience, not your hours.

    2 0 Reply
  8. Anonymous Coward
    Anonymous Coward

    The concept “technical debt” in software design and development comes from Agile development guru Ward Cunningham.

    The name, maybe, but not the concept.

    /* ToDo: Won't work if num_tables gets > 32767 */

    has been around a very long time...

    4 0 Reply
  9. Anonymous Coward
    Gimp

    and another article on theRegisters pages today asks

    "Why isn't digital fixing the productivity puzzle? Paying people better matters just as much. Maybe more so ?" "https://www.theregister.co.uk/2018/02/23/mckinsey_productivity_puzzle_and_digital/"

    Where you say it's all just grist for the mill, because as one gets a step closer to completing a project, it all gets a step closer to being obsolete.

    a merry-go-round debt machine. I hope the purpose of the project was worth it.

    Inflation is lack of productivity in spending - debt is just spending

    1 0 Reply
  10. dbgi

    Clients always want the best price

    It can be a difficult conundrum. On the one hand, a team of developers are sat there waiting to build the best system they can dream of, on the other, is the client who wants it cheaper than you've quoted for and by tomorrow. The management team want the work to pay everyone's salaries and it almost always results in a system which has been heavily compromised.

    No one cares until the support team need to constantly fix things or the client can't add an extra feature without it breaking something else.Then it's always our fault.

    2 0 Reply
  11. iron Silver badge

    Agile is no panacea

    Agile is no panacea. Having worked there I can tell you the Scottish NHS went agile about 10 years ago yet it hasn't prevented: "outmoded systems that couldn’t be made to work together, partly the result of years of programming decisions"

    6 0 Reply
  12. Anonymous Coward
    Anonymous Coward

    In a few years we will know how the rate at which DevOps creates Technical Debt compares to other approaches - of course by then we'll be being told about the next New Best Thing.

    4 0 Reply
  13. SVV

    Outsourcing....

    The source of payday lending levels of interest, both financially and technically, when it comes to technical debt. The future of the system once it's delivered? What's that? OK, how about a costly per-hour rate maintenance contract?

    3 0 Reply
  14. John Smith 19 Gold badge
    Holmes

    TL:DR. You need to buy some new software to manage this.

    Actually "technical debt" sounds like the reason so many IT systems of HMG are s**t. All those decisions deferred indefinitely. All those outsourced devs on minimum wage doing minimum thinking work.

    4 1 Reply
  15. Ken Moorhouse Silver badge

    Security

    This word is not mentioned once in the piece, yet it is arguably the biggest BYOTB (Bite You On the Bum) item of Technical Debt that can be taken out, as can be seen, for example, with the number of vulnerabilities with IoT and unsecured Cloud Buckets being reported. The problem with a developer grappling with something new is to get the damn thing working for now, and come back to configure it securely later.

    API providers want you to use their creation, so they don't want to rock the boat and refuse to work with default credentials, but there should be some kind of nagware built in (stretching the metaphor, an IOU) to alert the developer, on a regular basis until the debt is repaid. Unfortunately, there will be developers out there who will "sink" such reminders, rather than act upon them.

    0 0 Reply
    1. Snow Wombat
      Reply Icon

      Re: Security

      Clients don't want to pay for the extra work it takes at all levels, to make something secure by design.

      You run into the Classic A x B x C = X problem, so famously referenced in fight club.

      0 0 Reply
  16. Snow Wombat
    Mushroom

    In my experience

    "Nevertheless, it faces a decision: should it spend time and money fixing the problem, or should it kick the can down the road?"

    In my experience, companies almost ALWAYS choose the latter unless the problem can be fixed quickly and easily. I have got into metaphorical "knock down, drag out" fights with previous companies regarding this sort of thing, and bone headed design decisions.

    Decisions that cost them 20% more now, vs costing them 200%+ later (later being within 2 years) and almost without fail they choose the former.

    So when the Titanic finally hits the massive Iceburg I warned them about, I get the emails and phone calls about how they can deal with it.

    When this happens I give them a fair and honest assessment of what it will take to fix, and quietly add 30% onto my consulting fee as an "idiot tax"

    0 0 Reply

POST COMMENT House rules

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

Forgotten password ?

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like