When a development team is working on a software project, there is always going to be tension between the necessity to deliver your product and the desire to engineer your code to a high level of quality. I’ll refer to these two “forces” as the delivery mindset and the engineering mindset.

According to the delivery mindset, the number one priority for a development team is to release software which

• Meets business requirements

• Doesn’t exceed budget

• Is delivered on time

This is important, as it pays the bills. It’s why we were hired in the first place!

With an engineering mindset, the highest priority is the quality of the codebase, ensuring that:

• The code is well tested and is bug-resistant

• The codebase is easy to maintain for future development

• The code is built to handle all edge cases elegantly

• Technical debt is kept in check

The engineering mindset is just as important as the delivery mindset as it ensures a high-quality codebase, allows for faster development in the future, a more stable product and fewer overheads in on-boarding new developers.

As you’re probably aware, taking on too much of a delivery mindset can compromise the quality of the codebase and negatively impact the future of your product. Likewise, taking on too much of an engineering mindset can mean you miss delivering on a crucial business deadline. So how do we find the balance? I believe the answer lies in working closely with non-technical stakeholders in your team.

These guys…

Ensure you have a line of communication to the product team

Depending on the situation, there will be a team or individual in charge of setting the business requirements for your product. The closer you are able to work with this team, the more opportunity you will have to make an impact on the decisions around feature development and prioritisation of bugs. Effective, regular communication with the product team can make the difference in delivering on the business objectives or not. If you have no avenue to engage with the stakeholders in charge of the product, this is a red flag and you should raise this with your management ASAP.

There should always be a “product owner”, someone who represents the interests of the business. Know who this person is and get them involved when the team is having trouble reaching a decision. It is your responsibility as a developer to make sure the product owner understands the business impact of decisions which are made during development.

Here are some ways to effectively collaborate with the product team and protect your precious codebase:

Know the problem you’re solving

Often, you’ll be given requirements which explicitly describe exactly how the software should work. In this case, you’re being told what the solution is, not what the problem is. Try to understand what the higher-level business objective of the proposed solution is and assess whether or not there may be a less complex solution which meets that requirement.

Instead of implementing things exactly how they appear in a requirements document, get in touch with the product team and present your alternative. You are the technical professional, so it might be the case that you’ll be presenting something which they hadn’t considered, or knew was even possible. Help them understand the cost and risk of the more complex solution, so they can see the value in what you propose. If the alternative you offer results in meeting business requirements for a cheaper price tag, then it’s a win for the project and a win for the quality of your codebase due to less complexity.

Pair your clarifications with suggestions

There will be times where you need more information on a requirement before you can build a feature. See this as an opportunity to suggest a solution which you believe meets the business requirements, and which introduces the least amount of complexity to the codebase. In my experience, 9 times out of 10, the product team will be grateful for your input and will ask you to go ahead with your suggestion (perhaps with minor tweaks).

Know the acceptable limitations of a feature before handling all edge cases

Sometimes when building a feature, the classic “80/20 rule” applies. Developing the remaining 20% of your feature ends up taking 80% of the time. Software development has a way of dragging out when we really try to cover all cases, however unlikely they are to occur. Be aware when working on a feature and encountering this situation. Don’t dive down the rabbit hole straight away, instead get in touch with the product team and discuss if the app needs to handle these edge cases, or if the 80% mark is sufficient to meet the business needs. Give them the numbers. Usually, they will think that last 20% is important until they see the remaining estimated hours of development required to get it done. Perhaps the remaining 20% of use cases can be prioritised for a future release. This way, you can shave off a lot of time and code-complexity and still deliver a feature which meets the core business objective on time.

Refactor opportunistically

It’s pretty hard to convince the business that you need to spend time refactoring code and not delivering features. Instead of having a specific refactoring task in your backlog (which never gets prioritised), consider refactoring code when you begin a task which touches a dubious part of the codebase. There are a couple of benefits to doing it this way:

1. You will still be delivering something, so the business will see it as a task that has gone over the estimate, rather than a piece of work which results in “nothing”.

2. If you refactor code to implement a new feature, you’ll be more confident that you’ve refactored that area of code in a useful way.

But before you commit, weigh up the following:

• How will this reduce work effort for future development in this area of code?

• How will this increase the stability of the product?

• Can I justify to the rest of the team why it was worth this task going over the estimate based on the benefits?

If you can’t justify doing the refactor in business terms (reducing risk and future cost), then perhaps it’s not the right time to tackle it just yet. It’s a tough decision to make, but thinking of the above will help you make the right choice, and help you convince the business that you’ve made the right choice.

You are the technical expert

There will be others in your team who understand the business objectives better than you and others who understand the product and design better than you. However, what you understand more than anyone else is the codebase - the underlying technology which powers the whole thing. You understand the consequences of introducing unnecessary complexity into a technical solution. The key is developing an effective way of communicating this back to the team so they can know how the product will be affected in a way that they understand. I have found that the best way to do this is to explain things in terms of cost (i.e. hours of development) and risk (increased chance of bugs, added cost to future development etc).

Learning how to communicate effectively to the product team in terms of cost and risk will make you an effective protector of the codebase. Your engineering mindset will be under less pressure, and you’ll have a fighting chance to actually deliver your product on time.