personal development, Refactoring

Getting rid of technical debt

This post was inspired by excellent article by Bastian Buch, Effective Steps to reduce technical debt: An agile approach.

What is technical debt?

Technical debt may be considered as work that needs to be done to complete the project, but not done before delivering the product. I personally like to say that it’s all the undone work that makes developers proud or at least satisfied about the system they develop. It’s all about the issues that we promise to do in our less busy sprints, TODOs in code, sticky notes etc. It’s present in almost every project, but the only thing many of us do with it is complaining. Here is a list of ideas helpful to get rid of this debt using agile approach. It’s really hard because reducing technical debt is out of normal flow that is “implementing features”. That’s why you need a good plan to get rid of it.

1. Control technical debt

It’s not that technical debt comes from nowhere nor it’s that bad developers come to the team, make a mess and disappear. Technical debt starts with the lack of time. Initially it’s right – business value is more important than developers’ satisfaction. But then comes the deadline, another sprint in a rush and the team forgot to implement these unit tests, refactor this copy-pasted module or fix the hack in domain logic. Instead of trying to not create more technical debt, let’s try to control it in a proper way. One way is to have an inventory with items having a brief description. Then such a knowledge persists even if the only developer knowing the details has left the company.

2. Estimate & prioritize

After you gathered all the items in one place it’s time to put them in some order so that it’s easy to get something and just do it without analysis of the whole backlog. It’s good practice to order items in two dimensions: by their cost and returned value. The most important thing is to come to conclusion that cheapest but most valuable issues should be done first, and the most expensive with lowest value will probably never be done.

3. Visualize

The third, but the most important point is to visualize this inventory. This was a revolution that hit me while reading the article of Bastian. Before we had “TODO” items in code, but who knows how many. We had Onenote page (our wishlist) gathering all the things that we want to do for our project when we have time, but we just push items onto the list, never pull from it. We had “As a Developer I would like …” tasks in JIRA, but they were lost among hundreds of issues originating from “real” users. In all cases the inventory is hidden and the team pretends that there is no debt. But imagine that the inventory is visible next to the scrum board. Then it’s impossible to ignore the debt. You have an instant access to the inventory, both read and write. It’s clear when there are too many items. We go through this when we have a minute or two.


4. Put on a strategy

When everything is ready it’s time for the strategy: do the cheapest stuff in your innovation/research/study time (it should be around 20% of your capacity) – all in all such technical tasks is a great opportunity to sharpen your skills. More expensive tasks must wait for approval of Product Owner and come into a sprint with other issues. All in all you can always split them into smaller ones if you think that in that shape you can still benefit from them.

5. Involve Product Owner

Your product owner should know that you have debt. It’s the problem of the whole team. Tell him the cost of the debt (sometimes you need to realize it even for yourself). Sometimes it’s easy because implementing new features must be preceded by getting rid of the debt for some technical reason. Sometimes it’s harder, because of long term consequences of poor code coverage or just a mess in solution structure. All in all PO must be aware of it because they give the green light to do bigger issues as parts of the sprint.

Other ideas

Beside technical debt we also put on the same board optional technical tasks. Actually it fits the definition of “things to do to be proud of the system”.

We always wanted to try implementing gamification in our team and I think it’s a nice opportunity for us. By solving technical issues we get “virtual money” and we could praise ourselves for doing it. We can also track the average earning for each month. It’s always good to measure because such numbers motivate.

I really recommend to try it yourself

Desktop, tools, Web

Generating HTML document from template using NVelocity

Web HTMLSometimes there is a need to generate a document (HTML report, e-mail etc.) from a given template. It’s simple when it comes to just replace some tokens, but in case of more complicated operations (dealing with collections, conditions, loops) it’s better to use advanced template engine. Most of us are familiar with many (even unconsciously): WebFormsViewEngine (ASP.NET WebForms), Spark (ASP.NET MVC), Razor (ASP.NET MVC) and probably many more (here’s a nice comparison). Unfortunately these famous ones depend on ASP.NET and it’s rather a big deal to use them in a simple library. Fortunately there is NVelocity that can be used as a standalone tool and gives pretty much flexibility.


NVelocity is a port of very famous template engine from Java world called Apache Velocity that makes it possible to build MVC application (used for example by JIRA or Spring Framework). The latest version of NVelocity is a part of Castle Project and can be downloaded from github (other versions stored on codeplex or sourceforge are no longer supported). You can also use Nuget to do the same.

Velocity alone is documented pretty well, but also the library in Castle Project repository contains a lot of samples (I believe each single keyword has a separate document with sample usage).

NVelocity does not need any extra references but NVelocity.dll that you can build on your own or take it from the sample app in the end of this post.

Sample usage

Here’s is a code showing the sample usage of NVelocity:


var model = new
	Header = "Test Header",
	Items = new[]
		new { ID = 1, Name = "Name1", Bold = false},
		new { ID = 2, Name = "Name2", Bold = false},
		new { ID = 3, Name = "Name3", Bold = true}
var velocityContext = new VelocityContext();
velocityContext.Put("model", model);

string template = string.Join(Environment.NewLine, new [] {
	"   This is model.Header: <strong>$model.Header</strong>",
	"#foreach($item in $model.Items)",
	"   <li>",
	"      item.ID: $item.ID,",
	   "#if ($item.Bold)",
	"      item.Name: <b>$item.Name</b>",
	"      item.Name: $item.Name",
	"   </li>",

var sb = new StringBuilder();
	new StringWriter(sb),
	"test template",
	new StringReader(template));

This should produce the following result:


Some explanation

The snippet above is rather self-explanatory, but I’ll just point out the most important clauses. First thing is “Velocity.Init()” that initializes the engine and creates a pool of parsers (NVelocity uses singleton pattern). Next we need to create VelocityContext that is a map of velocity variables and .NET objects. Here I used anonymous objects, but you’re free to pass any .NET object. NVelocity interpret IEnumerable as NVelocity collection, it also supports .NET properties. “Velocity.Evaluate()” applies the context to the given template and produces result using passed TextWriter.


Feel free to experiment with the solution above: download