Innovation versus technical debt

First of all, we need to have a clear picture about 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 new features which are not aligned with goals or architecture.

The golden rule with facing technical debt is first to 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.

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 in checking code.

It’s well known that you need to keep tracking technical debt along feature items. If you are agile, you will need slightly to 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. In another, we had technical debt that for a member of the team who was resolving technical debt items for the whole sprint. Doesn’t matter in which manner you will work and how big amount of time you will allocate at the start. But you need some way how you will measure the success of getting rid of technical debt. In one project we had simple counter — average time 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 have 14 something 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 right due to the fact of resolved technical debt.

In reaction to Uncle Bob, I am advising to follow Programmer’s oath. I firmly believe that doing our best not to introduce potential technical debt and follow industry best practices is a significant advance 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.

Time to time I am in the company when the project manager or team leader is too far from the implementation and architecture. They are solving only director’s stuff with spreadsheets, estimates, meetings, and planning. After some time, it’s difficult for such person to understand why implementations take longer and longer time. And why isn’t possible to incorporate this and that feature to the software. It’s about us, developers, to continuously improve the knowledge of our managers and raising the objections whenever we see why exactly the new features doesn’t fit the software. I am time to time looking for the tracking system and watching the backlog of planned items be on track what’s going on. It helps me to have the clear picture what the managers thinks needs to be done and give me time to speak early about possible problems.

Have you ever heard about it? It’s about not giving sufficient time for learning to developers. Tight schedules, pressure from clients, all of these issues can postpone all the learning process to “never” area. And it’s bad, because, after some time, motivation is going down, best developers run away, productivity is dropping. 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. In 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 the entirely new approach for something. Or simply learn something. It’s important that 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.

As I am in industry for more than eight years, I am taking care about my colleagues. Our industry is not a school. Whenever I am joining the new project, is of particular importance to have the qualified colleagues. I am always happy to help with hiring new team members when I can influence my further colleagues. Interviews are disliked between developers so you can elaborate a little and come with the better approach. I would guess that your managers or leads will appreciate this small help.

If feature requests (aka innovation) aren’t sufficiently described, it’s always flag of “I am not thinking enough” approach. We have occasionally tension to decline features which are not correctly described and to have negative meaning about them from the start. I would suggest being as much as helpful you can to provide suggestions, affected areas or unspoken questions about a feature. It can help others to be understanding of the impact and feasibility.