JProfiler Get rid of your performance problems and memory leaks! Modern Garbage Collection Tuning Java Performance Training Courses COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs Java Performance Tuning, 2nd ed The classic and most comprehensive book on tuning Java Java Performance Tuning Newsletter Your source of Java performance news. Subscribe now! Enter email: Training online Threading Essentials course JProfiler Get rid of your performance problems and memory leaks!

Back to newsletter 117 contents | All Javva's articles

What is the cost of your code? Have you ever worked that out? Mostly any such calculation would be an average, you count the number of statements or LOCs, work out how much you are paying the developers to produce that, and you have an estimate. I'm talking about code actually produced, not estimating how much it might cost if it were produced in the future. But what about maintenance? That calculation only works for greenfield code, maintenance is more about correcting faulty code, or code that is being exposed to situations that it wasn't originally designed for. In this case maybe you would calculate the cost by the number of changed lines instead of the number of new lines. But extend this slightly more, often you are generating new code on an old system, but the new code will retire some old code, so you need to factor that in too to your calculation.

I had a look around the net and as you would expect the cost per line of code varies hugely, there are so many different factors to consider. But a figure of $20/LOC seemed to be a consensus outcome of looking at a number of different large multi-developer projects. So I was fascinated to be able to cost a particular line recently where I am working.

It was a one statement, basically it said if (x==null) log("x is about to throw an NPE"). The line immediately following this line invoked a method on x, i.e. it said x.doSomething().

Personally, I have no problem with this line. Sure it is pointless. I can think of numerous ways it could have got into the code - almost certainly when someone was debugging something. Yes, I appreciate the line adds no information at all, the NPE stack will have everything you need, assuming the stack isn't swallowed up somewhere further up. But then, when you are a performance tuner you come across so much code that is entirely unnecessary (maybe there was a need for it once, maybe it was over-engineered, maybe it was just inefficiently designed or implemented, etc.), the odd redundant line just doesn't really register. I tend to think in terms of overheads, and in this case one null test rarely has measurable overhead, and one extra log line when there is an NPE which is about to be logged also doesn't matter.

I digress. I am not talking about what I think, I was talking about the cost of a line of code. Now putting that line of code in, assume it was someone looking at a bug and he chucked it in, then as part of the overall bug fix it wouldn't have cost much - after all it probably took a few hours to fix the associated bug (whatever was allowing x to be null), but required other lines of code fixed somewhere else. And all that happened a long time ago.

But now another developer looking at the code notices the line. He sends out an email to the company development community - a couple of hundred developers, asking "is there a reason for this line of code?". This generates a robust exchange of emails, I counted 37 on the "reply all" circuit, and from overhearing people talking there were a few side discussions too. The initial line is commented on, and the reasons for why it might be there, the benefits and the inefficiencies, the benefits of having clean code versus the time taken to clean up code, further side discussions on design, implementation, coding best practices, and so on. There was nothing wrong with the robust discussions, the many tips and points that the email generated - it happens all the time in our opinionated and knowledgeable community, and we all learn from it, especially in a company environment where the noise tends to be kept down because you know each other. So all good. But it allowed me to measure the cost of this line of code. I can estimate the average cost of the hourly pay of the developers, I can estimate how much time they spent reading, thinking, writing about the emails, and discussing it all offline (a good few chats and laughs around the coffee machine). Adding it all up, I came to a figure of $300.

That's one expensive line of code.

BCNU - Javva The Hutt. (LinkedIn profile http://www.linkedin.com/in/javathehutt feel free to connect me, my email as javva@ this java performance domain).

Back to newsletter 117 contents