Coding with glue

I’d wager that almost no-one writes web-based software these days without using a framework somewhere. It doesn’t matter if you’re dealing with front or backend engineering, you’re likely making use of one somewhere.

Frameworks are great; They reduce to a bare minimum the amount of boilerplate code needed to achieve tasks that we all encounter in our daily work. Good ones even give us readable documentation – with examples – of how to implement some aspect of their function.

I see a problem though and it’s not as if it’s just over there on the horizon. No it’s here. Now. Shoot, the personification of it is probably sitting in the same room as you, it may even be you.

The problem I’m referring to is the inexorable reduction of our jobs into Glue Coders. We Google for a solution, install some package or other, call some aspect of its public API in our own logic, and call our feature done.

Now unless our own project contains decent test-coverage, very often we have absolutely no idea how that part of the package we’re using really works, and have no idea under what circumstances parts of its API will fail – that is until a client reports an outage or bug on production that is ultimately traced back to this package and our peculiar use of it. In using other’s APIs in this way, are we not just glueing things together? What are we, Airfix modelers?

My old man used to have a saying, (he probably still does) something along the lines of the following:

..if something is too easy, there's usually a reason for it..

Regardless of his formidable Fortran and Pascal skills, my Dad wasn’t referring to software development. Rather, I think this was a reference to one’s life-choices. In his experience, behaviour driven by simple solutions, often lead to worse problems later on in life. (There might have been some quasi-religious basis for part of this, I forget).

Being the developers that we are, often under the pressure that we are, we welcome quick solutions, and actively seek them out. What my Pa was saying was a hat-tip to its antithesis (Try stating that as BNF); That something being difficult shouldn’t immediately signal avoidance. When something is perceived to be difficult (and that path is subsequently chosen) one necessarily needs to take one step at a time to figure it out. Poke, see where it squeals and in doing so learn about it. In software, the parallel is in learning some aspect of a package’s internals which can only be beneficial when encountering last minute bugs on UAT and production.

By all means, install the latest package directly from GitHub, via aptitude, npm or wherever, but take some time to understand what it’s doing and how the part you want to use actually works. If (when) you’re in a hurry, usually just one or two core system calls or top-level functions in that package are all you need to Google for, to get the gist of what the thing is doing and how it’s doing it.

This way you’re better prepared when the brown stuff takes flight.