And not a feature
How can something not be a defect in the system, and still be an unquestionable bug from the business side?
It happens often, missing a key functionality not allowing a business process to be completed but a low priority from a developer’s perspective.
But how often a bugfix becomes a bug itself, while not introducing any issues with the fix?
Imagine one situation that is freely based on some past project…
Fixing the coupons
The client was using the discount coupon number feature on UAT environment. Everything was working fine up to some point, discount codes were accepted, no issues raised. At one point the bug came in that the validation is not correct on one of the codes.
Good developers fixed the bug completely. They saw that there was no validation at all (technically speaking, there were no error messages, just an error written in logs, the application running the success path). After the fix, the validation worked and passed internal QA.
Surprisingly, the feedback from the client was that the fix broken coupons completely, and now none of them are working!
Good developers looked into the high priority issue and were surprised again because the validation worked perfectly.
They dug deeper and found out that the client was just using invalid codes in the second issue.
The discussion between developers and managers at this point was:
-M: Why your fix has broken more things? Prepare a new fix so it would work.
-D: We have fixed the original bug correctly, the client is using wrong codes.
-M: Client says codes are correct and they were working previously. Prepare a new fix.
-D: It is either validation not working or codes not working at all. Were codes client using specified?
-M: It was working from the beginning, there was no specification needed, now it is broken. Prepare a new fix. Do you need more Senior Developers to help?
After that much refusal from the developers the client responded that codes were working fine previously, they are correct and were generated by them.
So yeah, the client used some (random) numbers and letters, because the system allowed for it, and assumed it works that way.
And it was difficult to explain that code change that broke the system was the fault of the business side (requirements and codes data format, to be precise).
Finally, after every party understood what happened, developers had to change the system to accept the format of codes used by the business.
Lessons learned
Communication, requirements, but also accountability.
A developer can’t fix everything with more code. And sometimes even if you can, you should not do that straight away, as that could be seen as taking responsibility for lack of communication or incomplete design/requirements. And if not noticed, those gaps would forward to other projects in the company.
In the end, the project could be late by that bug and that would be all the management would look at.
And a total number of “code” bugs would be high if the bugs would not be marked as “design” bug correctly.
For a project retrospection and summary, that information could highlight the areas in need of improvement (e.g. design and requirements, not development).
Finally, making a fix immediately, without specifying requirements finally, could lead to other validation issues in the future, that is why it was important for business and management to understand the issue.
Note from the past
After thinking more about that type of problem, I have recalled a couple of similar issues from past projects.
One example could be an order form accepting incorrect data due to the lack of validation (fixing validation has shown that there was a problem with data).
Another was missing error handling for one module, so after it has been fixed there were a lot of automatic error messages as the module had other problems itself.
Leave a comment