Paying Your Software Development Tax

26 June 2017 (2)

In software development we already have the technical debt metaphor that helps describe the the fact that a quick and dirty approach now, may create problems in the future. For example getting a feature into production sooner but compromising the quality/design/testability/etc. may make future changes harder or more costly: hence paying interest over time for the technical debt that was just created.

The technical debt metaphor is easily relatable to by non-developers and can help facilitate discussions with business owners/stakeholders.

In the real world, paying interest is an acceptable part of life and loans in various forms are not seen as problematic for the majority of people in modern society.

Even though they are an essential part of society however, most people dislike the thought of taxes.

Would the metaphor of a software development tax provide a more visceral reaction and encourage higher quality software where appropriate?

For example, there are “taxes” that come from everyday software development, such as bug fixing or introducing code duplication. Rather than saying “this will add some technical debt to the project…”, we could say “that’s going to increase the amount of tax we have to pay to deliver this…”.

SHARE:

Comments (2) -

  • Joseph

    7/11/2017 12:55:04 PM | Reply

    I think saying something like "this will add tax to our project" would throw people off at first, but after a while, they would get used to it. No one likes debt. And I would venture to say that debt may sound worse than taxes, because at least taxes get used for society, where debt payments are only beneficial to the creditor.

    I think the real problem is technical debt cannot be measured, so the perception of it being a threat is hidden behind vague figures. You may throw some technical debt into a feature that customers don't end up using, so the debt never needs to be collected. Or maybe so many customers use it that it crashes your app and your debt is supplemented with damages to revenue. Again, the problem is that it can't be quantified. And I'm sure you know, "what doesn't get measured doesn't get managed."

Add comment

Loading