While scrolling through my Twitter feed the other day, I came across this tweet which got me thinking:
It’s true that for the majority of my career, I’ve heard that my primary focus should be the business logic. After all, that’s where the value is delivered for my employer or client. It makes sense, and I’m not going to argue that business logic isn’t important. What this tweet made me realize is that despite the seeming focus on the business logic, the means of building software has been radically and rapidly changing for years. The very earth is shifting beneath our feet! There are a couple implications of this.
The first is that developers don’t focus on the business logic nearly as much as they advocate. There is an inescapable technological component to the act of writing software. For a lot of us, we enjoy the technology part of our jobs. Sometimes we base our decision on which job to take according to what technologies they use, not what industry the customer is in.
The second is that developers are not practicing what they preach. I think that if developers really focused on business logic, the pace of innovation (or at least adoption) with regard to technologies would slow down. After all, adopting any technology at today’s rate of change is a huge risk! Why not stay in an environment utilizing older technology wherein it’s possible to write perfectly fine business logic? I’ve been a part of efforts to decompose monolithic applications into microservices that haven’t gone well. The initiative to adopt microservices was couched in terms of “business value” but that’s not really what was going on in all cases.
Also, I think there’s a whole community of professional consultants and conference personalities who thrive on promulgating the “business logic” emphasis. Many are better at talking about the software than delivering the software, so they look to free themselves from the obligation of being technically competent. They often do so by rushing to advocate innovations in infrastructure. Reminiscent of Plato’s Idealism, a picture is painted where infrastructure is abstracted away into a realm disconnected from and taken for granted by those who consider the loftier nuances of business logic. From microservices to Kubernetes to today’s flavor of serverless, all are sold as silver bullets enabling faster delivery, less overhead and more business value. But it’s simply not true. Besides being extremely nascent in some cases, each of the strategies I named above has its own complexity to manage. In addition to benefits, each strategy has weak points that must be mitigated. Some have steep learning curves. In my experience, these strategies require teams dedicated to infrastructure (sometimes called PaaS, SREs or, mistakenly, DevOps) to have a chance of being successful. And once again we have a divide between those focused on technology versus business.
There are three broad dimensions to any software project — infrastructure, software development practices and business knowledge. They are all important. In my opinion, a seasoned software developer will have an integrated skills profile consisting of all three. Companies today have to have some kind of legitimate software strategy, although software may not be their primary focus or product. Developers who work for, say, an insurance company have to understand that cutting edge serverless technologies may never be adopted in their environment. This is because the perceived risk would undermine business value. On the other hand, developers who hire into a company on the sole basis of their cool new tech should not make any noise about driving business value because that isn’t what they’re doing.
