Hello dear esteemed monks,

Today I would like to present a tool of my own which I hope you'll find useful.

Preamble

Every once in a while I encounter a technical debt discussion on the internet. Each time there are generally two types of comments: (1) tech debt is bad, it leads to bugs, delays, downtime, top talent quitting and product rewrites, and (2) nobody pays for clean code, all you need is features here and now.

Being a supporter of the first cause myself, I keep wondering if the damage can actually be measured. And it looks like there is a way.

The tool

Potracheno (a Russian adjective with a meaning close to "wasted" or "spent") is a specialized tech debt issue tracking system. Just like a normal bug tracker, it has tickets, ticket statuses and comments, search, and so on. It supports markdown and Stackoverflow-like tags. Nothing much to boast about.

Also like a normal bug tracker it has time tracking facility. However, instead of recording time spent fixing a problem, it tracks time wasted on living with it. Copy-and-pasting, fighting bugs, doing manually what could be automated, waiting for long compilation/deployment, and generally being frustrated and posting about it on the net.

Completely unlike a normal bug tracker, it has a special feature called solution proposals. A solution is a special comment with a time estimate to fix the issue. Multiple solutions can be proposed for the same issue.

Finally, a report with numerous criteria can be generated. Including, but not limited to, the fix estimate / wasted time ratio.

The project is written in Perl and SQLite with minimal dependencies (DBD::SQLite, Text::Markdown, and MVC::Neaf). It is designed to run from local directory on any network-enabled device, be it a dev's laptop, a test server, or a coffee machine in the office.

Source: https://github.com/dallaylaen/potracheno.

A little philosophy

The supposed setting for this tool is a team sick of bad code and willing to refactor it - refactor in the broadest sense, including rewriting specific components, fixing architecture/preformance problems, writing missing tools etc - anything that improves the project on the inside.

Also somewhere must be the project owner, who only wants features as soon as possible. Well, if they wanted something else, the team would be out in the street with a well written product that nobody uses.

This tool is supposed to be installed alongside a normal ITS (if you don't have one, tech debt isn't your biggest problem for sure). As statistics and solutions accumulate, they either should be presented to the product owner and converted to usual tasks, or silently included with features touching the same component(s).

I believe that, similar to performance profiling, 80% of the team's frustration are accounted for by a tiny subset of problems that can be numbered, weighted, and dealt with once and for all. Whether this holds, only practice can tell.

And finally

I would like to ask you, fellow monks, to try and follow the installation instructions of my project, and tell me (either here, or in the github bugtracker) what went wrong. I'm planning to release it onto non-Perl users (thus acting as a Perl-monger), so I would like the process to be as smooth as possible.

Thanks for reading, and have a great day and a great week!