Search This Blog


Wednesday, January 30, 2008

The Curse of LoC Metric

The new manager entered the boss office. He had a grand plan for the company.

"Boss, even though today is the first day I start working, but I believe I have made some observations that you will find helpful in driving the programmers to be more productive."

"Oh yes? Tell me what you've got." The boss asked, in reverent tone, as if he was speaking to the highest priest of the One Religion.

The company was a software company, meaning, it made and sold software and the services around it. As such, software development was the core activity of the company and the programmers were the Most Valuable Player, at least that's what the company manifesto said. Without the programmers, there would be no software to make, and no revenue. Even though the boss did not have a technical background, but he understood this clearly ( even better than some programmer-turned-boss!). He poured great resources into getting the best software developers. (He read blogs from great programming gurus such as Joel Spolsky and Eric Sink. )

But assembling a team of good developers ( not yet great, mind you!) was not so easy. Despite that the colleges churned out batches and batches of engineering, computer science and IT grads, not many can speak or write proper English, let alone something more rigorous than plain English such as C++ or Java or Ruby.

Given his lack of technical ability, he needed someone to manage the software developers. So in the Manager he found his man. The manager was a man with goals. He set metric, he strive for the metric. The boss was absolutely amazed when the manager told him that he had increased the worker's productivity by 50% when he worked for a manufacturing company. You know, the manufacturing pipelines were already pretty efficient those days, increased the productivity by such a wide margin was tantamount to a magical performance.

There was only one problem. The manager did not know a damn thing about programming. But the boss picked him precisely because of that, contradicting the programming gurus' advice.

The candidates who came for the manager role interview did not show enough efficiency and will to make the company successful, the boss felt. Because when the boss interviewed them regarding the specific benefits they could bring to the company, all of them assured him that programmer couldn't be managed based on specific metric or figures. Programming is an art more than a science, they told him.

The boss did not like it. He liked numbers, prediction and certainty. The Manager was the one, the only one who could offer him that confident.

The manager laid down the plan for the boss. This one neat sentence summarized his plan.

"Let the programmers be rated based on the amount of code they write; the more code, the more productive, the better a programmer is! "

So the manager talked to the software developers, telling them that they would be managed based on the all encompassing Line Of Code Metric. Of course the software developers did not like this. Why should they?

Some of them began to protest:

"Sir, my work required more thinking than coding, so I would be unfairly judged!"

"Sir, I needed to spend time to understand the new technologies and this would be counted against me!"

The manager retorted:

"Boy, don't try to find excuses! I am convinced, based on my past experience this is the best route for the company to take! So shut up and start writing code!"

There was a reason for the manager to be tough on them. The developers were lazy. Can you imagine this? They were browsing reddit and dzone in the office! The company employed the developers to work, to write new features, not to read leisure stuff. Just in case you don't know, reading online, including reading programming tutorials or blogs was considered as a waste. If you need to brush up your skills then please do the reading at your own free time.

Disgruntled, the programmers went back to work. The manager set strict metric to motivate, I mean, to manage the developers. The developers who wrote less than how many lines would be denied bonus and promotion. Of course, some developers would like to work around the system by putting in a lot of comments. The manager knew all these tricks. Only the real code got counted. So no back doors, and don't try to be clever. The manager warned the developers.

Everyday went by. The manager looked at the report and smiled at himself. After initial resistance, all the developers cooperated and produced acceptable Lines of Code everyday. Everything went well. During the morning report, everyone would report what feature he implemented and everything was going on smoothly.

After last feature got implemented, the boss threw in a big party, he gave everyone a big applause and launched the software the very next day.

And then the boss dismissed all the developers on that very day. The developers were no longer needed. The product was finished. When the show ended, who needed the actors? He retained the manager though, because the manager was still useful for the next project.

But making software was and is not making breads. Once you sold a copy of an application you needed to maintain it. So the software got a lot of complains from customers.

It was buggy, slow and downright unusable.

The manager and the boss were perplexed. Everything was well on the book, so why the end product was so bad? A lot of the features worked well on the developer's demo, but when the customers did exactly the same step, the program crashed. This was not too bad, at least the program waited until the customers bought it before it crashed. The program could even hanged even when the sales followed the instruction in the tutorial!

Can you tell them why?


Sudeep D'Souza said...

If you can hire developers that will manage themselves with minimal direction and help then you don't need managers from the manufacturing sector to help you increase prodcutivity. I have a post about what I look for in a great developer when I hire someone

Monkeyget said...

Why? Bad developers. They probably didn't churn out enough lines.