metrics and worm holes
It took me more time than I’ve expected to start the New Year on my blog. So here it is, the first post for the New Year! Happy New Year!
The last year I was at conference and attended to ‘s presentation about . This talk based on his post on the IBM’s web site about and the whole series.
The talk was about and – quite interesting tools to discover potential bugs and hard-to-maintain code in a project. What was the most important for me, Neal used the project as an example, especially the class – you can find the details in the mentioned article. He presented how to prepare these metrics, how to read them and what they mean. A really interesting talk.
After all, I’ve asked Neal to give me more details about the problem and few days later I received an e-mail from him. I’ve followed his advice and inspired by his talk I’ve gave a promise to my self that I must improve that badly-looking code.
…. but wait, it’s just a badly-looking code. It had taken me another few weeks to discover it isn’t so important to improve that piece of code, it really doesn’t matter right now. There are plenty of places to improve code base of the project and so many users don’t care about that – UIBean doesn’t exist for them.
The current UIBean implementation do the job, it isn’t pretty or easy to maintain, but right now there is no one for whom it is important. No one complains about it. Some day I’ll refactor the code of UIBean class but today isn’t that day.
The conclusion is the same as for code optimization, you shouldn’t optimize too early, so you shouldn’t improve too early. Don’t throw everything and try to improve some bandwagonhost vps not-important part of your project. Don’t trust metrics by heart, they can lie to you, try to figure out what they mean in context of your knowledge of the project. They aren’t a silver bullet.
Today’s day brings to me another newsletter from web site and gave me answer to important question: the shortest connection between two points is …