Tool Dependency
The disability that is crippling tech
My wife has a master’s in Critical Disabilities. She is the person who introduced me to the concept of social disabilities. I used to think that people with disabilities are those constrained to a wheelchair, or have some other physical issue that is limiting their movement. I didn’t consider the finer realities of life — for example that a person who cannot speak the local language is as incapable of navigating the social structures as someone who can’t talk. I understand now that disability is a created construct. The things we have created, the way we do things, the way we frame contexts — creates disability.
The other day I spend 3 hours debugging a Maven Goal. When I manually run a script it processed my WSDL files just fine (I will have to devote a separate post on why I am still using WSDL files) but not when I executed it as part of a Maven Goal. Maven allows you to debug a Goal — which indicates I was not the first person to hit that type of a snag.
But it was a version conflict in the Maven build process.
There was a time when you wrote a program and you hit compile and it ran and you saw something. I recall writing midi sounds with Pascal and annoying the entire classroom. My dream was to recreate the score of Monkey Island but then came lunch and I got distracted.
Well, we are doing more complicated things
That’s a cop out. To build that simple program and run it on Pascal, I needed decades of computer and software engineering. In the mid 90s (at least that’s when I encountered programming) the layer of abstraction matched the problems we were solving.
It was not like I wrote microcontroller logic in Assembly. I remember trying to control flip-flops to display my name in LED lights. When I was writing Pascal I was dealing with a high level language that required an operating system to provide a runtime, which in turn abstracted away the complexities of microcontroller architecture.
Now, the essential problem of our time is a mismatch between our current level of abstraction and the complexity of our problems.
Imagine if Tim Berners-Lee build a package manager
Or maybe what is easier to imagine: what if the world wide web was designed like npm. NPM is probably the worst package manager — your projects are constantly at a risk of becoming useless on Windows machines as your path name is bound to eventually exceed the 256 character length.
But while we are moving fast and break things, we need to occasionally step back and reflect on how broken we have become. The web development world is full of half assed tools that have gained so much popularity so fast that the people who designed them (fully aware of the flaws, but had to deliver something in a reasonable time) are stuck leaving the tools as they are.
Everyday someone wants to fix a new problem by re-inventing the wheel — this is evidenced by the waterfall of Javascript frameworks. Either people are so greedy that they want to make a name for themselves or are genuinely clueless about the alternatives — when your framework matures, chances are it will have the same problems that you tried to avoid, since we are all building websites using Javascript that run on a browser. Nobody is doing anything fundamentally different…
So we are all disabled
I wouldn’t go that far, but we are at a risk of becoming so. Developers who pigeon hole themselves into narrow frameworks, who understand React but can’t live with Angular; who can work with NodeJs but cry in agony on encountering a line of Java etc. etc. are already disabled.
You constantly carry the risk of disabling yourself by becoming too dependent on a single workflow. You are at a risk of creating for yourself a technological disability that will prevent you from seeing a different, genuinely optimal solution.
You will be left unable to innovate in an industry that craves and rewards innovation more than anything.
