1. 13
  1.  

  2. 16

    The click-bait title is not really backed up in any way in the content. The conclusion doesn’t even bring up company death. All-in-all, a rehash of the existing knowledge and statements around technical debt.

    1. 3

      Moreover, the fact that almost all of the most successful, rich companies have a pile of technical debt… some maybe inescapable… refutes the title so thoroughly that it almost seems more natural to ask if technical debt is a positive sign of success.

      Im not saying it is so much as looking only at correlations between companies that last and amount of technical debt would make it look positive by default.

      1. 4

        I tend to view that as “Stagger onwards despite the mountain of technical debt, because the prime drivers in our current economy are not efficiency or competence of engineering”.

      2. 1

        I’m sorry if the content of my post wasn’t explicit enough. The 4 areas of technical debt I analyse give my idea of how they lead to the corrosion of the engineering organization and the company:

        • Lack of shared understanding on the functionality of the product (leading to waste of effort and disruption of service)
        • Inability to scale and loss of agility in respect to the competing organizations
        • Inability to react to failures and learn from how the product is used by your clients
        • Inability to scale your engineering team

        My bad if the above points haven’t been clear enough from my post. Thanks for your feedback, really appreciated!

        1. 2

          No, I got those points out of it, but you didn’t link that to company death in anyway. I’ve not done a study but of the successful companies I’ve worked at, tech debt is pervasive, depending on the area.

          Also, and this point as more to do with me than you so I don’t hold it against you, I’m sick of these articles that of the form:

          Observation -> Logical Assumptions Based On Observation -> Conclusion

          There is no empiricism in there at all. So does tech debt make it harder to scale your engineering team? Maybe! But you’ve just presented some nice sounding arguments rather than any concrete evidence. It’s easy to say “here’s a a bad thing and here are the bad things I would assume happen because of it” but that’s a long ways away from “here’s a bad thing and here is the concrete evidence of outputs because of it”.

      3. 3

        Can we stop using the term technical debt? It was invented by Ward Cunningham to explain to business people the risk and benefit of cutting corners. We are not finance people and like all analogies it breaks down quickly. Who incurs the debt and who pays it back? Its unclear.

        1. 2

          Who incurs the debt

          First the developers. They have to do more work. Then the users. Code tends to be delivered to them later because TD adds to time.

          and who pays it back?

          Your boss. Either he invests in giving you time to fix the TD or he pays continuously because your day-to-day work takes longer and longer.

          I think the term pretty much nails it. Not only for finance people.

          1. 1

            First the developers. They have to do more work. Then the users. Code tends to be delivered to them later because TD adds to time.

            Technical debt saves time! That was the argument Ward Cunningham gave as a benefit of technical debt. You save time now for complexity later. It’s a way to push out software faster in the beginning. it’s about cutting corners. You incur TD because it saves you time!

            Your boss. Either he invests in giving you time to fix the TD or he pays continuously because your day-to-day work takes longer and longer.

            What if there is no boss? What if you never pay technical debt? What if you just keep patching? What if your software reaches a point where it’s feature complete and there is not reason to tackle the technical debt? Is this a debt jubilee?

            It makes no sense, who do we borrow from? the universe? ourselves? Is there interest? Is it quantifiable?

            I prefer other terms than technical debt like entropy, code rot, or incidental complexity. It’s about keeping a clean shop. After the first release it’s all maintenance. A better analogy might be a car mechanic keeping a clean shop.

            1. 1

              Is it quantifiable?

              Yes, for companies producing software, yes it is. For Open Source projects, may be.

              It’s about keeping a clean shop.

              Well, no. It can be all dirty but this might not add to the total cost of maintaining or producing the product. It’s not about work ethics or craftsmanship.

              TD is used to assess the real cost of certain decisions. (I like your “cutting corners”.) Whether these costs are too high or not, or like you said, if it even saves you in the end, doesn’t matter. It is just a term for those costs.

              1. 2

                Yes, for companies producing software, yes it is.

                Can you expand on that? Quantifying software development has, so far, been a very difficult challenge.

                1. 1

                  Yes, sure, exactly quantifying the costs has been a very difficult challenge. But you can estimate, get a measure of, or roughly calculate the costs. And this is in fact what you do in every sprint planning, if you do follow an agile methodology.

                  Example: When I use SVN as a version control software I can add up a certain amount of time, say 10 minutes, when I do manually “rebase” my changes on the current trunk. If I do that 3 times a day, that’ll be 30 minutes. Or I can use git, where it’ll take me lets say 1 minute, or 3 minutes a day.

                  Now when I want to switch the repo to git, and want to preserve the commit history, I need to understand and use cvs2git to transform the SVN repo. Then I need to test the import. Publish it. Train my fellow colleagues to use git. Lets say I need two weeks for that.

                  Now is it worth it? When will the cost amortize?

                  I think this is pretty good quantifiable. If you just guesstimate.

                  1. 1

                    Or you could just decide commit history isn’t all that important to you and do merges, no tool change needed! Your example leaves out a bunch of other work, though. For example, if your company has a bunch of tooling that makes assumptions about using SVN, then moving over to git could be extremely expensive, and that expense is usually a challenge to quantify, IME. Is it worth having the tools team abstract SVN away or move everything to git? What won’t we have in the time it takes for them to do that? And that’s what TD usually looks like IME. It’s not “if we do this, I’ll save X minutes every day, and doing this is free”. Almost always, it’s “we can do this, I’ll save X minutes every day, but doing this will cost us a month of doing other things”. And since quantifying the future is hard, that statement becomes much harder to quantify.

                    1. 1

                      I might be wrong but it seems you mix-up business decisions with engineering decisions. And of course, taking decisions in a world where you do not know everything is difficult. That’s what makes it so interesting :)

                      But I believe I see your point: TD is a limited concept that does not encompass the entire problem-space of software quality. True.

                      1. 2

                        I might be wrong but it seems you mix-up business decisions with engineering decisions.

                        TD is inherently a business decision, otherwise not having it/solving it when it does show up would be trivial: just do refactor/rewrite and take as long as you want.

        2. 3

          How many of you track your technical debt explicitly?

          That is, with an issue label or somesuch marker indicating “a decision that might bite us was made and this is proof of that hesitation”.

          I’ve been doing this now for about 2 years on my projects and it’s helped a few times when regret has come in the form of unhappy management.

          1. 2

            I do not do it that explicit in code. But projects I’ve been TL on I do make very explicit decisions about which part of the codebase is allowed to go into debt and which parts need to be high quality from day one. It doesn’t always work out like that but making the decision and communicating helps a lot.

          2. 1

            Technical debt is something that always creates an internal debate for me. In some cases, I believe that it is our responsibility as engineers to “fight” against it, through the use of well-known refactoring techniques and being efficient on time management to improve code even when adding new features. But sometimes (or most of the time) you always have the pressure to add new features to the system, and how you sell that the feature is going slow due to not being able to “just add the feature” but instead you have to move things around to accommodate the new feature?

              1. 6

                I have learnt never to say “Technical debt”.

                If you say “Technical debt” to the business end, you’ve lost already.

                Because then you have to explain what the problem is exactly. And you run in to the Manager’s Syllogism.

                You know the one, “Manager’s are Important People. They know and Understand Important Things, if XXX was Important, They would Know All About it.”

                Ok, I’m exaggerating for humorous effect, but the point is compared to everything else on the list of things they want done, Technical Debt is really low on the list…. and most times falls of the list of things To Do This Cadence. Again.

                Or worse, “So you’re saying this mess exists because your Managers are Bad and your colleagues are Worse? And now you expect me to trust you to go off on a long rewrite?”

                I distrust rewrites.

                They are never as Good as Hoped and always take way way longer than expected to get up to full functional equivalency. In fact, usually never do. In fact, I’d argue most of the benefits of a rewrite is in deleting cruft nobody really needs.

                So start there.

                Delete cruft as you go along every time you see it.

                If someone yells and really wants it back… hey that’s what version control is for.

                So merely say, “It will take X amount of time.” Why so Long? “Because that is the way the existing code is. (You can start explaining it to them until their eyes glaze over..)”

                And then fix the existing code.

                When you need to fix a bug, write a unit test that stimulates it. Then tidy up the code until it is so simple the bug is obvious. Fix the bug.

                When you need to add a feature, brace exiting required functionality in unit tests, write a unit test to add the new feature, watch it fail, clean up the code until it’s trivial to add the new feature, add the new feature, watch it pass.

                Technical Debt? What’s that? Heard of it once, not a useful concept in practice.

                1. 2

                  Thank you so much for this. Really really useful!

                  1. 1

                    Thank you! Will read it :)

                2. 1

                  It’s problems in the code that build up over time which slow development pace, reduce flexibility, increase costs, and can negatively impact reliability/performance/security. So, what phrase do we call that if replacing technical debt?

                    1. 2

                      Oh yeah, that simplifies the heck out of it, doesnt it? Was more accurate.