Manager – Shut Up

Eli Lopian    Management for Geeks    

One of the hardest things for me to do as a manager is to shut up!

When I see a flaw in our product or web site or in a plan session, I have to give my thoughts and ideas in order to make the best product.

Although I am making the product better, I am de-motivating the team. There is a simple equation that I forget to calculate when I give my (brilliant) ideas. I must calculate the value added to the product versus the motivation of the team. I am finding this very hard to do, but I must learn to shut up more often.

(picture from je2fs)

Measuring Effective Unit Tests

Eli Lopian    Code Integrity, Unit Tests    

What is an effective unit test?
A good unit test (via Jeremy Miller) is

• Atomic
• Independent & Isolated
• Intention Revealing
• Easy to Setup
• Runs Fast

But how do we know that the test is effective?
The biggest value of unit tests come when they fail. When a test fails, and we fix it, we have saved considerable time in discovering the bug, pinpointing the failing scenario and fixing it. The more bugs we find early on and the faster we fix them, saves us headaches and time. We also know that the longer we leave a bug in the system, the harder it is to fix.

I have debate this before (Measuring Code Integrity) and I think that measuring the Bug Fix Time is a direct measurement of the effectiveness of our unit tests. I have written a small application that sits on the developers desktop and we are starting to use it in Typemock.

This is what the small application looks like. Each developer can see how long it takes them to fix a test. We still have to tweak the calculation.
We are thinking of counting the failure time only after the first test is run (for TDD teams) although this will not count known bugs, as it is standard to write a test before solving them.
We do consider a group of test that fail together in one run and are solved together in another run as one test.