The truth about Technical debt?

I am always posting provoking post on my Linkedin, and I have decided to replicate those here. Let’s socialize!

Technical debt is widely used and discussed within engineering teams. However, in people mind, it looks like it accumulates because of some nasty, dirty practices.

Technical debt piles up even when you work with the best intentions and follow the best practices.

Why?

Because Tech debt is not ONLY a result of prioritizing speedy delivery or poor development skills but a natural result of writing code about something we don’t have a proper understanding of the complete solution

Knowing that, a natural response is to invest more in the design phase. However, in reality, you can not capture and learn everything before start implementing the solution. The future is uncertain and might bring radical changes.

A leaner cycle is the best option. Take a piece of the Design effort and move it forward in a refactoring phase that happens every time a few pieces have consolidated and are ready to be secured.

In this scenario, we accept debt creation, trusting our ability to repay it in the short term.

Like financial debt, tech debt can harm or help your organization. To use it wisely, engineers and team leaders must monitor how much technical debt they acquire and learn to manage it well.

Free Advanced Java Course

I am the author of the Advanced Java for adults course. This course contains advanced and not conventional lessons. In this course, you will learn to think differently from those who have a limited view of software development. I will provoke you to reflect on decisions that you take in your day to day job, which might not be the best ones. This course is for middle to senior developers and we will not teach Java language features but how to lead complex Java projects.

This course’s lectures are based on a Trading system, an opensource project hosted on my Github.