Refactoring, Uncategorized

What kind of debt is your technical debt?

The word “debt” is usually related with money. When you take money from somewhere, you have to give it back. It’s pretty obvious that if you don’t, it’s considered a crime. The story complicates when talking about technical debt as we don’t remember to pay it off. Based on that I’d dare myself to separate two different kinds of debt.

Debt as a credit

Let’s say there is some good investment that requires funds that you don’t have. In such case you can get a credit that helps you achieve the goal. As it’s serious thing, you think carefully about the conditions and consequences. If you finally incur the debt, you have a plan how to pay it off. Even more, you pay it in the first place as not paying it results in penalties. All in all you think of it as of something positive, because without it you would not succeed.

Same goes with technical debt. If managed properly, it is just another tool that helps in achieving the goal.

Debt as a speeding ticket

This type is completely different for various reasons. You don’t plan it, it just happens. Of course it is not because of bad luck, it’s effect of breaking the rules.

The other thing is that many people don’t want to pay the ticket at all. As it comes from nowhere, maybe it will vanish by itself. You think of postponing the payment for a better future, when you pay back everything else. Or hopefully it will be forgotten and you won’t have to pay at all.

All in all whatever happens, it is not something that you are really proud of. And finally postponing the payment usually results in high interest and additional penalties.

In development world if you do nothing with the debt, it will grow and may kill you (indirectly force you to quit the job) or at least multiply the cost – instead of refactoring one class you will have to rewrite the whole module.​

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.

image

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

Refactoring, tools, Web

Removing unused UserControls with NDepend

Untitled2

NDepend is an amazing analysis tool for .NET code. It gives you deep insight into your code and let you manage its quality easier. It lets the user execute LINQ queries on code, generates dependency graphs, metric view, check rules and many many more. In this post I’ll show a very simple trick to detect unused user controls that can be removed from our project.

NDepend was recommended by Scott Hanselman, Greg Young and others. I tried it some time ago in my small project but I couldn’t benefit from the tool. After some time I had to do some cleaning in our legacy system. Then I came back to the the tool and I have to admit that I fell in love with it.

Some time ago I wrote about Finding unused private and public methods with Resharper. It is of course very nice way of doing code clean-up but in rather smaller systems. In my case Resharper found around 2.5 thousand issues and it’s not an amount that I could face in one or two iterations.

Some issues are specific to particular parts of the solution. In WebForms project the highest level of abstraction is Page and Control. If the user removes/refactors page and decide to not use some user control it becomes dead source of other dependencies.

In the first iteration I decided to get rid of unused pages with help of google analytics report from the last few month. The next one was about dead user controls. Resharper doesn’t allow us to find unused types deriving from specific base type. Here is the place for NDepend.

In “Queries and Rules” section I run the following query:

Untitled3

As a result I got the list of around 30 user controls. Unfortunately this is just an input for further filtering because it lists controls that are not used in code, but not saying anything about markup. All in all checking this is not that hard, one solution is to go through all of them and check what compiler says or find all occurences of “<%@ Register Src="~/Path/MyUserControl.ascx" TagPrefix="uc" TagName="MyControl" %>” for each *.ascx file.

Refactoring, tools

Find unused private and public methods with Resharper

7There are times when you find dependencies of some legacy code in a method that is never used. I personally always have a feeling that one day I need to find a way to search for all these unused methods and just get rid of them. Here I want to show you how to do it with Resharper.

 

Solution

There is a nice inspection tool built into Resharper that can show us different code issues found in the solution. Among them we have a metric called “Type or type member is never used”. By default it presents private types and type members (methods, fields, properties, etc) that are never used. To make R# show us also public (or in general ‘non-private’) types and members you need to enable “Solution-Wide Analysis”.

1. Go to bottom-right corner of visual studio, right click the circle and click “Analyze Errors in Solution”

1

2. You should see a message that solution-wide analysis could take a while, but don’t be scared, for me analysis of a big project (more than 60 000 statements) took less than 2 minutes.

3. Go to “Resharper –> Inspect –> Code issues in Solution” (or current project if you wish).

3

4. After code analysis it should show the inspection result. To filter only the unused methods (type and type members) click “Filter issues” button.

4

5. In the “Filter Issues” window “Uncheck All” options and then go to “Redundancies in Symbol Declarations” and check “Type or type member is never used” (here you can specify that you want to see only private or non-private stuff).

5

6. After that you can group the report by some additional criteria – I prefer project structure. From now on you can click each and every issue and do some actions on it (mainly “Remove unused …”.

6

Final notes

Although we have a full list of unused types and type members, we cannot bulk remove the issues and forget about them. Some of the issues should be treated specially because they can be used in ASP.NET markup, WCF communication, serialization and any other way that cannot be figure out by Resharper. All in all it’s good that unused interface implementations will not be taken as issues.

Happy refactoring. And don’t forget to turn off Solution-Wide Analysis.