This is me being cynical. I’ve turned into a person that is more prone to disliking building new flashy things, and rather suggests to leverage existing things. Good engineering organisations don’t measure success by looking at the amount of things built, but by the value created. Two incredibly different things.
One thing I find remarkable is that I still encounter reinventions of known and working things all the time. And I don’t think that the people who built it made a mistake – I rather think we, as an industry, are doing a remarkably poor job at establishing language, patterns and best practices that can be considered universally valid and applicable for a given domain.
Take feature flags. If you’re working on a mobile or web app, chances are you’ll run into a situation where having the ability to turn features on and off for your users comes in handy – especially since releases for mobile platforms tend to take a little while to make it to your end users devices. It’s a very known problem, with a very known solution. And I’ve seen a bunch of solutions being built to solve it – even though there’s open source tools that solve your immediate pain, without you having to do much. It comes down to understanding the problem, knowing its name and then using what’s already there.
Another example could be message queues and streaming platforms in the context of system design. Most folks I know move into system design from basic backend engineering, meaning there’s a familiar toolbox that includes things like HTTP, Databases and the occasional in-memory store. That leads – more often than never – to a situation that those tools are very much applied to entirely different kinds of problems that would be better suited to a decoupled mode of communication. We have streaming processors, like Kafka, queues like SQS or simple PubSub models like the facilities provided by Redis that can really help in building more scalable, simple and robust systems. But again, I’ve seen quite some reimplementations of existing solutions, quite simply because we’re not doing a great job of ensuring that there’s a boring toolbox that’s available to people doing the craft.
I could continue this list – and probably I’m just an old man yelling at the clouds. But there’s a point here.
A few decades ago, software design patterns were the hot shit – I memorised quite many of the GoF patterns, and I still refer to them from time to time. The relevant thing that happened with that movement, at least initially, was that those folks gave problems names – and provided a blue print on how to solve them. There has never been a version two. And I think this is not due to the fact that no one ever wrote it – it has much more to do with the impatience and arrogance of our industry as a whole.
In our constant urge to build, explore and reinvent the world, we’re ignorant of the previous learnings. Maybe that has something to do with the average tenure of engineers in the industry, but it feels we’re working in 20 year cycles, and we’re just episodically forgetting – and then proudly rediscovering – knowledge that already was there. And that’s both on a smaller scale, when teams simply don’t know that feature flags are a thing – to bigger things, when ew move from client side processing to server-side rendering and treat it like its the second coming of christ. Seriously, this is how we did web pages until like, idk, 2016.
It’s just a goldfish industry, isn’t it.