Which is more important: delivering a feature on time to be first to market while leaving behind spaghetti or achieving a "perfect" solution with the highest product quality?
I’m sure you can easily recount the number of times you’ve been in a meeting with your project manager, when the company you are working for has requested a new feature or product to be developed ASAP. A tight deadline is given, based on the need to align with a product launch or boost the company's bottom line.
As engineers, we understand the requirements and we often pride ourselves on having expert problem-solving skills in our field, we might feel compelled to show off these skills; as this is what we have been hired to do! So as per our company's request for a hastily developed feature, we might be tempted to jump in and showcase these “building” skills.
So we might reply to the feature request: “Yes, I’ll meet the deadline and it will be perfect!”
Later after smashing out a bunch of 20-hour work days, late nights and several cases of RedBull; we completed the feature perfectly as our family and mental health have taken a backseat!
“Well done!” our company responds - “Now do it again!”
What have we just done?
Well, we’ve just taken the road to hell, called burn-out!
While this might seem extreme, no human on a continuous base can keep the above pace up; something starts to give, overworked engineers eventually start suffering from poor mental health and their output and quality of work drastically drops!
On the other side of the fence, we might take up our engineer’s “responsibility” and explain that based on the requirements this feature is going to take the team months if not years to complete. Especially to deliver the feature “perfectly” with 110% test coverage and all security and scaling factors considered ensuring it can survive cosmic bit flipping the requested deadline is not set in reality!
Let us assume the business respects our timelines, what would be the business impact? Well, this could eventually negatively affect the bottom line of any startup and even in a large corporate client, not delivering updated products or features would eventually chip away at their market share.
So what do we do?
Finding a Balance
Do Quality or Deadlines weigh more? Well, that depends on several factors!
Let us be honest, neither of the above approaches will work, rather we need to strike a balance, both the quality and deadline will need to give a little and depending on the type of feature, one area will take a more significant knock.
To find the right balance, we will need to factor in whether you are working at a start-up or a large enterprise, whether the product is a critical component or back-office processing, what risks are involved, and how will this impact operational and security within the business.
Well, let us unpack three of these mentioned areas.
Type of Product
We have to identify the type of product, who is the end-user, what it is intended to do and most importantly, what needs to be done to make sure the product is successful, it is critical to understand what the “end” quality needs to be. We need to be aware that not all products, features or services require the same engineering effort and love - some must be perfect whilst many others only require basic security and performance. For example, at a start-up, you may be aware that the feature will be revised or discarded in a few months and doesn’t require all the correct checks and balances in place or building a payment processing engine vs implementing full user journey tracking has a stark contrast in the level of complexity and product quality.
Clearly in some use cases, you might be able to trade the quality of a solution to successfully meet the other end of the scale - the deadline!
Best-Effort Quality
This trade-off is where you might request an extended deadline but you are still delivering a "best-effort” quality solution.
As engineers it is our “responsibility” to clearly explain to the business, that due to the tight deadlines, the quality of the solution will greatly impact the business and we cannot agree to such tight deadlines, rather we going to have to come to a compromise with business to meet a “best-effort” medium to a low-risk solution, yet still delivering within a reasonable amount of time.
This often requires a senior engineer or project manager to understand the cadence of the team or we need to swallow our “problem-solving” pride and admit our human limitations. Otherwise, we will soon find out we are not able to continuously deliver time and time again, as we come headfirst with mental fatigue and burn-out. This is why engineering teams need proper rest and work-life balance, if they are given projects with tight deadlines over and over again and there is no room for wiggle; eventually, the cadence of the entire team will come to a very slow crawl.
This approach is usually best as it factors quality and deadline equally on the scale.
Enterprise or Startup?
If you are working for an enterprise-level company, which is a well-established client in the market place then you’ll see that they are much more flexible as far as deadlines are concerned. Usually, big businesses can’t compromise on the quality of a product, as they are most likely servicing thousands if not millions of customers they understand that good software takes time to develop and will work with you to try and meet the goals as their reputation is on the line, especially if their new feature breaks down around it is released into the market.
For start-ups and even small enterprises, these rules are drastically different. Firstly their customer base will generally be understanding if a system or solution is broken for a few hours as it is relevantly new. These types of businesses will also often re-iterate, refactor and pivot their products and possible entire business solution several times over their lifetimes.
Often the aim is to deliver the product as soon as possible to capture the biggest share of the market and as quickly as possible; therefore time plays a big constraint for startups. These teams will often adopt the “Fail Fast” methodology. So for them, they don’t hesitate to compromise slightly on the quality or shred off the extra functionality causing a delay in deadlines. Their main objective is to establish themselves as the market leader, helping them gain valuable market share in a new vertical before it becomes saturated with competition.
Conclusion
Engineering has many complex problems, and quality and deadlines have been and will always be one of these tough problems, understanding what variables go into deciding which approach to take is a skill every engineer should learn to cultivate over time.
In short, the answer as to what should I give more importance to is either quality or deadlines, well as you can see, this is based on several factors, including the type of feature and quality requirements.
These factors need to be considered carefully, but the main idea is that every project is different and will have different quality and time-to-market goals. It's up to executive leadership to determine an effective business strategy that includes a thorough analysis of the opportunity costs and risks of choosing one method over another. Not to forget we as engineers have a responsibility to inform the leadership of the risks and factors they need to consider when rushing to build software.