How much shall I refactor?

"disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior"

-       Martin Fowler

Usually refactoring is initialized by code smell, a piece of code that does what I shall do, but doesn’t look “good”. But it can be initialized by several other reasons and some of them are:

Readability – a code part is really complex and the context it’s in would be easier to understand if it’s replaced with a function. For example, calculating the mean value of an array:

Testability – by replace some part of the code with a function, writing test gets so much easier to do. The code you want to test is depending on a previous part and you need to control the output from it.

Reusability – by extracting and generalize some part of the code, it can be re-used in several other parts.

So whats the point with this post? What I listed above is nothing new. It has been said and written of thousands of people.

A few days ago I watched a video from Öredev with Oren Eini, Hard Coding - A Design Approach. The most interesting he points out is that after Gang Of Four released  Design Patterns, we have refactored and abstract code into so many layers that the code gets more complex and difficult to understand. Without good documentation and/or someone describing to you what the code actually does, time-to-understand-was-this-code-does has increased.

I don’t say that Design Patterns are bad. I like them. I use them. I do believe that they should be used with caution.

Back to the first question, how much shall I refactor? 

As long as the code gets easier to read, test and modify, you should always consider refactoring, but check that your performance don't gets worse.

KISS – Keep It Simple, Stupid!

Why I need SCA

I am a big fan of Static Code Analysis (SCA) because I learn to produce better code!

I have worked more than 10 years as a professional embedded software developer in several different environments and with different platforms and languages, and I believe I can write decent code.

But you know what, I can’t!!

I have not had a single week during my life that I have delivered perfect code with no errors. The weired part is that I even teach my colleagues how to write better code and write this blog about this subject. So why is it so hard to avoid those tiny, tiny errors. Well because we are humans and not machines. Yeap!! You read right.

If I were a machine it would be possible for me to think on every thing that I need to think on. Psychologist says that the human mind can hold 7 +/- 2 things at the time. If we try to remember more we starting to forget. I believe that you can apply that on writing code. Each software developer focus on different things depending on her/his previous experiences. For me, I usually focus on these things:

• have I initialized parameters?
• can I refactor the code?
• have I covered the new code with unit tests?
• can someone else understand it?
• is this code from a performance perspective (like cache and memory usage)

that was five. Maybe I missed something, but you I am human!

Normally after I have written some code and run my SCA and it founds a error or warning, quite often I say to myself. ahhhh I missed that. Sloppy of me! But sometimes it indicates something new and in my mind goes:

Stop! This one is new! Lets do som digging. 

What I don't do is fix i right away and rerun the SCA.. First I make sure I understand the problem and then I fix it. Through that I always learn something new and maybe I remember seven things to check for instead of 5 next time.

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.

Software Quality - Can we improve it

Software Quality is something that everybody wants to be good. So what is good? And if it’s not good, how do we reach to that point? And if it is good, can it be any better?
Let’s start with some basics about software quality.

Basics

Software quality can be described as: how well we meet some requirements. It is often related to a business value. Is the customer satisfied with the product the paid for?
Customers are often people and what satisfies him will differ, therefore requirements for the product are well defined. The result is some form of minimum quality for the product that both the customer is satisfied with and the product developer can fulfill.

Requirements can be divided in two parts:

• functional requirements 
• non-functional requirements

Functional requirements refer to the specification, the requirements the customer and product developer has agreed to. They well defined. They can be measured and verified. If the quality is bad, the product developer won’t get paid.

Non-functional requirements refer to quality that is not directly visible to the customer, like maintainability and efficiency. Compared to functional requirements, these are “soft”. These are often results from architectural decisions and developers coding practices. Measurement of these requirements can be difficult and needs to put in context to give a meaningful value. 

What is good?

Back to the second question, what is good? Maybe it’s easier to define the opposite. If something is good, it can also be “non-good”. We can call it bad. If the quality is bad, it does not behave as we are expecting. The requirements are not fulfill. The customer is not satisfied.
If the requirements instead are fulfill, then the customer should be satisfied of the quality. We can then define that if we meet the quality for something we have agreed on then it is good! 

Let’s stop!

What about non-functional requirements? What if the code

• has extremely long source code files
• has functions that are pages long
• is really hard to understand
• only a part of it are covered with tests
• is so tight coupled that even dynamite won’t separate it
• needs extremely much memory and cpu

Can the customer be satisfied even if the internal structure is a mess?

Yes it can!

The solution can be to use more hardware or increase the development time with a factor X. It won’t be cheep but the customer will be satisfied. 

Or maybe there is another solution... 

If it’s not good, how do we reach to that point?

For functional requirements it’s easier to reach good quality because they have been agreed on with the customer. They are on paper. They can be measured. 
Non-functional requirements are more trickier because the limit for “good” is something we state our self. We don’t agree with the customer who the product shall look inside. It more about how much work are we willing to put down for a product?

If it's good, can it be any better?

I just claimed that the customer can be satisfied and the functional requirements are fulfill, even if the internal structure is a mess. He will probably not be overwhelmed. The good parts will weight more than the bad parts, as specified in the requirements.
But what if the internal structure (code) would be

• easy to understand
• easy to change
• easy to test
• cpu and memory efficient

It sounds nice. It sounds even better than good! No extra hardware needed. The development time is probably much lover. It open ups possibilities to change the requirements earlier in the development cycle if the customer is not satisfied. The staff are probably also happier because its more easier and more “fun” to work with the product. In the end the customer will be more than satisfied.

Can we improve it?

Back to the end question, software quality - can we improve it?

Yes we can! 

By having good quality on the internal structure the product cost will decrease and improvements of the functional requirements are easier to implement.