Consider these realities of enterprise application programming:
- The majority of coding time is not on business value - it's on all of the supporting stuff.
- A massive amount of effort and money goes into trying to establish some semblance of standards so that infrastructure can work efficiently and to ensure that we follow regulatory and security requirements.
- Despite this effort, most enterprises still have any incredibly heterogeneous array of technologies across their applications that end up making it difficult and costly to achieve any efficiency or satisfy our regulatory requirements.
These are some of the things that keeps us from valuable coding:
- Hygiene
- Keeping libraries up to date
- Updating projects with new regulatory and security requirements
- Replacing decommissioned technology from old projects
- Researching the "right" technology for our current projects.
- Writing boilerplate code
- Messaging & communication
- Persistence
- Implementing infrastructure blueprints
- Logging
- Security
- Monitoring
- Metrics & Telemitry
- Conforming to frameworks
- Updating to newer and better technologies
The result is that we are incredibly inefficient as a profession.
- Manually conforming to infrastructure is inefficent, slow, and risky. Paying millions per year is grudgingly accepted.
- Despite blueprints and best practices, we end up with extremely different results anyway.
- This chaos makes it impossible for infra to make holistic optimizations without imposing a high cost on every app dev team.
- For example, there's no way to move all apps from JSON to gRPC without asking all teams to do so, which they don't.
- Teams don't know whether or how to target cloud when it's not available.
- It's even worse with security and privacy compliance. Adherence to regulatory requirements is spotty at best and time consuming.
Anything that addresses a few of these problems should be taken seriously. Something that addresses all of them presents an obligation to try. Why are people hesitent:
- Skepticism that it can work based on years of promises
- Loss of control
- Fear of change and abandonment of years of learning
Why that doesn't apply:
- These are tools to codify all of those years of experience into automation.
- We've demonstrated the viability. Now all it takes is community to make it succeed. It will start as some useful tools and grow into an approach to development based on the needs and contributions of the development community.
- Developers never lose control. This is not a one-size-fits-all miracle framework that abstracts and removes control and forces you to conform your business. It's the opposite. It's a way to define your business first, figure out how you want it to run, and then automate the rest.
In the end you get better throughput, more agility, better code, fewer bugs, more time to innovate, less time documenting, more insight into what your application is really doing, and total user confidence.