We were in the last stretch to ship a redesigned, reengineered, microservices-based analytics product. After a 6-months design phase, we were coding the last microservices to ship the product.
It was a year-long project, and obviously, we were behind. We did not exactly know when we will ship. What did we do? We set deadlines.
As much as you want to protect product quality, deadlines create technical debt. You have variables like numbers of engineers, reducing scope, buying a third-party product to cut some development cost, even outsourcing, but that won’t solve the effect that deadlines create on engineers.
An engineer on a deadline is like a factory chimney polluting the environment: we know it is wrong, we allow it, and we think we will fix it later.
The problem is not the deadline itself; it is the belief that the deadline is more important than the product quality.
An engineer will think that “if my boss doesn’t care about quality, and all that matters is to meet the deadline, then I might as well throw the lowest quality code possible, and fast.”
How do you prevent deadlines that create tech debt? First of all, make clear that the product’s quality is more important than the deadline. Still, we need to honor the deadline.
The second challenge to protect the product’s quality: you can have beta users or product managers testing the product, but we are talking about tech debt at the code level.
A simple tool is code reviews. Promote cross-engineers code reviews, and put together some coding style guidelines, and some short tutorials on how to code things.
Technical debt means code only one (or a few) engineers will understand. If you have an architect or someone responsible to come up with ways on how to code, everyone will be coding with the same principles, and that will reduce tech debt.