A Problem vs The Problem

A Problem vs The Problem
Photo by Hans-Peter Gauster / Unsplash

Situation: I can access this after being even when my access is revoked.
Problem: You missed a check in a function.

General opinion:

Add the missing condition in that function and push it to production.
Time took to fix: A few mins - Quick approach
Impact level of the fix: Low - Only that function is fixed.
(It’s a high velocity decision)

Alternate opinion:

At GreyB, it's first checked if the problem is the one to fix or not. Since this is a core miss, a user who has no more access should not be able to use that particular feature/space, and also this should not affect the existing system.

You spent time exploring ways that this can be added by default when someone interacts with that specific model. (every framework has such functionalities - it’s just an exploration away to use it).

Time took to fix: A few mins + few mins of exploration - Quality approach
Impact level of the fix: High - A core has been fixed. There is a product level-up here.
(It’s a high quality decision)

There will be a tradeoff between high velocity and high quality decisions when fixing bugs or developing features. It’s a choice to make.

How is it helpful?

  • Anyone who uses these generic models now after that doesn’t have to take care of this. It’s no more developer dependent.
  • The overhead between the developer, tester, and team lead of missing such things will be less - the right thing is delivered faster.
  • You started fixing 1 function, but you have fixed that function, the existing functions using that, and functions that will come in the future. Time is saved for every method that will be added in this model - for adding that filter, for its relative bugs to exist, and for the cycles after that.
You can try this out: Dig the problem until it can’t be divided more - decide what to fix - the function or the core. Otherwise, the same bug will keep biting you and your product twice.

That’s the red flag of bugs.

And if during testing this is what your testing team has to find in every endpoint. You gave them a coded mess to fix. When it's only the first identification, it's a bug. Reappearing is the obvious bug caused by the developer's ignorance. The bug report after that will be: ‘Everything is broken. Steps to reproduce: do anything. Expected result: it should work'.

Subscribe to Haox

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
[email protected]
Subscribe