Firefighting developers

Firefighters are portrayed, quite rightly, in our society as heroes. They courageous run into dangerous situations and save people. However, let's think about why we need firefighters. We need firefighters because our man-made environment has been built up over hundreds (or even thousands) of years, by many different hands with differing ideas on what's important. This legacy of inconsistent design, coupled with our differing attitudes to fire safety has meant that we need a professional fire service in continuous deployment to deal with fires (and of course cats up trees).

Now contrast this with society's portrayal of Health and Safety inspectors. They are often portrayed as busy bodies getting in the way of business and generally seen as jobworths.

However let's do a thought experiment together:

What do you think is more costly?

1. Having to pay more for fire retardant materials to insulate the walls of your home?
2. Having to crawl your way through the ash pile that was your home, trying desperately to find the baby-photo album?

2 has to be more costly than 1. Yet despite this Firefighters are held in much greater regards by society than Health and Safety inspectors.

Firefighters vs Health and Safety inspectors

Firefighting can be viewed as reactively dealing with a situation, whereas inspecting can be viewed a preemptively dealing with a situation. Preemptively means taking steps to ensure that the adverse situation never happens. Reactively means dealing with the situation after it has occurred.

Let's think about this in the context of software development. The pre-emptive approach is almost always better than the reactive approach for both a company's image and the wellbeing of the team. Despite this the pre-emptive approach has two problems:

1. Image
2. Measurement

The pre-emptive approach is associated with documentation, checklists, process and generally non-programming activities; where as the reactive approach is exciting, real time handling of a crisis situation with lots of programming.

It's straight forward to measure that your server is no longer crashing; it's more difficult to measure the impact that a unit test had on preventing that server from crashing to begin with.

These two problems mean that the IT industry is often in reactive mode more often than it should be. As a start-up addict, I've had the opportunity to work with some really great people on very cool projects but I've had the opportunity to see how a lack of management experience can lead to some disastrous decisions being made that can affect the whole outcome of these start-ups. One particular naive management belief is that a developer/team that spends more hours working is a more productive developer/team, this is often expressed with comments such as:

"Why didn't you stay till 9PM last night like X did?"

or

"Team X was here on Saturday, why wasn't your team here?"

I find this attitude very troublesome as it's now widely accepted that when people are over-worked they tend to make more mistakes. So in fact wanting people to work longer hours can lead to a decrease in productivity and at some point these additional hours will actually have a negative impact on the project - this often takes the form of introducing bugs. Each bug that we introduce is a form of unscheduled work so that the team that has to work Saturdays solving past mistakes is potentially ensuring that they will also have to work future Saturdays. Now a key component to breaking this cycle and ensuring that we work smarter rather than merely work harder is good pre-emptive work.

👊🚒

Pre-emptive software development 🔥

Pre-emptive development doesn't have to be more expensive than reactive development and is something that the majority of us are already doing in some capacity. Let's look at some basic steps we can take to improve our development process and be "inspectors rather than fighters" (there's a phrase that won't catch on):

1. (Mis)Communication
2. Enforcement

"Eh, that's only two points?"

Everything in a team comes down to communication and enforcement. Without good communication you don't actually have a team; what you have is a group of individuals working on the same project. Without enforcement you won't ever act consistently implementing the plan that you and your team have agreed to put into practice (or to maintain that plan when things get tough). I'm sure we have all told ourselves that "this is just a shortcut, I'll refactor it later" and we never really get the chance to do that. Too many shortcuts and eventually the overall quality of the project drops - developers tend to write code to match the quality of existing code so if your project is poor quality your project will remain poor quality unless a huge amount of effort is spent to change to improve that quality.

Communication

By making sure that the team communicates well, the team is able to avoid unexpected surprises when it comes to merging code changes into the main branch. Little and often should be the mantra here - daily stand-ups, work-boards, peer reviews (code and interpersonal), tight feedback loops (between peer-to-peer and boss-to-underling), tech talks and healthy debate.

I also included miscommunication as Grace Hopper says it best :

"It's easier to ask forgiveness than it is to get permission"

Sometimes you need to be prepared to invest the time in making smart technical choices even if you are unable to get your boss to agree to it, as it's your responsibility to ensure the health of the project above all else.

Enforcement

Team culture should be self-enforcing through peer reviews (yes it's in both communication and enforcement), coding conventions, processes and automatic testing suites (super important). It's much easier to maintain a standard than it is to achieve it so once the hard work is done in improving the code base, don't lose all that effort.

By investing in both communication and enforcement you will be able to develop smarter rather than harder and solve issues while they are still ideas rather than bugs.

Calendar time?

So who knew that being an inspector could be so sexy, maybe we should organise a calendar 📅 and show those firefighters how to really do it?

Ok, ok, maybe I'll pause the calendar (email me after you've realised how awesome it will be - no rush) but at least you should begin to look at your development processes and ask yourself:

"If you're fighting fires because you need to do so or if it is because you are not putting in enough effort at the start of the development process"

If it turns out to be the latter, get ready to start chatting and enforcing your way to a better tomorrow.