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.

Business Layer Value

I had a great discussion with my supervisor about application architecture.

The question at hand was, what’s the value of the Business Layer? Most applications I’ve worked on are CRUD applications. Is there any value in a thin veneer over the data layer?

In my experience, most business layers consist of pass through methods.

If there isn’t any value, call the data layer directly. Handle the business logic on a case-by-case basis. In most cases this will entail creating a service class to encapsulate the business logic.

In the end, having a business layer that provides nothing but pass through methods is pre-optimization. It’s the “it will save me down the road” mentality. 95% of the time, it’s a waste, it creates multiple of points of change and it increases maintainability.

Weighted Random Distribution

This is genius; I could have used this a couple of years ago. I’m posting it here for safe keeping. Note that I am NOT using the random class. The random class is not truly random. It’s based on time. Time is predictable.

RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

byte[] result = new byte[8];
rng.GetBytes(result);
double rand = (double)BitConverter.ToUInt64(result, 0) / ulong.MaxValue;

//40 percent chance of being selected.
if (rand > 0.40d )
{
 ...
}
In Code