In software projects, there is always present tension between producing new features and keeping the maintainability of the software. If maintainability is hard (bugs are hard to detect and fix, for example) and we are spending much more time maintaining than with implementing new features, we have significant technical debt. Keeping the right balance between the cost of fixing this debt and producing features that are creating revenue is essential for business success. In this article, I will point to some advice on how we as software developers can help to keep this balance.
Keep the Big Architecture Picture in Mind
First of all, we need to have a clear picture about the architecture and business goals of the software being produced. Without that, we can too often skip implementation details or overlook another possibility when implementing new features. Also, it helps to avoid unnecessary work and prevents the development of new features which are not aligned with goals or architecture.
Deal With the Most-Touched Codebase
The golden rule of facing technical debt is to first deal with areas which are touched the most. It’s simple, if you focus on the code which is rarely modified by developers and rarely needs adjustments due to business reasons, you are working in the wrong place. I am not saying that this code doesn’t need refactoring, or you’re not getting rid of technical debt, but obviously there are more important places to take care about.
Use Ubiquitous Language
As I was advancing in my previous post, it’s important to use ubiquitous language in all discussions and descriptions, and let this language speak in the code. You don’t need to follow all domain-driven design, but being able to talk about the same things with the same terms is essential to not adding further technical debt.
Technical debt does not even have coding standards. Also, not having coding standards for your test codebase is the big problem. If you have coding standards, you should continuously improve them with new rules and remove obsolete rules. A coding standards document should be a living document because when it’s a static page with the most recent modification being a year old, nobody will care. Also, it should be the basis for doing code reviews, and all team members should follow these rules when checking code.
Including Technical Debt Items Into the Backlog
It’s well known that you need to keep tracking technical debt along feature items. If you are agile, you will need to slightly accommodate the resolution of technical debt in standard team life. In one project, we had one technical debt item to get rid of in each sprint. It doesn’t matter how you work and what amount of time you allocate at the start. But you need some way to start successfully getting rid of technical debt. In one project we had a simple counter — the average time it took for the feature to be delivered to the customer. From the start we were on sixty-something days, and when we have one guy resolving technical debt per sprint we were down to 14-something days in a couple of months. Of course, there were other circumstances which were affecting our velocity, but for half of the stories it ended with cleaner and simpler implementation due to resolved technical debt.
Programmer's Oath Perspective
In reaction to Uncle Bob, I am advising you to follow the Programmer’s oath. I firmly believe that doing our best not to introduce potential technical debt and to follow industry best practices is a significant advancement in software development. You don’t need to sign this document because all the facts aren’t possible to follow at the same time, but just keep this in mind and your work will be technical debt free.
Keep Your Project Manager (or Team Leader) in Touch
Time to time I am in a company when the project manager or team leader is far removed from the implementation and architecture. They are solving only director-level stuff with spreadsheets, estimates, meetings, and planning. After some time, it’s difficult for such a person to understand why implementations take more and more time, and why it isn’t possible to incorporate this or that feature into the software. It’s up to us, developers, to continuously improve the knowledge of our managers and raise objections whenever we see why exactly the new features don't fit the software. I am usually looking at the tracking system and watching the backlog of planned items to keep track what’s going on. It helps me to have a clear picture of what managers think needs to be done and give me time to speak up early about possible problems.
Have you ever heard of it? It’s about not giving developers sufficient time for learning. Tight schedules, pressure from clients, etc., all of these issues can postpone the learning process to the “never” section of your to-do list. And it’s bad, because, after some time, motivation is going down, the best developers run away, and productivity drops. We can help with introducing hackathons, which are great opportunities to face some company problems, but only driven by developers, or Code Retreats to share knowledge around coding and current technologies. At Google, the staff members have one day a week for doing something which is not tied to their project. They can do anything which can help in other projects, or they can investigate an entirely new approach for something. Or simply learn something new. It’s important that the content of this day is totally only up to every single person. Maybe one day would be too much at the start, but you need to convince your managers that it’s better to have some time to learn than cry that someone left the project.
Help With Hiring
As I have been in the industry for more than eight years, I am not taking care of my colleagues. Our industry is not a school. Whenever I am joining the new project, it is of particular importance to have qualified colleagues. I am always happy to help with hiring new team members when I can. Interviews are disliked between developers, so you can elaborate a little and come up with a better approach. I would guess that your managers will appreciate this small help.
Help With Describing Features
If feature requests (aka innovation) aren’t sufficiently described, it’s always seen as “I am not thinking enough”. We have occasionally had tension to decline features which are not correctly described, and have negative feelings about them from the start. I would suggest being as helpful as you can to provide suggestions, point out affected areas, or ask unspoken questions about a feature. It can help others be understanding of the impact and feasibility.
The majority of us would agree that technological debt needs to be managed primarily by us, developers. But we should be quite diligent in more areas to have the proper working environment, staying motivate and productive. Being active, helping with dealing with innovation will reward us. Communication will be clearer. Motivation will remain, and you will have a much better feeling of produced stuff.