Measure... Measure... Measure...
If you are a serious professional, you will always be looking for area of improvement with in your work eco-system . Measurement is the first step that leads to control and eventually to improvement. To Measure something, you got to understand it. If you cannot understand what you are measuring you can never control it. If you cannot control it, you can never improve it. There are some problems with measurement, and it is too likely that you end-up measuring wrong things.
A law called Good heart’s Law say’s that.
In the world of software development irrespective of the kind of job you are having, majority of the aspects of job are usually measured. For example In a product team, Developer ‘A’ might deliver 30 story points, Developer ‘B’ might deliver 10-story points in a quarterly, that does not mean ‘A’ is better than ‘B’. Still, that’s what some managers look at but no one says so openly, to be honest even I too was once judging people on this regard. Some folks even measure number of hours spent in the office, and some measure lines of code that is where Good heart’s law looks so convenient to apply :) .
People go by measuring things like number of hours and number of lines of code because to an extent they are too easy to track, that gives he/she some good reason to decide on whom to give a good bonus or rating or decide who deserves the best treatment.
There’s also a good related quote that points out that
Just imagine if we start rewarding people based on lines of code, people start writing more code on daily basis irrespective of weather it is required or not. People might go one step further and start Re-writing things and stop Re-using existing stuff. This might reduce the quality as well because some people might stop writing tests for code and start creating legacy code. Some might even start writing long classes, long methods without thinking about abstraction etc … After many days of such a pathetic life what we end up would be a working software looking like a Frankenstein Monster which is extremely huge and fragile.
The customers of a product do not care weather how many lines of code are in the system. They care whether the feature works properly or not. They also love your product based on how soon you can deliver the requested changes. So in that way these are really horrible measurements.
Now lets talk about life, to measure how successful you are can you use your net worth ? or Can you use the engine capacity of your car by looking at your neighbours nice looking AUDI car ? Or Can you use the kind of smart phone you are using ?. If you are measuring your success with such materialistic things, you end up prioritizing things which are not so important in your life.
A similarity with each of such bad measurements in your life as well as in software is they are too easy to measure. Improving on items which are too easy to measure actually may reduce the quality of your life just like it reduces the quality of your software.
If I’m stressed, I’m less creative. I’m less likely to consider the tradeoffs. I’m going to optimize for what’s being measured.
Usually things most worth measuring are the hardest to measure.
For eg, If you are measuring developer productivity, Here are the things that I would question
- Are you reliable or someone I can trust for getting things done ?
- Do you have a positive mental attitude ?
- How well you collaborate ?
- Do you have a growth mindset ?
- You write Readable && Testable && Maintainable && Scalable code.
- Are you humble enough to admit that you were wrong and admit that someone else is right during Code reviews ?
- Are you humble enough to admit that you don’t know ? and Say, I don’t know.
These are really hard to measure. These measurements are a much better quality indicators. Just question yourself, if you have set of developers in your team who scores really high in all those 7 things that I have listed above. you can actually deliver anything without any problems .
If you are hiring someone from some Big company or someone who had solved some complex problem or someone who is aware of some complex algorithm, and he is too poor in all those 7 things that I have listed what is the use of having such an Einstein/Newton in your team.
So measuring stuff is good for taking decisions as long as your decision on what all to measure is wise enough.