Shoemakers’ Children Go Barefoot, or, Why Developers Don’t Help Themselves
As developers we understand the value of what we do. We take business problems and create robust, automated solutions for them. We take pride in our craft, valuing engineered solutions using sophisticated modern programming languages, frameworks and platforms. We don’t trust anything we can’t test at multiple levels. Many of the technologies we use were developed with testability in mind.
Yet we let ourselves down in how we work and approach software delivery. Just as shoemakers’ children go barefoot, we fail to use our skills to improve the daily work of our own teams. We fail to automate many of the tedious daily tasks we face. We code important behaviors in untestable YAML and Bash. We resort to copy and paste when we could automate reuse. Individual developers use secret local scripts, without sharing their knowledge with colleagues. We tolerate duplication between delivery pipelines and suffer increasing and dangerous entropy over time.
As we’ve moved toward microservices from monoliths, we’ve actually gone backwards in some ways, as the sophisticated capabilities of IDEs solve fewer of our problems. Like boiling frogs, we’ve let things gradually get worse. Many of our present tools, such as CI solutions, were conceived when we had a small number of highly complex builds, not a far larger number of relatively simple builds. They are necessary but not sufficient for a very different world.
Once upon a time, there was an excuse for this lack of automation. Developers need APIs, and there wasn’t an API for a forklift. First virtualization, then containerization, PaaS and Kubernetes changed this, giving us an API for hardware. Hand in hand with this, more and more things have come to be driven by version control, which is also automation-friendly. Tools that were once driven by operator UI are now controllable by API or configuration.
Today we have an API for hardware. We need an API for software, so we can develop our development experience.
What should the API for software look like?
- It should address both code and delivery: the contents of repositories and how they get to production
- It should offer a consistent model, making it possible to evolve and add automations incrementally, rather than as unrelated point solutions
- It should be based around full-featured programming languages, rather than YAML and Bash
- It should allow the use of mainstream module systems and runtimes, rather than the more primitive composition available in such scripts
- It should be cloud native, running wherever we choose to run our business applications
- It should allow testability at multiple levels, from unit testing up
With present solutions, it’s hard to react to change. Above all, the API for software should make it easy to evolve projects and delivery flows, using proven software engineering principles.
We’re trying to build this at Atomist. But the need is bigger than any one company or technology. It’s time to reflect on how we work and how it could be improved by turning our own skills toward smoothing our daily work.
By helping ourselves first, we are better placed to help others, and deliver business value. By applying what we do to our own work, we can smooth the way to focus more on coding business logic and less in struggling with distracting daily impediments. We can collaborate better, be more productive and have more fun.
Above all, we can unleash our imaginations and build richer and richer behaviors on solid, proven foundations.
