3 min read
Getting the Job Done

There is a fine balance between doing it right and delivering.

I manage a team of 8 developers. Each hour the team is blocked is eight lost development hours.

A co-worker was tasked with getting me a database. After two days of waiting, I inquired the status. He said we were having problems with the data import. When he scripted out the data, it was almost one gig. One gig was a bit much to check into subversion. He was looking for an alternative method.

Another day goes by. I asked him how it’s coming. He says it’s almost done. Ok cool, I’m three days down, 192 hours of lost development time. I’m itching to get started. My team is bleeding hours.

On the fourth day, he’s ready. Finally! He sends me the database project and the import database scripts. He’s using PowerShell and BCP to import the data. I send them off to the team with detailed instructions.

The team is 12 hours ahead of me, in India. The feedback loop is 12 hours. It takes 24 hours to get anything started.

As Murphy’s Law states: “Anything that can go wrong, will go wrong”. The team ran the data import scripts and were met with failure. The Powershell scripts failed, a security issue prevented the import of data.

I’m five days behind. 320 hours have been lost. The deadline is looming, we need to get started.

At this point, I need to get the database up and running for the team. On my machine, I detach the database, zip it up and send it to the team. Every developer knows to reattach a database. Within an hour of getting the database all, eight developers have a functioning database. Success!

Creating a clever process is good, but sometimes just getting the job done is more important than clever.