How should we view firefighting developers?

As in most things you have two options of dealing with adverse situations - pre-emptive and reactive. Pre-emptive work means dealing with a situation less likely to occur and if it does occur having a plan to ensure that it's impact is as limited as possible. Reactive work means dealing with a situation after it has occurred and doesn't consist of a premeditated plan. Now we all know that a pre-emptive approach is better than a reactive approach but pre-emptive work also has an image problem. It's viewed as being associated with documents, checks, abstract thinking, boring non-work that isn't helping the company to achieve it's aims where as reactive work is exciting, real time handling of a dangerous situation as and when it occurs and is immediate real work. But we all know that this is nonsense as most people when stressed and rushed make poor choices and have a tendency to act in a more emotional way. So why do we value reactive work more greatly than pre-emptive work?

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 the lack of management experience can lead to some disastrous decisions being made that affect the whole outcome of these start-ups. One particular attitude that I've faced again and again is:

"Why does your team not work till 8 each evening?" or "Team X was here on Saturday, why isn't your team also here?"

As a team lead, it is often my responsibility to describe the importance of rest and relaxation on team performance. But more importantly to impress upon the importance of pre-emptive work in ensuring that Saturdays are reserved for family time rather than reacting to some predictable mini disaster.

Firefighters vs Health and Safety inspectors

Firefighter

Firefighters quite rightly are portrayed in our society as incredibly brave individuals who go into dangerous situations and save people, processions and beloved family pets. 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 have meant that we need a professional fire service in continuous deployment to deal with unexpected 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 who get in the way of business. However let's do a thought experiment together:

What's 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. So why then the widely held attitude about health and safety inspectors? It's because as a society we still measure work by time-spent and especially time spent in a visual fashion which is why I need to keep having the same conversations about my "lazy" team and why that "lazy" team keeps outperforming other "more dedicated" teams.

👊🚒

Pre-emptive software development 🔥

Pre-emptive software development doesn't have to be expensive and is probably something that the majority of us are already doing. 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 actually consistently do the things that you have agreed to put into practice or maintain a standard 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 will drop - 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 it.

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 to quote Grace Hopper:

"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.

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 released 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.