Let's define the invisible feature:
Invisible feature is any piece of code purposely written for making an application work as we think was intended. Can be also called edge-case features.
What makes them different to a bugfix is they are not corrections of failed code (i.e. it is not fixing an unwittingly flipped condition in an if), they are bridges, interactions built to be not noticed.
The problem here is since they are built to be invisible they are not naturally tracked product management or business completely forgets about them when a product rewrite is requested which can result in embarrassing delays.
Therefore we need to be able to identify the invisible features and document them, so decision makers can factor those in.
Now it might sound very vague, so let me give you some examples.
Invisible feature: the server switch fix
In the 2010s I was working on a help desk software project. In that application there was a chat option between the client and the help desk agent.
From one particular company we have got reports of chats breaking up and being stuck in a reconnecting state. There was a lot of confusion and a lot of emails and calls with this company until somebody figured it out:
The help desk agents in that company were using laptops and they were moving around in the building with them: an agent would sit in Room 1 connected to WiFi Router 1 and then move to Room 2 where they would connect to WiFi Router 2. Nothing out of ordinary.
The moment this switch happened the chat got disconnected. The reason was there was a load balancer operating and when a new connection arrived it routed it to (most likely) another server.
It is clear that this is not a per definitionem bug since everything worked as they would, it was the situation so rare and specific that required code to be brainstormed, designed, tested and implemented, much like a real feature.
Invisible feature: gathering location
You would think that acquiring location through GPS is a very straightforward feature in modern phones. You call the system API exposed to you and it's done! And that's where you are very wrong. Modern location gathering depends less on satellites than on network towers and known physical addresses of WiFi routers. The problem occurs when there is no network and no WiFi; the person might be inside a house, the satellites won't be "visible".
The solution steadily working in your dev environment (be at home or in the office) can totally fail in areas without network coverage.
Again, even though you have done nothing wrong, your application is logically correct, you need to brainstorm, design, etc. an entire feature worth of code just to be at business-at-usual again. You might even need to instruct the user through the UI to get outside the building if they need GPS to get their job done!
Handling all sorts of weird issues like this one is in fact an invisible feature and is very underappreciated. Sadly when we fail to communicate these efforts the competitors application might look juicer even though their solution would also fail under the same circumstances.
Invisible feature: handling huge volumes or none at all
Another thing that I really often see forgotten is designing for extremes in volume; by design I mean both software architecture and UX/UI.
The usual interface mock showing a couple of items might look odd and unfinished when there is no or just one item, and it might look and feel cramped when you have thousands of items.
Similar case is scaling: handling one country in one region is a different beast than handling multiple countries in multiple regions.
What to do with it?
First of all we should always set aside time for covering edge-cases. Except for my last one none of these examples could have been avoided, therefore
you should not be ashamed of an edge-case even if it scrambles the precious deadline.
I would be also very happy to see if fancy charts like this would incorporate edge-cases and gotchas being covered:
Developers: we need to raise awareness about these weird non-bugs, non-features that take lots of effort. We should also take these seriously, cover them with test and document them, so the next colleague refactoring our code 3 years from now will have a fighting chance.
Product managers: you need to factor in that you might need to put serious product efforts in fixing "bug like" cases.
Sales and business people: reliability and resilience of a software product is also a marketable, great feature. Especially when you know your competitor is failing at it.
Top comments (0)