Black Belt – Now you know what you don’t know

A story from my life:

Once when I was young and was training Ju-Jutsu, receiving a black belt was my goal. Probably I believed I would be like Bruce Lee (I still hope :-)) because you can’t be better than him….or?Several years later during one of my workouts, I was discussing with my master about different martial art stiles and he told me something wise: You start your journey by choosing a path (stile) and follow that until you reach a master wisdom (black belt). Only then you are ready to look at other paths (stiles) and understand what distinguishes them apart.

I am convinced that you can apply this on most of the skills you learn. If you take programming as an example, you start learning one programming language and after several years of experience you are start looking and using other languages. Why? Most of the case you see benefits in using another programming language for a particular task. By learning other languages you also learn more about your first language.

For me learning is fundamental part of my life, both in work and in private. I try to absorb as much knowledge as I ever can and I found out that using different source and forums gives you best return.

Books

+ Its very practical. You can take it with you and read it any were.
+ The language is very good. A book is edited several times before it’s printed.
+ Quality is good. The quality needs to be good enough for a publisher to publish it.
- It cost money. Not much, but still you have to pay for it.
- It you want the latest “stuff” you will not find it here. It normally takes one to several years before something new is printed.
- Its one way learning. You “can’t” ask the writer any question.

Blogs/forums

+ Extremely practical. You have it in your smart phone in your right pocket. You can access it any were anytime.
+ It free. Well, you have to pay your mobile subscription.
+ You get the latest stuff. You can follow discussions and ask questions.
- The language doesn’t need to be correct. At best the blogger used some grammar tool and removed the worst part (like me :-)).
- How do you know that the content is true? You don’t! You can assume by how the blogger is and from potential comments.

Webinar/YouTube

+ Most of them are free. For webinar you are often requested to register before you can attend the webinar.
+ Often it comes together with a PowerPoint presentation with rich information.
- Limited access. You need good internet bandwidth.
- Noise. You need to isolated sound around you, either by earphones or go to some silent place.

People (colleges / CoPs)

+ Its free.
+ You can ask questions and have deeper discussions. You don’t have to wait for an answer. It’s easier to ask “stupid” questions if you don’t understand.
+ You can draw sketches it make the learning process easier.
+ You can create improve your network for future needs.
- Limited access. Hopefully you only spend round 8 hours a day with your colleges.

Instructor led course/conferences

+ The instructor has high competence in the subject.
+ The instructor is hopefully good in education and has good material.
+ At conferences you can connect with new people and sharing experience.
+ You can ask questions if you don’t understand.
- Cost a lot of money. Often your company pays for it.
- The number of courses/conferences are limited, both in content and geographical.

Don’t forget that you can do all mentioned parts above yourself.

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 - Interest of improvement

In previous post I discussed if it's possible to improve the quality and the conclusion was: it is, which is not surprising. I also divided software quality into two groups, functional and none-functional, to make software quality easier to reason about (which it isn't).

In this post  and the next I will discuss what is required to improve the quality and two parts that are necessary are:

• interest of improvement
• knowledge of you current quality

Interest of improvement

Before you can take any actions to improvement, there must exist a interest of improvement. Normally a company wants good quality on it's products so the customer are satisfied and continues to buy/recommend the product. You want:

• the response time of your web browser to be than your competitors, else users will abandon you product.
• to be able to test the product continuously in a reliable way to changes can be made earlier
• the code to be clean and easy to work with, to make it possible to add new feature easier.

But all this will not happened by itself. It’s the people in your company that will make it happened. You need employee's that are like sports people that always seek ways to improvement. So how do you get them? Either you have been lucky with you recruitment or you have a company culture that endorse caring about quality and sharing knowledge. Geoff Schaadt has written an excellent post about How to make your employees care about quality. He writes:
“how do you make your employees care about anything? You can’t make them.”

It means that you can only create a culture that makes people care.

Different people
People are different and have different interest. We want people in our company and teams to be different, because it’s from their discussions innovations are started.
We want different people that are interested to learn more and a company that creates a caring culture.


In the next part I will continue with knowledge of your current 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.