One of the things I think about regularly is how to properly manage a programming team.
How do we set up a system in which we deliver on-time and on-budget? How do we ensure that our work output is not only fast and accurate, but sustainable long-term? And how do we improve the team we’ve got, and make our workplace somewhere that attracts people?
I present here some of the things I think a programming team should value. I don’t expect that the values themselves will be new; however, I have placed them into a framework which I hope provides some novel insight.
1st order values: how do we do well right now?
The first category I am interested in considering comprises those values that are short-term. They are basic, small in scope, and are concerned only with the current deliverable. I consider the following to be 1st-order values:
Delivering more features faster is how we do well on a programming team in the short term. This is the domain of rock-star programmers and slave-driving micro-managers. They are short-term concerns, and staying at this level will stunt your growth as a programming team. As I stated in an earlier post, being able to freely re-use earlier work is a double-edged sword. We get to carry our previous work forward without redoing it, but we are also expected to do so. Building more features and building faster without concern for the future will result in asymptotic speed and feature growth - eventually, there will be so much cruft that we must wade through in order to build more or fix bugs that we won’t be able to get anything of substance done. And so we move on to:
2nd order values: how do we sustainably deliver over the long term?
The second category is concerned with continually delivering and not slowing down as our project gets bigger. 2nd-order values allow you to grow a team and manage a larger, more complex project, thereby delivering more value to your customers. I consider the following to be 2nd-order values:
Simple code has low overhead to reason about. Projects can be simplified in several ways. The best way to keep a codebase simple is to keep it small - don’t add anything you don’t have to and remove anything that’s no longer used. If you have to grow your codebase (like most of us), you can control the increased complexity by sanely encapsulating parts behind easily-understood interfaces, preferring well-known design patterns, and using language idioms. Keeping a codebase simple results in more regular deliveries, better predictability of work required to implement features, and less bugs, all of which add up to more predictability of your team’s output.
Maintainable code has low overhead to understand. Building a project to be maintainable means that your programming team will be able to fill in for each other and add members. Increasing maintainability can be done by (in order of increasing overhead) writing code clearly, so that it is self documenting; commenting anything that isn’t or can’t be clear; and creating external documentation for anything that is too large to be understood by merely reading the code. One of the tropes that often comes up when talking about maintainability is “bus factor”: if our lead programmer got hit by a bus, would our team be unable to pick up where he/she left off? If so, our bus factor is 1. Ideally the codebase should be independent of individual programmers.
3rd-order values: how do we increase our productivity?
The third category of programming team values are concerned with improving our team. These are the 3rd-order values I’ve come up with:
- Collaboration tool choice
Training is an easy win in this category. Making sure your team is up on the latest techniques allows us to take advantage of newer knowledge. Keeping your team up-to-date is investing in them as individuals, which makes your team a better place to work, and providing a flow of new ideas into your team keeps them engaged and prevents stagnation.
Team-building activities are another long-term win for your team. I’m not talking about ropes courses or firewalking or dodgeball here, though for the right type of team these work well. I’m thinking of regular happy hours, lunch & learns, and paid professional conference trips. Anything that increases your team’s sense of being a team will make them more creative and happy to come to work as well as reducing collaboration overhead.
Speaking of collaboration overhead, choosing the right tools for collaboration goes a long way here as well. For example, having a chat application like Slack reduces response time compared to email. There’s always a balance with these choices. With Slack specifically, it’s important to have a culture that allows someone to disconnect and just focus on their task at hand if they need to.
It’s important to consider that with software, you’re not just building the current deliverable. You’ll probably build on it and continue using what you’ve built for quite some time. Consider more than just 1st-order values. Think about 2nd-order values in order to deliver sustainably, and 3rd-order values to take your team to the next level.
Do you see any glaring errors or omissions? Have any additional thoughts? Let me know down in the comments.