Standard for Managing and Fixing Technical Debt

Seems an official specification for measuring and managing technical debt is in works. I found myself waiting with a mix of fascination and horror, and then realized those emotions were caused by me being a strong proponent of my Simple Standard for Managing and Fixing Technical Debt (SSfMaFTD for those of you fond of hashtags or alphabet soup).

It has clearly come the time to share this standard with the world.

Simple Standard for Managing and Fixing Technical Debt

1. Do not code anything risky or messy (aka technical debt).
2. If you create any technical debt, note down what and, most importantly, why.
3. Fix all the technical debt you can¹.
4. Eliminate the root causes of technical debt whenever feasible.

Proposed implementation of SSfMaFTD

1. Do not code anything risky or messy (aka technical debt).
2. If you create any technical debt, write into TECHNICALDEBT.md what and, most importantly, why.
3. Comment technical debt in code with a code comment "TECHNICALDEBT".
4. Fix all the technical debt you can¹.
5. Check the notes and code comments in your retrospectives.
6. Pay attention to the common causes that lead to technical debt and strive to eliminate them.
7. If your technical debt went down since the previous retro, celebrate that!

Something more verbose?

If you want something more verbose, the slide set on Identifying and Managing Technical Debt can let you know a lot more on identifying different types of technical debt and understanding why keeping it under control is important.

Embracing test failure

When I start sketching out tests for my code, I often use the test names as placeholders for the tests I know I'll want to write. I don't necessarily know when the tests get written, but for sure I know that I'm not done until all of the tests are written and pass.

That means it's not ok for me to lazily do:

class ExampleTestCase(TestCase):
    """Test case covers known acceptance criterias"""

    def test_ac1(self):
        pass

    def test_ac2(self):
        pass

Why not? Because then my first run of the unwritten tests would pass, not fail. Worse yet, I might forget to flesh out some of the test cases.

Making your tests fail

In order to make the test fail so that I know what is missing, and so that I only get the happy carrot of a passing test when it's well deserved, I instead make everything fail:

UNTESTED = "The test has not been written"

class ExampleTestCase(TestCase):
    """Test case covers known acceptance criterias"""

    def test_ac1(self):
        self.fail(UNTESTED)

    def test_ac2(self):
        self.fail(UNTESTED)

Fare thee well, my friend, and may all your tests be green when, and only when, you are done.

Three different motivations to start a project

In the last year or so I've been curious about the different motivations people have when choosing to start a new free software project. There seems to be three common patterns.

NIH

NIH stands for Not Invented Here. The person sees the whole range of existing options immediately as inadequate and not worth even looking into. In the eyes of a person with strong NIH nothing written by anyone else could possibly be as good as what they themselves are building.

Scratching one's own itch

The person just scratching their own itch is making something just because they need something and want to make it. They will consider other options valid and not automatically their own project as superior. In fact, while they eat their own Dog Food, they don't think other people would be interested in consuming it.

Not for me

Not For Me starts as an attempt to Use Someone Else's, then one by one finding that the existing solutions do not fit their needs, and then eventually giving up the search and starting to write a new one. Usually having been exposed to the existing alternatives makes the designer then more aware of the possible needs of other users, and the end result has a niche it fits in the ecosystem.