War and Peace

If you took any time slice from my career, I could easily tell you if that time period was war time or peace time. Based on the projects, the management, my co-workers, I was either stressing out (war time) or bored out of my mind (peace time).

What I want to do with this post is contrast war and peace in a software creation environment.

War Time

It’s easy to know when you’re at war. There is a constant feeling of subtle panic every time you sit down. You leave the office drained, tired and quite often angry.

Here are some specific symptoms I’ve noticed from my career:

1. You have several outstanding production issues that are non-trivial.
2. You have abandoned quality in favor of quantity. (No unit tests, code review, etc.)
3. Stakeholders are running amok. You are strongly encouraged to say “yes” to everyone.
4. You are missing management to help shield you. You have to make managerial decisions, sit in meetings and develop politics.
5. You are working extra hours to keep up.

There are of course more symptoms. Let’s look at peace time to help emphasize the divide between the two:

Peace Time

1. You have time to read articles about your industry – without feeling guilty.
2. You have time to write unit tests.
3. You have time to re-factor code per (2).
4. You have time to think about names for objects, classes, etc.
5. You have periods of focus that go longer than one hour. It’s normal to have four interrupted hours of time.

Conclusion

Now the point of this post is not to argue that developers should try to get to peace time. The point is not to decry the horrors of war. That is obvious.

The point is that as an organization, you need to know what state you’re in.

If the development team has bloodshot eyes and the stakeholders are playing Nerf basketball, then there is a major disconnect. One team thinks it’s peace time and the other is at war.

This is bad because expectations end up missing each other by wide margins. A peace time customer will ask for 100 features for a system. If he knew the development team was at war, he wouldn’t ask for 100 features. When you’re at war, compromises and sacrifices have to be made.

For any job I’m finding it’s important to know which state I’m in and then communicate that to others. It’s only fair that the stakeholders know that I consider us to be at war. Hopefully it helps them to adjust their expectations.

War and Peace

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s