You have surely met a client asking for an urgent feature or change.

In fact, every second client wants their change as quickly as possible. You’ll get to hear variations of “This is really urgent”, “The management wanted it yesterday”, “it is essential for us to deliver this”.

Kimber Lockhart made very good case against urgency in Don’t create a sense of urgency, foster a sense of purpose.

A sense of urgency isn’t the goal. Trying to create urgency reflects the age-old confusion of hurrying with speed?—?the misguided notion that if you’re not always hurrying, you’re already behind.

I agree wholeheartedly with her. In fact, as someone who has consistently on receiving end of “urgent” requests, I have been through the urgent and random deadlines a lot of times.

You never do your best work when hurrying

We are expected to deliver great work. And great work requires time.

I am not advocating just dumping the deadlines and go on an epic quest to create your best work. That’s a recipe for never completing something. As creator or Ruby on Rails, DHH wrote in Remove the stress, pick a deadline:

The opposite of the deadline, the once much heralded When It’s Done, is the oppression of a blank canvas.

What I have observed is that you do not do your best work when hurrying. You deliver good enough work.

That may fly for some things. But for a lot of things, good enough doesn’t fly.

I have done my best work when I had no deadlines. In fact, one recent feature that I completed on a big product was done entirely without telling anyone. I wanted to improve and it was a small part of the app but I had an idea and implemented it in one night.

That’s the sort of sense of purpose Kimber mentioned in her article:

A strong sense of purpose manifests when a software engineer watches a potential customer struggle with a workflow and stays late to make the changes that make it easier. It shows itself when a designer spends their weekend on a few extra iterations because they felt engaged with the problem at hand and want to produce a better solution.

Hurrying leads to bad software

Joel Spolsky recommends writing functional specifications before writing software. I will take liberty of assuming that a hurrying software engineer won’t take time to write specs. Here’s what Joel says in Painless Functional Specifications - Part 1: Why Bother?:

Programmers and software engineers who dive into code without writing a spec tend to think they’re cool gunslingers, shooting from the hip. They’re not. They are terribly unproductive. They write bad code and produce shoddy software, and they threaten their projects by taking giant risks which are completely uncalled for.

The moral of the story is that by quoting enough popular and influential writers, you can prove anything. Wait, not that one.

The moral is that it’s not possible to write good software when you have an arbitrary deadline hanging on your head. It results in less productivity and ultimately, burnout.

An experiment to balance urgency and good software

I am not experienced enough to recommend much. But I can go ahead with an experiment.

I think specifications can help a bit here. So, for next 4 weeks, I will not write any new feature without a specification in place, be it for a small project or work.

I will report back results here. Have any suggestions or questions? Comment here or contact me.