Meeting In The Middle: How a Product Team and Product Owner Can Build Ideas into a Reality
Our developers strive to produce high-quality, well-tested code that works seamlessly. Code should be easy to extend and simple to understand, both for our future selves and other developers. In our field, we constantly have conversations about writing maintainable code and coming up with good abstractions for the underlying business domain. There are many sayings that go along with coding about maintaining perfection, but is that the right approach?
At Borne, the heartbeat of our company is client projects. Working with clients, specifically product owners and founders, and making decisions together about the direction of the product is a constant in our work daily. As it naturally happens, product owners and founders are excited to move at a rapid pace, delivering features to users as quickly as possible. So how can we balance that desire with making the right technical decisions? Sometimes creating software in a maintainable, scalable way can be slower than simply building something which works, and the benefits might not be obvious immediately to a non-technical product owner or founder.
Open Communication
Like so many aspects of what we do, a big part of the answer is good communication amongst our team. Having an open and honest conversation with the product owner about the trade-offs on each side of a technical decision is really important. In our experience, these conversations tend to be longer and more fleshed out the first few times they happen on a project.
As the project progresses, trust between developers and the product owner builds, and we tend to understand each other’s judgements and motivations better. As developers, we have a responsibility to communicate clearly why we would recommend a particular technical decision — these decisions could have been made for reasons of code quality/maintainability or performance.
What might the repercussions be of not taking that route? As the product owner, it is important to communicate the context of the decision. Is there a specific urgency around getting this feature shipped right now that makes taking a technical shortcut worth it?
Addressing Technical Debt
An important part of the conversation is the concept of technical debt. Technical debt brings a financial analogy to our project codebases. The idea is that shortcuts that we would make while writing code and making code design decisions result in debt. The debt can exist in the form of badly organised code, poorer abstractions and worse quality code in general. Unless the debt is paid off by addressing these compromises, we would pay interest on the debt through changes and additions to the codebase taking longer. This ultimately could result in features being slower to ship. Furthermore, because concepts in the code are less clear, it becomes easier to accidentally make the wrong change and ship bugs to your users.
This definition may sound doom and gloom. But, treated the right way, technical debt can be a valid, useful option during a project. Technical debt can be used positively if it’s accumulated deliberately and prudently.
So what does that mean?
We have the responsibility to make sure such decisions are considered thoroughly and not made in isolation. Our designers and developers are there to have the conversation with. Another point to raise is to have a plan in mind for addressing the debt. What might a better solution look like? Are there future features that touch on a similar area of the codebase which might provide a good opportunity to tackle the debt when constraints are different?
In this scenario of a client project, an important part of the learning process and a feedback loop is to openly call out scenarios where technical debt is slowing us down in developing your product, and raise whether now is the right time to pay off the debt through refactoring or revisiting past decisions made about the architecture. This is where our team can help you in understanding and taming technical debt in your product.
Code Quality Maintenance
Keeping in mind, consciously accumulating a small amount of technical debt does not give us a free pass to throw good software design out the window! The important thing to remember is that even if we’re making trade-offs, we always want to ship high-quality code.
Having honest conversations between product owners and developers is critical. Reaching an understanding of each other’s motivations is an important step in any project. Our team at Borne have found that it is useful to get into the habit of having these conversations early in a project, to avoid having them for the first time when your milestones are approaching.
