Making code cleaner can result in a angry phone call

You have just released a update of your product. It includes more or less nothing, just a minor bug fix and cleaner code. Tomorrow it will reached 10 million smartphone users. The next day your phone is calling, one hour before it normally wakes you up. Its your boss!

I recently read a blog post by Erik Dietrich about legacy code (http://www.daedtech.com/intro-to-unit-testing-5-invading-legacy-code-in-the-name-of-testability) and how refactoring can help you to make it testable. The articel (and it’s serie) is very vell written, and as he writes in a comment he aims for novices. With this post I want to change focus from correctnes to performance.

Refactoring

In several books and blogs you can read about clean code, reduce cymclomatic complexity, duplicate code and how refactoring can help you. And that works!

If its legacy code there will most of the time be a comment saying something that it shall be done with caution and you have to write unit tests before. Thats also great!

But what you don’t read (or very rare) is that you should profile the code before and after to spot any performance differences. Why? Consider this:

What do you think happens if you refactor a code snippet, that is used in one of your most CPU intense part?

It will take longer time!

A quick person will say that he will inline that code, either by function of through compiler flag.

Well...that sound good, but are you allowed to change a compiler flag?

And if it’s already there, do you know how large functions that will be inlined? Maybe a software architecture has decided he wants to have control of what is allowed to inline for several causes. It could be: controling final binary size, debugging issues or something else.

Jumping around takes time

What happens when you have refactored a code snippet, is making a jump to another place and do something there. This jump takes time. If you need to bring some parameters to this function, you have to store them in a register. And also the return adress. This takes time. If you need variables in the refactored function, you need to allocate memory for those. This takes time. And you have to jump back when you are finnished. And this takes time.

This itself isn’t a problem, but if it’s done milions of time in a part that is already highly loaded, it can be a problem.

A angry phone call

Even if you as a developer thinks the code looks cleaner and is easier to understand, you also need to understand the harware and your customer. Here is some senarios:

• There might be requirements about how long time a task can take.
• There might be limitation on how much of the cpu can be used before a wathdog generates an alarm, or in worst case reboots your system.
• There might be a customer starting asking questions why his system use more CPU load after your software update.

Learning to ride a bike is easy, the hard part is to ride in traffic jam

Software Quality - Knowledge of you current quality

In this post I will continue discuss what is needed before any actions can be taken to improvement and I will focus on knowledge of your current quality.

To receive this knowledge, data must be collected and analyzed, and it can be done in many different ways. I will discuss some of them here.

Collect data from users

Users are those how use your product in any phase, from using the actual code to end user of the final product.

• What does the software developer think about the code? Is it easy to read? Is it easy to modify? And so on.
• What do the testers think about the product?  What's their feeling? Is it well tested?
• And finally, is the end user satisfied?

A story:
Once when I developed a user interface to a customer, I was really satisfied with it. You could almost do everything from one screen. The error handling was rock solid. The color contrast was chosen well. Then one day it was time to show it to the end user. We installed the product in the customer's vehicle and went out to the forest. The computer screen was shaking all the time during the demo and my choice of small buttons, edit fields and drop down boxes really sucked! There was no chance you could hit the right button.

So....what did I miss? I didn't know enough about the environment it should be used in (I had only tested it in a car that was parked outside the office). This was in my early career and the project was 100% waterfall. RUP was not yet hot (if it ever was)

Lesson learned: make sure you know your customer. Physical meetings/demo are extremely valuable.

Test results

How did the tests went? Was there lot of errors found? Test coverage, is it good enough? Was the test performed under good conditions or was the test phase decreased due to late deliveries? Any lose ends? 
This is a combination of measurable results (PASS and FAIL) and a feeling about the whole test scope.  Yes, I feel very comfortable with the test results or Well..we didn't had time to test this special case X, but it happens extremely rarely...

Metric results

Today, the range of tools to measure code quality are enormous, and it's more about taste and platform what is chosed. Some of them measures :

• Static code analysis
• Memory profiling
• Cache misses
• Cyclomatic complexity
• Coupling

All these gives a indication about the none-functional quality and in some sense the functional quality. I want to point out that metrics needs to be put in context to be useful. A single “bad” value dosen’t says that the quality is low.

Summary

The end user might don't care if the code is extremely tight coupled, but it will effect him when he wants an update fast. The best knowledge of your current quality is received through gathering information from several sources continuously.

This was the last post about what is needed before any actions can be made for improvement. The next coming posts will be about what can we do to improve the quality.