Balancing Standardisation With Innovation

In my earlier post Sustainable Software Development I talked about how to build software that can be maintained and improved over the long term, and how to run teams that can work without burning out. In this post, I want to expand on one area of this - how to maintain innovation while using standards to reduce diversity in your code base.

Snow-flake applications, which have unique characteristics compared to others in your estate, take a significantly outsized amount of time to maintain. This extra complexity requires specialist knowledge in your developers, and the time taken to context switching between applications is increased. You also don’t benefit from the economies of scale, where you can apply improvements across many of your applications simultaneously.

Historically, sharing code across applications would be done through shared libraries, but the modern software development landscape is more complex and many companies are moving to Platform-as-a-Service models (PaaS). This is where the infrastructure used to run an application is more than just a server with a CPU, some memory and a disk. Instead, it is a whole ecosystem of APIs, developer tools and a platform for running code. Whether internally developed, or purchased from an external company, PaaS systems are chosen because they abstract developers away from much of the drudgery that previously they would have had to work through, but this also constrains them to only using services provided by the platform.

Pimoroni's Interstate 75W

I’ve previously written about my attempts to get metrics about my house into Prometheus and to visualise them with Grafana. This project has gone well, and I can measure everything I want to apart from water usage - please let me know in the comments if you have a suggestion on how to do that! The one thing that’s missing is a “glanceable” display. My Grafana dashboards work well when I’m at my computer, but they’re not so great when cooking in the kitchen.

Sustainable Software Development

When you’re in the zone it can be hard to think about the future of the code you’re writing, but the time you’re spending writing it is just a fraction of its lifespan. Code may be written once, but it will be edited a few times, perhaps copied once or twice, and likely executed many hundred, if not thousands or millions of times. You as a software developer will (hopefully) have a long and productive career in software development, as will the team you work with. And finally, you also do your work on planet Earth (hi to any readers on the ISS), and without it you’d really struggle.

When creating or modifying an object or system that we intend to last for a long time, it is crucial to consider sustainability. This includes factors such as the sustainability of the source code, your or your team’s ability to work on it for an extended period, and the software’s impact on the environment. All of these aspects are significant and should be carefully considered.

If you’re working in a scrappy start-up, fighting for survival, then the long-term maintainability of your code will not be important to you. In most cases though, code can be expected to last for a significant time, and the cost of maintaining it will significantly outweigh the initial cost of writing it.

Small Celebrations, Big Motivation

Software development can sometimes feel like an endless treadmill. Push that commit, review that code, investigate and solve that bug. Rinse and repeat, day after day.

You probably have some high-level business and technical aims that you’re working towards. These might be releasing a large new feature, or perhaps migrating to a new infrastructure or a new software stack. These long-term projects might take a year or more to complete, and can often feel never-ending.

If you’re working on a mature code base it can be difficult to see the progress that you’ve made. One of your jobs as a leader is to help the team step back and see how far they’ve come, and one way to maintain motivation in a team is to celebrate achievements and show the wider business the progress that has been made.

It can be hard to know how to celebrate, and how often. Too frequently and you’ll be celebrating things that are too small and simple, and it will seem forced. If you wait for the large projects to finish then you could be waiting for a very long time, and it will feel like you never celebrate anything.

Leadership Stand-Ups

Standups are standard practice among developers, but when you move into the realm of leadership they stop. If you’re a team leader then you will probably join your team’s stand-up meeting, but often you only contribute a brief update, if anything at all. Mostly you just listen and perhaps facilitate discussion on other people’s updates.

In Five Dysfunctions of a Team by Patrick Lencioni (affiliate link included) the CEO in the story asks her executives to consider that group as their primary team. I’ve been asked to do the same too, but really, if you only meet once a week or perhaps even less frequently, how can you do that? If a group is your primary team then you should know (at a high level) what everyone is working on, and what their main problems are. A leadership team where you only discuss what people decide to bring to the table will not function as well as a group that can benefit from collective wisdom being brought to bear on problems.

When you start a leadership position your calendar suddenly fills up with meetings, so the idea of adding a daily meeting might seem crazy, and it probably is. However leadership is a different role to a developer, and you can use different processes to achieve the same goals.