What ‘technical debt’ can teach the construction industry

By Steven Johns - Back-end Developer at BECODE

So, you’re working on a great project, results are flying out the window, life is great. Then, things start to slow. Every problem you solve seems to produce two more. Your team gets frustrated. Your progress stagnates. Your clients get fed up.

In software development, we call this technical debt. Technical debt isn't about the objective costs of development but rather the follow-on costs of rushing and missing things that are often looked over. Think of it as dishes piling up in the sink. Washing a dish immediately after its used adds a trivial amount of time to the process but gets rid of that as an issue down the line. We can continue to defer washing those dishes, but they'll just become more difficult to clean, will begin to attract literal bugs and establish bad standards that will make for an unhealthy household.

In construction, project management and compliance, these problems are things like inefficient processes, unstructured client communication and incorrect documentation practices. They may seem ‘good enough,’ but as your business, workload and ambitions grow, the cracks start to show. All of a sudden, those dishes that have been piling up in the sink are an absolute stinking mess – and you can no longer ignore them.

Take me back…how did we get here?

Technical debt is never something you acquire willingly. Rather, it’s the direct (albeit delayed) consequence of compromise or oversight. A lack of a clear vision, underestimating time, over promising results and inexperience are all huge contributors.

It's really easy to say "I'll just do that tomorrow," but "tomorrow" becomes "next week," which becomes "next month.” The longer the problem hangs around, the lower down the priority list it gets (in software development we call this the “backlog”).

As a consequence of this cycle, tech debt compounds very quickly and it can quite rapidly spiral out of control. Poor decisions made early on in the product or feature lifecycle can snowball into extremely large problems down the track, and similarly, a lack of thorough consideration, or band-aid solutions implemented at the beginning of a project can be disastrously time consuming to fix. A lack of strict standards early on could also affect culture around technical debt moving forward as new people are trained and hired.

Okay. You've sold me. What do I do to stop it piling on?

The great thing about technical debt is that while it becomes harder and harder to fix, you normally know how to solve the problem. Most organisations are not "too far gone" and the sooner that things are addressed the better. If it doesn't resolve the existing problems, it will definitely stop them from getting worse while another solution is put in place. So, here are some ideas:

• Standards need to be developed and they need to be strictly enforced. Management also needs to be aware that things might need to take 10-20% more time to produce, but with significant benefits across the board -- including reduced time down the track.

• Questions on technical debt during hiring of both management and staff need to be asked. Making sure that candidates are aware of the concept, or even informing them about it and letting candidates know that management is aware of it, will have immediate cultural benefits*.

• Even with a good plan in place, tech debt does creep in. Take a week out every quarter or six months to catch up on things that might have been missed and integrate that into everyone’s workflow. This means you’re systemically minimising the amount of damage technical debt can do to your business to six months.

• Catch up on undocumented features and purge legacy documentation regularly.

• Have a culture that encourages things being built right over being built fast -- within reason, of course. You won't regret it if your goal is to have a longstanding presence or a solidly built product.

Hopefully all these tips will help, but if I can leave you with one final piece of advice it’s this: Give people ownership over the things they've built. No one wants to clean someone else’s dirty dishes, so, if a developer or team feels like they own it, they'll be more inclined to take care of it. And if you give your staff ownership over the projects (and processes that make them happen), they’ll be more willing to put in the time for a quality result, even if it put’s them out in the short-term.

Tech debt might just be a software development term, but the concept itself extends across almost every workplace. Those dirty dishes that pile up can be seriously unhealthy for your business. However, if you take a proactive approach, develop the right standards and encourage quality over quantity, tech-debt can become an issue that drives positive change and decisions in your organisation.

-----

*I've made sure to, when interviewing, ask candidates about their familiarity with things like testing and the various tooling around it, ask why testing might be important and tell them if they miss key points. I also emphasise that I expect to see at least one module well-tested in a take-home exam. Two hires had never written tests before that interview, and after starting they immediately began writing tests as part of their development process without being asked to.