I know that we should be using TDD and stuff, but…
Let's talk about how to negotiate with project manager about tech debt and good engineering practices.
We often find ourselves trapped in technical debt within a project, passively watching the code gradually deteriorate and eventually losing control. Adding a simple requirement often requires a great deal of effort and can lead to a lacklustre outcome, compromising quality due to "delivery pressure."
Developers often exhibit great creativity in making poor technical decisions, citing reasons such as excessive delivery pressure, lack of emphasis on code quality from clients, or practices that are too idealistic for their specific situation.
When a tiger or rhinoceros escapes from its cage; when a tortoise-shell or jade-stone is broken in its repository: Whose is the fault? — Confucius
At face value, it is understandable that project managers/clients prioritize delivery dates while programmers pursue excellent code that is easy to understand and expand. If neither side is at fault for complaining, then whose problem is it?
Project managers or clients seemingly don’t care about code quality or maintainability, but trust me, they do. In most cases, they are just reasonable people, just like the developers. The problem concerns responsibility or the bravery to tell them the truth and have a conversation.
Uncle Bob described it very well in his book Clean Code:
“…what if you were a doctor and had a patient who demanded that you stop all the silly hand-washing in preparation for surgery because it was taking too much time? Clearly the patient is the boss; and yet the doctor should absolutely refuse to comply…”
Clean Code Martin, Robert C.
While it is true that business stakeholders may prioritize the timely delivery of software solutions over code quality, it is important to remember that maintaining code quality can have long-term benefits for both the business and the development team.
As a developer, it is essential to communicate the importance of code quality to business stakeholders and to advocate for best practices such as refactoring and writing clean code. By demonstrating the long-term benefits of maintaining code quality, you will likely persuade stakeholders to prioritize it alongside timely delivery.
The only issue would be how you frame your reasons. It’s important to speak their language. For example, high-quality code can lead to improved software performance, reduced maintenance costs, and increased scalability, contributing to better business outcomes. It’s essentially a high ROI investment.
We, developers, are the experts. We must tell them the benefits (pitfalls) of what we should or should not be doing when writing code. Just like a doctor should insist on their judgement on if it’s required to wash hands before surgery.
Thanks for reading this week's note. I'll see you again next week.