Bane of rewrites: the Invisible Feature
Tags: productmanagement, product, refactoring
Published: 2021-07-25 12:52:02

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:
![A typical comparison chart](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oz1rs80bw93idzroxh1w.JPG)

**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_.