The true measure of … anything?

Coloured lines on a graph

Furlong–firkin–fortnight (FFF): A humorous system of units based on unusual or impractical measurements.
Also sometimes shortened to firkins per fortnight (FF).

This week's word is courtesy of Lewis, who actually referred to FF during his recent Object-Oriented Analysis and Design course.

There are stranger units of measure. As a 19-year old, Donald E. Knuth developed the "Potrzebie System of Weights and Measures", which was published in the Mad magazine. Donald Knuth later became a famous computer scientist, well-known for his multi-volume work, "The Art of Computer Programming".

To measure or not to measure

In business we are often told that "you can't manage what you can't measure". To know if you are successful, you must define what success is, and measure against that definition.

But it is equally true that "what you measure is what you get".

Measurement is important. It might be more important now than ever before. Last week a client told me that her company has realised that their employees can still meet their targets working remotely. Another person told me that her boss does not believe that employees work if they are at home. How do we know? We measure.

But what we measure is more important than the act of measuring. If we choose the wrong measure, we can just as well use FFF for all the real good it will do us.

The dark side of measurements

One problem is the dark side of human nature. People will manipulate the system to meet the measurements. If you measure project success by performance against schedule, there is a risk that schedule estimates may be padded to meet the target.

Another problem is that many measurements don't take a systems approach. Business (and software systems and projects) are systems. They consist of interdependent elements that must work together. The whole is greater than the sum of its parts. Is it success if the only way you can meet that project deadline is with excessive overtime and employee burnout?

And here's another problem. In many companies, measurement is a top-down approach. The company's targets are broken down into smaller and smaller targets to eventually determine your performance objectives. But what if you don't agree with the target? If I tell you upfront that a project deadline is unrealistic, should I still be measured against it?

How do we measure developers?

Here are some of the most common measures used for developers:

  • Source code metrics, like lines of code, dependencies, duplication and bug fixes.
  • Agile metrics, like lead time, cycle time and team velocity.
  • Production analytics, like mean time between failures (MTBF) and mean time to recover (MTTR).

None of these are wrong. But that doesn't mean they are right either. I mentioned the concept of SPACE in a previous blog post. It sounds impressive, but I think it will take time and effort to implement.

What do you think?

How do you want to be measured? What do you think is fair to you, as well as fair to the company?

Leave a Comment

Your email address will not be published. Required fields are marked *

Thank You

We're Excited!

Thank you for completing the form. We're excited that you have chosen to contact us about training. We will process the information as soon as we can, and we will do our best to contact you within 1 working day. (Please note that our offices are closed over weekends and public holidays.)

Don't Worry

Our privacy policy ensures your data is safe: Incus Data does not sell or otherwise distribute email addresses. We will not divulge your personal information to anyone unless specifically authorised by you.

If you need any further information, please contact us on tel: (27) 12-666-2020 or email info@incusdata.com

How can we help you?

Let us contact you about your training requirements. Just fill in a few details, and we’ll get right back to you.