Tag software

Latest posts for tag software

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

Do not code anything risky or messy (aka technical debt).

If you create any technical debt, note down what and, most importantly, why.

Pay attention to the common causes that lead to technical debt and strive to eliminate them.

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.

What you can fix is up for your project to decide. Usually it's the combination of whatever you can get fixed without manager interference and BIG refactorings with a clear ROI. ↩

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.

NIH rules out the whole range of existing options immediately.

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.

Scratching one's own itch doesn't require knowing the alternatives
well, just enough to get an idea of what one wants their project to be.

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.

Before starting, often multiple alternatives have been explored,
and thus the new project finds its niche in the ecosystem.