Coming out of a job where I was working on a 20-year old Perl codebase, I’ve got some burns to get off my chest. I’m reading “Accelerate” by Forsgren, Humble and Kim which claims to have scientific backing for what makes for efficient development in a team. In my recent experience:
- Use decent version control. To me, that means GitHub. Use a branching strategy to code each branch to a JIRA. Make the branches short-lived, preferably a day. GitHub is stateless. Diffs are resolved at merge-time when pull requests are made. Under NO circumstances use something like Perforce. That is like putting a large speed bump under a low slung car. It’s stateful. Mapping a repo into your filesystem is a pain. Rewinding commits is a royal pain. Ugh.
- Release often, releases should be easy. A marker of a high performing team is how frequently they release software. A release should not be confined to one person on the team and take half a day.
- Great balls of mud are hopeless. We’ve been writing new software as microservices for a while now, and more recently bundling them up in Docker containers (and if you’re really advanced then using Kubernetes). In the Perl world that means using a framework such as Mojolicious, Catalyst or Dancer with excellent modules like the Template Toolkit for the view and DBIx::Class for the model and not v1 of view software that’s barely been touched for years and v2 exists. It also highly bound to Apache and hard to use elsewhere.
- Ongoing support for mod_perl in Apache 2.x is ongoing. It’s already been abandoned in Apache 1.x so I would note that software is doomed at some point.
- Be very careful layering software upon software. Or using features that make things opaque. Oh, and having magic variables and not documenting them. For example, you have Puppet. That’s great. Why not layer Heira on top and render most of the puppet documentation useless. Or use a templating system that magically calls in a hierarchy of other templates. Oh, and where does that database handle come from? Somewhere in the bowels of that page startup. Not sure which module.
In summary, I’d say be aware of the speedbumps. How can you improve them?
One thought on “Efficient programming”
Comments are closed.