Elevate Winter Summit has been announced (Fri, Dec 11th).

🔥


Don't have an account? 

Are We Solving the “Right Problems”?

Impact
Productivity
Prioritization

13 November, 2020

Michael Vanhoutte, Chief Architect at Aprimo, discusses why it is important to establish that a problem you are trying to solve is the right one and how the engineering obsession with ‘fixing the problems’ can lead us astray.

Problem

In the world of perplexities and uncertainties, one is easily tempted to rush into solving the problem. Oftentimes, down the road, after much strenuous effort and countless hours, we would realize that the problem we are laboriously working on won’t solve customers’ needs let alone is aligned with the company strategy and goals. This challenge is proverbially captured as ‘when on the wrong train, every station will be the wrong one’. Having been there myself, I wholeheartedly recommend that whatever you do, ask yourself first if you are solving the right problem. Perhaps, you are only fixing a symptom or something of no use and could channel your energy on solving problems that matter.
 

Actions taken

To illustrate more clearly my position I would restore to three typical situations:
 

Solving a bug
Before digging any further ask yourself if the place where the bug appears is the place where the root cause of the problem is. Often, I see developers fixing the bug exactly where the customer has reported it. For example:

  • If the customer has reported that a certain value on an object causes the UI to crash, then it may be tempting to just update the UI to properly deal with that situation. But have you considered whether this value is even correct in the first place? And if the data is invalid, wouldn’t it be better to prevent this data from being there? By fixing the rendering in the UI, you may have inadvertently hidden the real bug. So, by “fixing” the UI you just made the identification of the real bug much more expensive.
  • Suppose a customer has reported that he is able to create objects containing some invalid properties using your REST API. Also here, one might be tempted to add validation logic to the API to ensure that the data coming in is indeed always valid. However, are you sure this validation logic shouldn’t be developed a few layers down in the business layer? Even if your REST API today is the only consumer of your business layer, who’s to say that there won’t be another consumer added 12 months from now? Maybe some bulk import capabilities need to be added and maybe these things will use your business layer directly. If you fix the bug in the REST API today, you are keeping the door open for the same bug once the bulk import feature is added. This means this bug would have to be fixed twice which translates into a much higher cost for the organization than simply spending a few more hours today to fix the bug in the right layer immediately.

People usually don’t do this out of laziness or malintent but often, in an attempt to resolve the bug as quickly as possible, people forget to stake a step back and really question if this is the right approach. Always question yourself: “Are you fixing the root cause or simply putting a patch on a symptom?”
 

Optimizing the SDLC
You have quality issues with your releases: too often you have too many bugs blocking a release, or even worse, ending up in production because it wasn’t detected by any of your quality gates. An easy and immediate conclusion may be that your developers aren’t writing enough tests and you may be inclined to push your team to write more automated tests. Again, before challenging the life cycle itself, check if you have overlooked some other issues much earlier on in your software development life cycle. Have you considered why your developers are not writing enough automated tests? Maybe that is the problem worth addressing. Perhaps the testing infrastructure is outdated or doesn't scale; perhaps it runs unreliable and people stopped running it because of this unreliability; perhaps it runs with too many false failures. Or maybe the way you used to write automated tests doesn't scale anymore with the size of your product. Or maybe some of the features aren’t tested properly because they are designed in such a way that makes testing difficult and that’s why developers don’t do it. There are too many ‘maybes’ that should be considered before you move forward with simply telling your developers that they should be writing more tests.
 

Developing a feature
Oftentimes customers push heavily for certain features and if they look valid at first glance, you may give in to the pressure. The feature sounds sensible and might benefit other customers, so why not do it?
 

But before continuing, have you asked yourself whether you are developing this feature for the right reasons? The feature may be nothing more than the customer’s answer to a problem that he is having. But if the customer would have simply explained the problem to you, would you have used the same feature to solve this problem? If you do develop this feature, are you intending it to be used for the use-case the customer is trying to solve? If you would know what is the problem that the customer is trying to solve, maybe you would have pushed for a different feature.
 

Lessons learned

  • Be patient and be confident to take as much time as you need to think about the problem and whether it is the right problem to put your energy into solving. Three examples above demonstrated how to avoid common detours engineers are facing when they are pressured to fix a problem instead of the problem.

  • The fast pace of the industry, pushy customers, demanding stakeholders -- all of them can drive you to a trap of solving the problem without establishing first is it the right problem to solve. Withstand the pressure -- analyze the root cause of the problem, question methodology and re-evaluate customers’ pain points before you roll up your sleeves.


Related stories

Should Tech Debt Be Managed
30 November

Anant Gupta, Senior Director of Engineering at Grand Rounds, argues that tech debt shouldn’t be managed unless it negatively impacts the business.

Dev Processes
Impact
Collaboration
Anant Gupta

Anant Gupta

Sr Director of Engineering at Grand Rounds

Are We Solving the “Right Problems”?
13 November

Michael Vanhoutte, Chief Architect at Aprimo, discusses why it is important to establish that a problem you are trying to solve is the right one and how the engineering obsession with ‘fixing the problems’ can lead us astray.

Impact
Productivity
Prioritization
Michael Vanhoutte

Michael Vanhoutte

Chief Architect at Aprimo

From a Dysfunctional Group to a High Performing Team
28 October

Narbeh Mirzaei, Associate Director of Engineering at HelloFresh, recalls how he transformed a dysfunctional group of siloed individuals into a high performing team.

Team processes
Productivity
High Performers
Narbeh Mirzaei

Narbeh Mirzaei

Associate Director of Engineering at HelloFresh

AI Products Are Data Products
19 October

Deepak Paramanand, Product Lead at Hitachi, shares how he built three different AI projects that all had one thing in common -- the ability to create or input data.

Product
Impact
Deepak Paramanand

Deepak Paramanand

Product Lead at Hitachi

Introducing Processes for Continuous Improvement
30 September

Peter Berg, Founder and CTO at Forward, recounts how he introduced processes for continuous improvement and thus creating a more psychologically safe working environment.

Impact
Productivity
Coaching / Training / Mentorship
Peter Berg

Peter Berg

Founder / CTO at Forward

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.