Faster is Slower


We have all read that story during our childhood where a fast rabbit (or was it a hare) was beaten by a slow, yet steady, tortoise. The importance of sustainable progress was taught to us well in advance but we forgot the lesson while growing up.

We are so rushed about everything that we have forgotten the pleasure of enjoying the moment. Hang on, this blog post is turning into a lecture on “living in the moment”. Well, that’s not what it is going to be. It’s going to be about the challenges I have been facing with some projects while trying to match an aggressive timeline set by the client.

At present, I am managing two projects for a client based out of Nigeria. One of the two projects is a daily-deal web application and the other is an e-commerce site. Both these applications are doing fairly well and generating a sizeable revenue to the client. And the company I work for is happy too, well, at least financially.

But these projects are becoming a death march despite my desperate efforts to the contrary. (I didn’t know Wikipedia had a page on death march in project management).

I can see the development team working till late everyday. The code quality is going down. Time is being spent more on fixing bugs than writing features.

My initial thoughts on this state were that perhaps the team is doing a shoddy job, delivering poor quality work that too late. Which is why they are having to work late to meet the deadline. But I was wrong. Mea culpa.

The whole problem is with the deadline. The word has actually begun to signify a point in the future beyond which lies death.

The whole situation starts like this: the client has a brilliant idea (every month or so) that needs to be taken to the market immediately. The team is expected to start coding even before they have a firm grasp of what they are working on. All this can still make sense as Agile is meant to allow, in fact welcome, frequent change. But not when all the 3 sides of the iron triangle (scope, resources, and time) are set by the client thus strangulating quality that lies within the triangle.

The developers (considering themselves a part of the same team as the client and equally responsible for its success) agree to the deadline often factoring in extra hours in a day and a few Saturdays. Even at this juncture everything looks possible; a stretch goal but possible.

While they are in the middle of the release, suddenly a mail comes announcing some hotfixes (a fix or a quick feature that needs to be deployed to the production site ASAP and has priority over current release / features). The team, again feeling responsible for the application, does those fixes. But the tragedy of this whole story is that the darned deadline doesn’t move a minute!

Mike Cohn, a highly respected writer, speaker, and practitioner of Agile, wrote the following in his book Agile Estimation and Planning:
Leave some slack. Especially when planning an iteration, do not plan on using 100% of every team member’s time. Just as a highway experiences grid- lock when filled to 100% capacity, so will a development team slow down when every person’s time is planned to be used.

This is where we are going wrong. Not only we factor the full eight hours per day of each team member, we also include a couple more so as to meet the deadline. Which is why we never have enough time to write good code in the first place, do a thorough code review, or test the app well. In some cases, unit tests are skipped altogether so as to deliver on time.

This is why I have begun to realise that in trying to become faster, we have become much slower. While we somehow manage to deliver on schedule, a lot of issues that should have been taken care of before releasing to production are looked at after the release. Thus the point of stability moves to well beyond what could have been a justified release date or the deadline with a reduced scope. And it causes heartburn to everyone: to the users who face issues due to buggy code, the client who faces user’s complaints, and the dev team who work day-in day-out.

I have actually experienced an automobile analogy of the above. I had to meet someone at a destined place and time. In order to avoid being late, I rode my motorbike much faster than I normally would only to get into an accident. The meeting got cancelled, my motorbike got damaged, and I got hurt. Faster became slower and expensive.

Considering the software context again, the client frequently gives the example of Apple as a benchmark of quality. However, in trying to attain that benchmark, I would not let my organisation become Foxconn. The team has had enough and I have had enough. It’s time to take a stand even if it means like the one below:

Hold Strong

Image Source:


One thought on “Faster is Slower

  1. Great article, I enjoyed reading it.

    The maxim that “slower is faster” also applies to matters of technical excellence. Refactoring tests to make sure they run smoothly on your Jenkins server (for whatever reason they are failing at the moment) takes additional time when the feature is done.

    But that time will pay itself back when you have that additional test coverage and someone makes a change down the line.

Leave a Reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s