-1

I was just reviewing some code and realised it is going to introduce the possibility for a situation where the numbers our staff use on a daily basis could be slightly out of line with the numbers we get in our monthly reports.

Fixing this would be difficult and ultimately is of no benefit. I see this as a small quirk of the system or we could call it technical debt. The problem that I am facing however is that, even if I write this down, it will get lost on a bug board somewhere.

Perhaps a year or two from now, if there is a process change, this situation could arise and no-one will know why it is happening. How do you deal with a situation like this? Do you just leave it and add a comment hoping someone catches it in testing if things change? These little issues in time are likely to build up to but for this one; unless that process change happens, there is 0 benefit to writing this difficult fix.

MercilessMaverick
  • 101
  • 1
    Possible duplicate of [How does one find out if there is a technical debt on the project? How to measure its volume?](https://softwareengineering.stackexchange.com/questions/368532/how-does-one-find-out-if-there-is-a-technical-debt-on-the-project-how-to-measur) – gnat Aug 07 '18 at 14:22
  • 3
    This is impossible to judge until we know the nature and extent of these deviations. Are we talking rounding errors? Inconsistencies? Loss due to concurrent sampling and processing? And most importantly: does the specification allow for this or not? – Kilian Foth Aug 07 '18 at 14:35
  • 1
    Why are you calculating the same quantity in two different places? – Stop harming Monica Aug 07 '18 at 18:37
  • Sounds more like a defect than technical debt. The numbers are different -- why is it not an outright flaw? – Frank Hileman Aug 08 '18 at 16:52

2 Answers2

7

  1. If there is a specific section of code that mostly causes the bug, or in the code that collects the flawed number, comment the heck out of that. State exactly why it will not always work correctly and what should be done to fix it. That way anyone who happens to be researching perhaps years later will not have to duplicate your findings.

  2. The bug board is an appropriate place for this. Even if it is too large to ever hope to go through the entire thing, people searching for why the report is slightly off will hopefully come across it. If later the customer or the product owner complains about the discrepancy, you can say you are aware of it but it is not an easy fix. Then the product owner can give it a higher priority if it really is important.

Nathanael
  • 827
  • 4
  • 11
2

The important thing is to define what your software is supposed to do and write it down!!.

If it's supposed to report "orders per week" and the monthly report is supposed to report "completed orders per week" for example, then the documentation for each bit of software should reflect that.

If it's supposed to be the same, but you accept the bug, then thats the new requirement and its supposed to be different again.

You would hope as new features come in over the years, people will check the document to see what the software is supposed to do and any confusion will be cleared up.

But as we all know, no-one writes or reads documentation, these things stagnate until no-one knows what they are really supposed to do anymore, then they are used incorrectly and people report bugs where there are none and eventually write a new system from scratch.

Ewan
  • 70,664
  • 5
  • 76
  • 161