Agile ways to reduce technical debt

 

Background

After a long time I thought of sharing my views about managing technical debt in an Agile project. The views expressed here are not only limited to Agile and I believe they can be used in any methodology. A debt is anything that we incur over a period of time. This could be due to various reasons like formation of a new team, people leaving the team, new technology etc. These are mainly related to the technical aspects. There could be a functional debt occurring due to similar reasons. Since Agile teams tend to time box their iterations there is always that extra pressure to deliver the next increment within the iteration cycle. In order to achieve the iteration goals  team members try to take shortcuts due to time and at times peer pressure to come up with shortcuts which starts building the debt.

 

Various reasons for building technical debt

Lets look at some of the common scenarios which are responsible for building the technical debt.

• Formation of a new team

One of the most common reason is when the new project teams are formed. You have people from different parts of the same organization of different organizations coming together. As the team takes time to understand the dynamics of working together, there could be different styles of working between different team members. There might not be a agreed coding standard to which all the team members can confirm to. These things surely improve as the teams gel together. But it might take some time and effort to re do things which were done initially.

• New members joining the team

I have found it one of the most difficult thing to get started on a new project with an existing team. It takes quite sometime to understand the ways of working of the team. If you are new to the domain then it is even more time consuming to understand the functional as well as technical side of things. For the experienced and seasoned professionals it might be little bit easier to bridge the gap. When it comes to new recruits it can be a big task specially in those places where the difference between the practicality and academic studies are quite contrasting.

• People leaving project or organizations

Organizations all around the world have hard time  retaining the same team over a long period of time for the complete duration of the project. It is quite normal for people to choose to move into a new team within the same organization or even change organizations due to various reasons. If a person has worked on a project for a long duration then obliviously he or she is bound to have acquired a lot of functional as well as technical knowledge about the project. As part of the handover managers usually ensure that this key knowledge is transferred to some other individual but very rarely does it happen that all the knowledge is transferred as expected. Many teams use a wiki to share knowledge among team members. My personal experience says that creating design documents and any other lengthy documents under the name of process is of no use. First and foremost its very difficult to keep these so called design documents in sync with the changing software. And secondly the way they are interpreted by different people is also different. I tend not to give too much importance to these documents. Their relevance is lost fairly quickly.

• Time constraints

One of the most common excuse people have for increasing the technical debt is “Time”. Almost all the customers want everything to be delivered as the highest priority from their product backlog. This might not allow the development team to concentrate on the technical excellence. My experience says that this leads to things like not making use of proper patterns like Design patterns or enterprise patterns while building solutions, lack of unit tests, skipping integration tests, lack of automated tests.

• Lack of knowledge / skills

Not always do developers have control over the choice of tools and technologies that are used for developing software. You might end up working with a team where everything that you see and hear is new for you. Just to give you an example if you have joined a new team which uses Silverlight technology for building line of business application, NHibernate as ORM, WCF as service layer and SQL Server 2008 as database server, MS Test as unit testing framework and Rhino Mocks as mocking framework. In most likelihood you’ll have people with different skillsets in these technologies. Someone might be a beginner while some other person might be an expert. As a result the way both the people might approach the same problem with different mindsets. 

• Lack of standardized practices and processes

In order to build quality code the team needs to have a agreed set of guidelines which all team members need to follow. These are basic things like coding standards document, agreed definition of done, inclusion of quality metrics like code coverage as well as automated code analysis.

 

Different methods of reducing technical debt

You will find symptoms of  one or more above debts in almost every project. There is no sure shot solution to any of these problems. What works for one team might not really work for others. We can only try and reduce the debt and make sure that it is kept to minimum at every level. Lets look at some of the ways which might help to reduce these debts.

• Formation of new teams

One of the common thing to do at the time of forming a new team is to go slow in the beginning and ensure that everyone understands what's going on around them. At the beginning of the project there is lot of work needed to be done on infrastructure side like setting the build, creating the project structure, choosing the tools or third party dll’s, setting up the source control etc. The team as a whole can work on these tasks. For e.g. this helps in ensuring that everyone is aware of why a certain folder or file was created in a certain place. You need not go about asking the person who created it and why is it needed. If there are multiple choices available and you are required to choose one among them then may be two or three people can evaluate things together so that the decision which is taken is not biased and based on an individuals analyzing skills.

• People leaving the team or organization

In my opinion this is the most difficult thing to manage as part of debt. Agile doesn’t support much of documentation. The best thing to do  is to avoid having the knowledge confined to a single individual. Obliviously you can’t satisfy each and every individual in your team. There comes a time when you need to let go the best people within the team whether you like it or not. To be honest every time I hear someone say that so and so individual is very important to a project I can sense that there might be lot of technical debt in that project. The moment you reduce that dependency you secure yourself from one man show and ensure greater success for your team.

Its not just limited to people leaving the organization. There could be extreme cases where a person has gone out of town or city or country and a critical bug arises in the production environment. You definitely don’t want only one person in the team to know about the functionality which is breaking. Think of another extreme scenario where one of the team mate has to go on a month long vacation may be for medical leave or for something special like marriage. You don’t want to disturb someone when he’s lying on a hospital bed or enjoying with his or her better half on a honeymoon trip

• Time constraints

Most of the times when I discuss with people why they did some things in a certain way and not the other way round, the standard answer is due to lack of time. In a hurry to complete something in a short duration people skip some steps and take shortcuts. Many times things which could have been refactored and implemented in a simple way get neglected due to lack of time. People always say we’ll finish this and then refactor everything at the end of the project or at a later point of time. Trust me 99% of the time it never happens. If you can’t refactor today there is very little chance that you’ll do it later. And those big bang refactoring steps are always more dangerous than the smaller ones. Once again refactoring is a very huge topic and there are dedicated books and blogs written about it. If I was the scrum master or project manager or a person in a position to take a decision I would rather spend little bit of time now to fix things as they are instead of piling on them and trying to fix everything together. The downside of taking shortcuts is that you might be able to finish things on time but the quality of the output that your team is producing is bound to be affected. My personal opinion is that no one cares how fast you deliver something but how well you deliver what you have delivered. Customers and clients would be much more happy to see 3 of the 5 requested functionalities working fully rather than 4 of 5 functionalities delivered but only 2 of them working as expected.

• Lack of knowledge

One of the best ways to reduce the skill gap is by using pair programming. Pair programming helps in reducing technical debt to a great extent. In my opinion almost every line of production code should be written by a pair. People normally tend to think that when two people work together the productivity goes down as one persons man hours are not accounted. It is proven and from my personal experience I can confirm that this is not true. You get some of the best results when two brains are working together on the same problem. (Provided both the partners who are pairing contribute). If there are any issues found during testing or some enhancement needs to be done then potentially there are two people capable of handling it. You also get some of the best ideas while discussing with your pair. You might come to a solution to a complex problem much faster if two people are working compared to a single individual working on the same. I’ll leave it for another post because pair programming is very close to my heart

• Lack of standardized practices and processes

It is very useful to have a standard way of developing different components within the same team. Hence a coding standard needs to be followed so that its easier for everyone to work within the team. The team also needs to decide upon the different metrics they are going to use to gauge the quality of their code. Some of the things which I have used during my career are the percentage of code coverage for unit test, various code matrices like cyclomatic complexity and maintainability index etc. We as developers have too much confidence in our code. But its always advisable to run code analysis tool to make sure the code confirms to industry standards. I personally like FxCop and StyleCop for dynamic and static code analysis. There will be things which these code analysis tools suggest or treat as errors or warnings. But they might be valid as per the teams conventions. In such cases these tools provide facilities to customize the default settings. I recommend that these tools should be integrated the build process itself. Some of the teams I have worked with had these tools integrated into continuous build and would even fail the build if things like code coverage was not met. If there is a way to enforce the standard or a process it should be done right from the beginning. 

 

Conclusion

Its always a herculean task to ensure that the team is self organizing and has what it needs to do its job on a given day. Many a times things are totally out of our control and we can only make an attempt to get things back from going from bad to worse. Technical debts keeps occurring during development every now and then. The more they increase the more dangerous they are for the maintenance of the project. But one of the motive behind the Agile moment is that we deliver quality software. If your team is serious about practicing Agile then you should aim for a quality product and not the quantity. People always remember how well you did a job and not how fast you finished it off. I believe in software craftsmanship and delivering quality with everything I do. I am sure there are many more techniques to reduce the debts. I would like to know about them. If you know any please drop me a comment.

Until next time happy programming

Share: