Over 50

Some time ago, the product/project manager of a company I was consulting for started the day in the same way some (probably too many) of her counterparts usually do: she announced to the development team that there was another bug on production: this time, a customer was complaining because she was not able to add items to her product list.
Used to this kind of bad news, the programmers promptly started investigating the problem.
After a while, one of them announced that he had found the reason behind the issue: the user had already reached the maximum allowed amount of items (namely, 50) within the product list.

Saying that the manager was surprised by the outcome of that quick investigation would be an understatement.
“Who the hell set that limit, and why?!” —she solicitously asked.

After inspecting the code a little more, the programmer, slightly embarrassed, uttered one of the sentences software professionals dealing with legacy code are most familiar with: “Well, it has always been there…”, being always probably the last ten or fifteen years at least.

Apparently, another programmer, who wasn’t even working anymore at the company at that point, had set that limit a long time before.
And he certainly did so with the best intentions.
After all, setting a reasonable limit used to be a common thing to do.
The idea of asking someone else for the most reasonable value to set was probably not that common at that time, though.
The assumption that nobody would ever need to buy more than 50 products seemed absolutely legitimate to him.

Over time, the fact nobody had ever complained about the programmer’s decision might have even given him the impression that it was a good one.
Anyway, after a while, he completely forgot about it.
By the time he left the company, it was as though nobody had ever made that arbitrary technical decision.

Until the day that customer tried to add another item to her copious product list…

Now, the happy ending of this story was that the manager immediately realized that that arbitrary limit had converted itself into a bug. A bug affecting a customer. A bug which needed to be fixed as soon as possible. Which means the limit was removed (and a new version of the web application released) that very day.

A very similar story, but with a not so happy ending, recently happened to me in my spare time.
This time I was the user.
The app was LinkedIn.
The issue: having already 50 items in my Courses section, I wasn’t able to add/save any new one. Which was really frustrating, especially taking into account that I had recently taken some interesting new courses, and I wanted to add them to my LinkedIn profile¹.

Why didn’t this story have a happy ending?
Basically because LinkedIn failed to acknowledge that such a limit (which was likely the result of an arbitrary technical decision on their legacy code) had now converted into a bug affecting (at least) one of their users: an annoying issue which does not allow me to add/save any new items within the Courses section.

In their view:
⦁ the system is working as expected —despite the so general and unhelpful error triggered did nothing but confirm that such behaviour was absolutely unexpected;
⦁ they need to do some research before deciding if that limit has to be increased or not —the very similar story (about the company I was consulting for) I explained to them (for free) didn’t seem to be a valid alternative to expensive (in terms of both money and time) user research, and
⦁ in case they decide to increase the limit, they would consider that an improvement, a new feature, not a bug.
They didn’t (want to) see the bug.
Yet, the bug is still there².
And the upset user (who happens to be a software testing specialist) too.

#LinkedInNeedsToUndergoGenuineSoftwareTesting

The bottom line is that arbitrary technical decisions (especially those ones made in the past on legacy code) will convert into bugs sooner or later.
When this happens —remember: it’s just a matter of time—, you can choose either to follow the example of the company I was consulting for and quickly fix the corresponding bug, or to put your blinkers on and behave like LinkedIn.

The good news is that you can also choose to be proactive here.
You may decide to have a look at your legacy code, for instance, to try to discover (by searching for “max”, for example) all those (often arbitrary) limits someone set in the past, and eventually decide if they still make sense or they need to be reviewed/updated before they materialize as bugs exposed by (usually upset) customers or users.

Anyway, I‘m pretty sure your testers, at least the good ones, perfectly know what is the best thing to do here.
Wait, don’t tell me there isn’t any at your company.
“Who the hell set that limit to 0, and why?!” —I’m hearing you asking…

¹ As you can guess, when I need to send my résumé to a company I would like to work for, I don’t list all those courses within it: I just select a few, actually the most relevant ones.
Nevertheless, I liked to use LinkedIn as a tool to keep track of all of them, at least until this was no longer possible.

² The only workaround available consists in removing some old courses. This is the only way I would be able to add/save new items. The thing is this “solution” doesn’t work for me because, as I previously explained, I want to use LinkedIn to keep track of all the courses I have already taken.