The software world is full of ways to avoid duplication of effort. We automate many tasks for our users, for each other, or for ourselves. Among ourselves, one solution we focus heavily upon is code reuse.
We have invented many ways to reuse code, but in all but the simplest cases we do so by bundling it up. We tend to put it into a library, or occasionally into a programming language. This solution falls short in particular for cross-cutting concerns, and to solve those we often resort to frameworks. But those bring their own set of limitations, some at the beginning of the project, while others become apparent in long-lived projects.
In recent years, other attempts at solving this have arisen, such as substituting libraries and boilerplate for frameworks, and then creating tools to generate the boilerplate. These generators can be great to get you into the current recommended state for your chosen libraries. They are especially helpful for starting new projects, but once started they are rarely helpful again. Use them once, and then you’re on your own.
From Onboarding to Production
Libraries have their own set of problems. To gain users, support, and contributors, you have to be welcoming. And to be welcoming, the library is left in a permissive, sometimes chatty state. So that you feel like you are doing well. So that you don’t get stuck and give up.
The problem is that there is barely a library around (including security libraries) that doesn’t take a ton of work to prepare it for production environments. And for some strange reason, it is often the case that third parties – rather than the project maintainers – are the experts on how to accomplish this. And often enough, one third party is not enough. You have to combine advice from several third parties as well as the maintainers to achieve your goal.
And just when you think you’re done, here come the operations folks. They inform you that you’ve missed a whole bunch of other things and please go read up about CORS headers, correlation IDs, log aggregation, graphite, and… hey! Why aren’t you writing this down?
And every single team all over the world that is using the same set of libraries has to do the exact same thing.
Once More, with Feeling!
Not long after you get all of this working, you’re expected to do it all again, because monoliths are passé. So now you have to go figure out if you wrote all the steps down properly, or if you can just cut and paste code from the old project, and after a couple rounds of this they start to expect you to get it right on the first try. No pressure.
A Way Out?
Something that’s changed recently is distributed version control. Linux developers share their entire source code history across multiple locations, and multiple teams. Large companies use monorepos to share source between divisions or the entire enterprise.
Forking of repositories is another tool, commonly used in open source. On GitHub there are two reasons to fork a project. The most common is in order to have write access to the code so you can make changes and share them back with the project. Less common but almost as important is forking a project to _stop_ sharing code. Through abandonment or a difference of opinion, you want to take the code in a some other direction.
But what’s to stop you from taking a single project in several directions at once? Not that much. These days, it’s not uncommon for an organization to have a number of base Docker Images that have just the right mix of tools and versions to play nice in the data center. You’ll have a conservative image that has things almost everybody needs, a few others with things many people need, and then yours on top of it, with the stuff your team needs right this second (like the current version of your applications).
I know you can do a similar thing with git, at least on a small scale. I am sure, in fact, that many companies are doing this internally, just like people were refactoring before someone gave it a name, and another guy wrote a book about it. The question I’d like to know the answer to is how far can you take this? Which is why I’ve started working (again) on Hello, Enterprise World! over on GitHub.
“I make highly scalable Hello World Apps for a Living”
At which moment I could express the problem I was trying to solve.