Churning out story points is not enough. You have to build for tomorrow, not just for today.

Something I see again and again is teams breaking their backs trying to produce as much functionality as possible. The business have a great tool for measuring the productivity of the team (story points), and this leads everyone to try to perform well on that axis.

The result is bad code that doesn’t scale, is buggy, and hard to understand for everyone. Introducing new features is done by copy-pasting and changing a little. Changing features is hard to do in a consistent manner – you are always afraid you missed something somewhere.

I think that the background to this mess is how easy it is to measure story points, and how hard it is to measure code quality.

Code, to me, has three distinct values, and I don’t think I’m alone thinking this.

1. What the code does
If the code doesn’t do what it’s supposed to do, it’s of little value to the business. In this value, I also group stuff like performance, scalability and responsiveness. Badly performing code can be as bad as code that doesn’t perform at all – from the business’ perspective.

2. How easy it’s to extend and change
Adding new features, and changing underlying dependencies is what I think of here. How hard would it be to switch from our home grown cache to memcached? Is adding a new supplier as easy as creating a new class and changing a configuration file, or do you have to do major surgery and add new code in unrelated classes to make the change? Giving the business the option to change their mind is very valuable.

3. How easy it’s to understand
And, of course, you have to understand the code you work with. New developers shouldn’t need months and months of training in the code base to become productive. I put consistency of the code here. If you learn one part of the system, you should be able to quickly be productive in other parts of the code. I value the code base as a whole. I often see really clever developers running away from the rest of the team. What this leads to is difficulties for everyone else. No-one dares touch the brilliant developers code, because they don’t understand it.

When you work with code, you can’t constantly be adding to one value at the expense of the other values. Just adding new functionality, and not improving extensibility and readability is bad business. You are
putting up yourself for failure later on. At the same time, you shouldn’t make the code easier to understand by just removing functionality. You need to strike a balance that doesn’t hurt you in the long run.

That’s why I always want teams to have a tech lead. Someone should keep their eye on the non-functional values of the code base. It’s easy for everyone to be drawn into the race for story points in the current iteration. Instead, taking on a little bit less, and using that time to make the unit tests easy to read, or start refactoring that huge database class makes a lot of business sense. It’s difficult for the product owner to see this clearly, so team, with the help of the tech lead, have to make this a priority.

Posted by Andres on Tuesday, September 9th, 2008 at 15:53.