The art of cutting corners

I’m pretty sure that if a developer built a house, it wouldn’t have any corners. Their first instinct at the sight of an obstacle would be to get rid of them. Corners you say? Who needs them! And then they’ll all start chanting: Cut a corner, cut a corner! 

At Revio, we challenge the developers to deliver estimates that they believe in. We tell them not to consider the expectations of management or customers. Consider the task at hand, and attempt to figure out how long it will take to get it done, and done right.

As discussed in an earlier post, accurate estimates are hard. That means even though we estimate with the best intentions, we might still end up hard pressed for time. And even in the flowery, sunny world of our little company, we occasionally misunderstand the customer. So there we are, with maybe 3 developers in the team, ten days until deadline, and 500 hours of work yet to be done.

Cut corners:

Fig. to take shortcuts; to save money or effort by finding cheaper or easier ways to do something.

To do something in the easiest, quickest, or cheapest way, often harming the quality of your work.

In a situation like this, the vision of an unexperienced developer often narrows down to the very next line of code as he mentally calculates how to shortcut his way out of his misery. Must. Code. Faster.

Let me share with you what I as a manager would want the developers to do in this situation:

  • Give me a calculator, help me type in 3 developers times 8 hours times 10 days equals 240 hours. Explain that we have 500 hours yet to be done. Then ask me patiently what I would like to do with the 260 hours worth of work that we do not have the capacity to complete.
  • Tell me to read “The mythical man month” if I suggest to add another 3 developers to solve the crisis.
  • Ask me wether moving the deadline is a viable option (More often than not, it actually is).
  • Work together with me in order to figure what features can be moved to a later phase, while still delivering as much value as possible in the current phase.
  • NEVER EVER cut on code quality (architecture, coding practices, coding conventions).
  • NEVER EVER cut on quality assurance and testing.

If you discover mid-project that you have more work than you have hours available, you will not get everything done in time. Period. Going into a team-wide panic and start building up technical debt like crazy won’t really help. In the long run, it’ll just make things worse.

Often, quick and dirty actually takes even longer. This is especially true if you have poor specifications and need to do a lot of re-work. When you tell me “yes we can” when actually we don’t, that’s bad for both of us.

So in conclusion: The next time you’re stuck in a doomed project, make sure you stay realistic and maintain your own integrity. Your manager may ask you to get 20 days worth of development done in 10 days, but it’s up to you to accept it.

@TSigberg

Advertisements

Posted on May 18, 2012, in Management, Software development and tagged , . Bookmark the permalink. Leave a comment.

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

%d bloggers like this: