When Not to Abstract

Software developers love abstractions. It is satisfying to hide the perceived ugliness and complexity of the underlying system in a so-called easy to use, beautiful interface. Also, abstractions are considered a good design practice.

The abstractions that I am referring to are those along the lines of structural design patterns like adapter and facade. ORM is a classic example.

The flip side of abstractions is the complexity that it brings. Abstractions would have bitten every software developer at one point or the other. Cursing ORMs is a rite of passage for web developers.

Poorly written abstractions cause more problems than they solve. Not to mention the countless hours wasted in designing, writing, and maintaining them.

Knowing when not to abstract is as vital as knowing when to abstract. 


When not to abstract?

  1. The abstraction does not add value.
  2. The underlying thing that you are abstracting is not a standard and is rapidly evolving.
  3. You are prototyping.
  4. You are short on time.

Before writing an abstraction, always introspect—what is it I am solving with this abstraction? What is the value add of this abstraction? 

Abstractions work well when they are written over components adhering to well defined, comprehensive standards and specifications. For example, SQL is a well-defined standard. SQL might evolve, but slowly. Hence ORMs are ubiquitous and work well for a majority of the use cases. 

When you try to abstract a non-standard rapidly growing platform, it becomes a game of catch up and drastic design changes each time the underlying platform changes. Without knowing the direction of evolution of the underlying platform, it becomes a disruptive change each time to the users of your abstraction.

When you are prototyping, concentrate on proving the idea as quickly as possible. Do not waste time writing layers of abstraction, which you might throw away in the future if the concept does not work.

Abstractions that add value require deep focus and ample time to design. If you are short on time, you will do a lousy job with the abstraction. It will cause problems than solving something.

In all the above cases, instead of structural abstractions, concentrate on utility functions. Writing utility functions for simplifying recurring patterns will give you more bang for the buck.

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

Photo by Lucas Benjamin on Unsplash

Fighting FUD

FUD stands for fear, uncertainty, and doubt. FUD is the strategy of influencing perception by spreading false and dubious information. Fighting FUD takes energy leaving no steam for real work.

Marc Andreessen, a Silicon Valley venture capitalist, recently wrote a post saying: It’s Time to Build. The gist of the writing is—in the US, people are no longer innovating and building core infrastructure—health, banking, transportation, finance, education, etc. anymore. The article is a call to arms to get back to building ambitious foundational projects.

While Marc Andreessen’s writing is in the context of the US, it is true, albeit to a smaller extent, in India too.


What has led us to this?

We were in a homestay in a green estate that had a stream running through the plantation. The owner of the property told us how the government allows him to build and operate a compact hydroelectric plant on the stream, but he does not want to. He said that as soon as he would construct the plant, environmentalists would raise a hue and cry, create a ruckus, and he would end up wasting all his energy on that front, leaving him little energy to do other things.

The above is anecdotal, but you see a parallel whenever our government announces big-ticket, ambitious projects. There is always a cacophony of protests. We live in an age where everyone has a strong opinion on everything, and if that person is creative with words, she can multiply her reach, thanks to technology. Nowadays, spreading FUD is just a click away. Plus-oneing the protest satisfies the modern age’s thirst for wokeness and fuels the FUD. In such a situation, a government that lives by the Damocles sword of public opinion gets into perception management mode leaving little energy to solving problems.

Organizations are not immune to FUD. US intelligence, as back as in 1944, published a manual with tactics to sabotage workplace productivity. The manual was a field guide to be used against Axis powers in the world war.

Some gems from this manual:

  • Never permit shortcuts to expedite decisions.
  • Talk frequently at great lengths.
  • Refer all matters to committees.
  • Bring up irrelevant issues.
  • Haggle over precise wordings.
  • Advocate caution.

The above is how one creates an environment of FUD. One can see such behaviors to varying degrees at workplaces. In a culture where this is extreme, fighting FUD and preception management replaces work. Once this culture takes hold, it is impossible to weed it out—productivity nosedives to zero.

Get articles on coding, software and product development, managing software teams, scaling organisations and enhancing productivity by subscribing to my blog

Photo by Snapwire from Pexels.