Loading...

Are We Solving the “Right Problems”?

Michael Vanhoutte

SVP Engineering at Ontoforce

Loading...

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.


Be notified about next articles from Michael Vanhoutte

Michael Vanhoutte

SVP Engineering at Ontoforce


Software Development

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


Product

HomeCircles1-on-1 MentorshipBountiesBecome a mentor

© 2024 Plato. All rights reserved

LoginSign up