Reduce Abstractions, Reduce Complexity

The job of a software developer (will use “developer” for rest of the article) is not just to write software and be a “front-end”, “back-end” or “mobile” developer or in some cases “rails” or “Django” developer (yes, they exist)

As Kaushik Thirthappa puts it in this interesting read “Manufacturing Cars and Developing Software” (http://w3z.in/109)

“You need people who know to build the car”.

The job of a developer is to move the business forward by managing complexities. Writing software is a means of doing that i.e. helping a business grow.

In large software, complexities of interactions of different components grow and their dependencies tangle to form a complicated mesh. This forest of interrelated components/dependencies on different software makes an abstraction.

Abstractions help you for a huge deal, they allow you to not think about the edge cases of an underlying system and allow you to be productive but as Joel Spolsky mentions in this excellent read “The Law of Leaky Abstractions” (http://w3z.in/aa7)

“All non-trivial abstractions, to some degree, are leaky”.

Which means your abstraction will leak at a case and then you will have to dig deep into the abstraction and extract the information to help you out and you would be very lucky if this leak in the abstraction is not causing you monetary loss having a client kick your ass or you losing customers in the process.

So, our job as a developer is to help businesses/people by managing complexities and playing only with abstractions that we can consume and not vice-versa.

The recent trend of programming is moving more and more towards abstractions with frameworks popping up every day in numbers or containerizing of everything (I am looking at you docker, vagrant).

A satire on JS MC\* framework flurry (daily flurry)
A satire on JS MC\* framework flurry (daily flurry)

I think it becomes a catch-up play for someone who comes and starts to learn to code. There is a huge gap to fill, first of all, we have to understand that the world will do fine, if not better without some of these useless abstractions.

For example, I was not entirely comfortable with Mac OS X shell, so, I tried to use Vagrant as my VM manager but there was so much abstraction (things not working while learning something entirely new) wherein I would not know if I am at fault or my abstraction is at fault. I decided to get rid of it and use VirtualBox + SSH to achieve the desired result.

Concluding this “rant”, here is a list of tips to reduce the abstractions and hence complexity to start writing better software

  1. Get rid of containers —
    Set up inch perfect Linux Dev environment on Mac
  2. Use IDE but learn to live without them. Use bare-bones text editors initially to learn manual linking of components in your favorite language before bowing down to productivity provided by IDEs
  3. You don’t need that “X” framework.

This post is not polished. I have written this as a mild “rant”, will keep updating as per further ideas, discussions, comments, and happening of software.