What is technical debt? If we ask our friend Google he will tell us something from Wikipedia for example:
“Technicall debt, also known as design debt or code debt is a concept in the software development that describes the implied costs of additional rework caused by choosing an easy solution instead of using a better approach that would take longer.”
Ok, I think we’ve got the point. Doing things right from the beginning does affect the quality and the result for the customers. So why don’t we just do that in the real world? Think about your last three projects for a moment. This was just the thinking you and your team had when you started your work, wasn’t it? But what went wrong in the past? Ok there were some milestones your team was faced with and there was not enough time to solve the challenge with clean code, a good documentation and so on until the deadline. So you and your team took the easy, quick and dirty way to code the stuff really fast down. And it does what it was supposed to do. “We should fix this after the whole work is done…”. Ok, here is my question: have you done it till now? Of course not. Nothing will run longer in a company then the crazy stuff you code for an interim solution. But all yourself: isn’t it slow, faulty and bad documented? Yes, it is.
There are different reasons, why technical debt is produced over the lifetime of your application. So, let’s try to categorize them in smaller parts. The first categories of technical dept are reckless vs prudent and the second ones are deliberate vs inadvertent. If your team members are not very familiar with solving a problem by a special technique like a development pattern or special language characteristics like LINQ, lambda expressions and so on or if they have developed a bad design for the different layers of the application, all that will add more and more technical dept to your project. And it’s like financial dept. So your team has to pay off the debt at a time.
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
— Ward Cunningham, 1992
So, what can you do to solve the problem of technical debt?
- At first: slower is faster! Leave a buffer after creating something great and pay off your debt, before it is in production too long.
- Use agile planning like the Scrum method. It can help you developing better, faster and very transparent with real-time feedback from and to your customers.
- Release often. Microsoft said 3 times a day must be possible for the whole deployment process. To do so, you have to automate a lot.
- Automation and working together with all team members like admins, testers and developers is the key of being successful.
- Don’t feel ashamed to ask for help if you don’t know how to do things right! And let your teammembers ask you to, because today you can’t know everything at any time.
This is a list that empowered me and my teams.
Have a nice day and let your team know about this post and my blog. Feel free to ask questions and I will response as fast as I can.