“Intentionally” Leaky Abstractions

Software abstractions that developers create should leak enough to let non-developers design the right product experience.

Eons back in internet history, Joel Spolsky wrote a post on leaky abstractions. The gist of the writing is that even though we create software abstractions to make life easy, they somehow unintentionally leak through.

With technology getting a lot more complicated, I believe that the software abstractions that developers create should intentionally leak to some extent to let non-developers design the right product experience.

Taking a concrete example, let us say that you are creating a search utility which goes over a lot of data. Your algorithm has two steps, one that works on recent data and the other, older data. Recent search is blazing fast while searching through old data is slow. You do both in parallel, combine the results and display it to the user. You have two options here; you can abstract this two-pronged approach from the product teams and act as if the search is a single step process or you can leak this abstraction so that they can take this into account while designing the product.

What can the product team do with this information?
They have multiple options.

Show the faster results first without waiting for the slower ones. Where the older results are displayed, show a loading placeholder, and then populate the results as and when they become available.

Another option is to make this a two-step process by showing only the recent results and then asking the users explicitly whether they want to search through old data too.

They can do this only if your abstraction leaks through informing them of the internal search nuances.

You need to be judicious with what you expose, and what not, so that the product teams are not burdened with unnecessary details – striking the right balance is essential.

Image by Jesse Bridgewater from Pixabay