The future of Software Development: Just Business Logic
Today, to accomplish this, developers are forced to write complicated infrastructure that typically involves message queues and databases along with complex logic to synchronize them. All this ‘plumbing’ is extraneous to business logic and makes the application code unnecessarily complicated and hard to maintain.
This was written by Werner Vogels a few years ago. But he has reiterated this message a few times: “In the future, all the code you ever write will be business logic.”
It’s increasingly obvious that coding as a profession is diverging into a number of specialised roles with little in common. You have the infrastructure programmers who work for a big tech company and are responsible for keeping the ‘cloud’ infrastructure running. And, more and more, you have business logic coders who are responsible for very little of the actual application code.
Web server? All of that’s done by the API Gateway and CDN front end.
Authentication? Cloud-provided, just plug it into your Lambda/Cloud function.
Image processing? Just use a service.
Machine learning? Plug the APIs into your cloud function.
Service coordination? Just use Step Functions and other cloud-provided coordination services.
We aren’t there yet but it’s getting closer. Already, you can easily think of individual businesses where the vast majority of the code you write is just what you’d call business logic.
The key feature that enable more structured and strategic use of all of these cloud services isn’t technical but financial: most of these services have pricing models that are based on invocations or actual use. This makes many varieties of organisational and strategic issues financially transparent and therefore organisationally visible.
What’s less clear to me is how this will play out in front end web development. My main concern is that Single-Page-Apps (SPA), which currently dominate the web development community, suck from a business perspective. They have a much greater number of things that can go wrong, which absolutely results in a much higher frequency of bugs, many of them are harder to solve than their RESTful HTML equivalent. They open up the possibility of a host of new classes of XSS bugs that won’t appear in your logs. Calling their state management requirements non-trivial is an understatement. And, finally, even though they are often used to integrate micro-services, they are by their very nature extremely monolithic which has substantial implications on development and deployment.
Single-Page-Apps have high ongoing costs and are harder to fix when they break. But, more importantly, they make it harder to separate out concerns into individual layers that can then be outsourced into services. Instead they are the pinnacle of Conway’s Law: an entire development methodology that is exclusively focused on building software architectures that replicate the organisational structure of the company making them.
Concerns are only separated on the component level where each team or department provides an opaque blob of code with no hope of discerning which code affects which individual concrete cross-departmental business problem.
This blocks off most (business) strategic approaches to front end development. The biggest impact is in reduced visibility into costs. Most companies vastly underestimate the costs of their Single-Page-App front ends. They don’t see the increased bug costs, the increased cost of accessibility compliance, the user churn resulting from accessibility non-compliance, the reduced awareness of XSS and similar security bugs, or the increased developer load due to state management.
(In many ways this makes Single-Page-Apps the antithesis of cloud functions. One both increases and obfuscates costs. The other decreases cost and increases visibility.)
For purely financial reasons, I’m not convinced that this particular web development architecture can survive in the long term.
It’s not the frameworks that are a problem but the architectural model of the applications we use them to make. Maybe frameworks will come up with some revolutionary solution that solves or makes up for the downsides.
Maybe I’m just not seeing the awesome.
(RESTful server-rendered HTML that uses JS for behaviour and CSS for design is a comparatively inexpensive web front end architecture, by the way. Especially when you look at long term costs.)