On technical debt

The other day I was listening to the new honeybadger-podcast “FounderQuest” (which I can highly recommend btw!) about the technical shortcuts and decisions they took to bring their product to market.

In this specific context of an early startup it is all about “surviving” and acquiring customers as fast as possible. In the end it is an easy choice: get paid or do yet-another rewrite of your customer-module to support high growth - which may never come.

The issue is not if you take the conscious decision to hack a feature together in order to support a use case. The problem occurs if you never revisit the decisions you have taken. Especially if your product becomes very successful and you hire more engineers that will help bring your application to the next level, it’s these kind of decisions that will prevent faster growth. This can potentially even frustrate your new-hires until the point they will leave to work on $INSERT_SHINY_FRAMEWORK_HERE.

So, should you always design every feature upfront using event-storming sessions to make sure you and your stakeholders talk the same ubiquitous language? In general this is not a bad idea per se but as always in software development: it depends. Having various meetings with various people obviously slow down your process to deliver value to your customers. That is the ugly truth and not everyone wants to hear. Does it help to make your new features work-as-expected? Probably. But is that worth it? In successful companies the velocity to deliver new features, start a new A/B-test etc. is so high that a feature designed weeks or even months ago just cannot have the right context. Even worse: In the meantime of designing and implementing a new feature you can learn so much about customers and their expectations that cannot be taken into account.

After all of this “the world is burning”-talk, how can we fix or at least improve the issues we have when developing software in the highest quality possible? Simple answer: It’s empathy. Every person involved in the software development process, from product owners, quality assurance, engineering etc. needs to be empathetic to understand the goals, visions and ideas of the other person on the table. A product owner for example also benefits from higher quality in software as he does not need to plan X% of the development time for bugs every sprint. A developer needs to understand the pressure in business requirements to implement a feature Y faster than the biggest competitor. The list goes on. All of these different points-of-view sum up to the final result we can present to customers. It’s each and every single person’s responsibility to make sure that necessary shortcuts will be revisited with new learnings we can make with every ticket deployed to production.