Same shit, different color

Same shit

Today I did a reflection after reading a blog post about howto deal with legacy code and the thing was, it didn't had any new information or insight. It was the same story:

First a introduction that try to visualize how bad it is:
...inherit someone else code....hard to understand.....no tests....outdated documentation....original coder has left the company....

Then come the solution...or should I said suggested practices:
...Pair programming.....TDD....Continuous Integration....refactoring.....loosely coupled code...customer value....

How many times have I read a book, blog post or watch a webcast with the same message? Thousands? I don't know... to many anyway.

Differences

So are they really the same? Isn't there anything that differentiate them? Yes it is. The writer!

The writer writes it with her own words and experiences. That's about it. The same list with the same practies. If your lucky you find some context specific that match your own enviroment. 

Isn't this said? You waste your time reading the same shit but with different color? I'm not better than you. I have done it. I have even written about it.

The question you should ask yourself is why is she writing about it?

She has made a journey from not knowing to knowing more (and knowing she knows more), and know she wan't to tell the world. Yes, because she has read somewhere (probably some Software Craftmanship writers blog or book), that to improve your skills further you should spread what you have learned, and one way is to write a blog.

There is nothing wrong with that.

But...what I find interesting is the journey itself, and that you rarely find written about. I would be more interested (it´s ok to not agree with me :-) ) in reading about:

• What practies did you try?
• What did you start with?
• Which ones were difficault to adopt?
• How did you deal with the difficulties?
• Which ones were easy? Why?
• How bumpy was your trip?
• When do you fall back to old habits? (we all do that sometimes)
• Whats your next step?
• ... 

The list with practies is the same for everyone, it's the journey that is unique. It's about changing your behavior.

In the future I will only write a blog post when I have something to tell.

Learning day

Today my company arranged a Learning day in the format World Café Method which was really positive. In short all employees gathered together during the afternoon for discuss different topics in small groups. Every topic was introduced with a lightning talk followed with intense discussion's and sketching (every table were prepared with paper, pencils and questions). The idae to time box all sessions made everyone focus on what they wanted to say or/and ask. There was lot of energy in the discussions....really positive.

So why do I even write about this? The idea is nothing new. I guess it's more popular today when all companies goes agile. I will tell you what I though made this something extra.

Findings

We wrote down on the table what we discussed and in the end of every session we were asked for what findings we had done. Like a really short retrospective. If I only had discussed and afterwards went back to my desk, it would have been like a long coffee break.

People

I meet new people in my company. Instead of sit with my colleagues, I put myself outside my comfort zone and sat down with colleagues that work with something else in another department, like project managers, configuration manager, line manager, etc. I already know what my closest colleagues think and would say; because we see the same side of the coin.

Cache usage - Why do I have to care?

Last fall I held a internal course at my company with the title Coding with performance and quality in mind. In this post I will write about one part in that course, Cache usage, and I will try to answer the questions why do you have to care?

Some of you might say:
- Hey, you! This is nothing new. If I Google “memory cache performance” I get 55.800.000 hits.”
 Why another post?

Well, I will not write another post with lot of details. There are already lot of great post with it already (Google is your friend). I am writing this post for you who are a software developer but don’t know some much about hardware.

The big conclusion

You want the right data inside your cache at the right time!

- That sounds good!

But what is a cache?

In your computer, smartphone or some other device, you have main memory, normally called RAM, and you have cache which is a superfast memory. Some parts of the cache is located in the same chip as the CPU so it located really close to the CPU and makes the access quick (se figure below).




Details:  Cache can be divided in L1, L2 and L3 but also TLB, I - Cache and D- Cache (check the links in the end for geek info.

- Now I know what it is, but

How is it used?

Data that the CPU needs now or very soon is read from the main memory (or a cache further away) into the cache so it can be accessed really quickly. It takes longer time if the CPU needs to go all the way over the data bus and copy it every time before the CPU can use it. It might need it again very soon and therefore it is temporary stored in the cache.

But there are limitations! The cache is limited in size. For instance my Samsung Galaxy SIII has one L1 cache for data usage one for each core. Another limitation is that it can only copy chunks of data, cache lines, which typically has a size of 32, 64 and 128 bytes.

- So whats the problem? Just copy what you need!

Before the CPU starts copy data from the main memory to the cache, it first checks if it’s already exists in the cache. If it doesn’t, it is called cache miss and the CPU needs to work more, which you don’t wan’t.

- Ok, I understand what you mean. It’s good to have some understanding what limitations the hardware have, but

How do I minimize cache misses?

You organize your data after usage! Imagine you have a data struct ,as the one below, and you what to search for some persons id. The size of of one cache line is limited to 32 bytes.

struct person
{
 unsigned int id;
 char data[40];
 struct person *pNext;
}
...

while (ptr->id != magicId)
{
 ptr = ptr->pNext;
}

When the CPU copy one line, it will contain the id and a part of the first person due the the size of the cache line. If the first persons id doesn’t match, it will continue to search by updating the ptr pointer. The problem is that this information is not inside the cache. The CPU needs to copy that information from the main memory into the cache. This is a typically cache miss. A better solution would be to move the most common used data close to each other as below

struct person
{
 unsigned int id;
 struct person *pNext;
 char data[40];
}

- So you are saying that I shall re-organize all my data structs now?

No, first you analyse your code in a profiler and find your hot spots. Cache misses might not be your biggest problem but it’s good to understand if one of your loops turns to to be a hot spot.

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.

Bigger retrospective - my first time

Finally I did it! I had my first bigger/higher retrospective. It wasn’t perfect, but I learned a lot.

In April last year I wrote a post on the internal forum at my company about Retrospective on a higher level, where I discussed that we missed some form of finalizing, round-up of each project. A planned time were all developers, testers, architecture's and manager sit together a put there view on how they thought it went. A possibility to visualize choices that resulted in good and bad,  from which we can learn from.

Why bigger?

Running retrospectives after each sprint is a great way to reflect after small changes. Maybe your team has tried pair programming or TDD for a sprint and then its perfect during the sprint retrospective to reflect over what everyone thought about it.


But during a project for several months or years it happens a liitle bit more:

• Several teams are working with different parts and the code changes a lot.
• There will be lot of communication ans synchronization  between the teams and managers.
• New way of working like remote-pair-programming.
• New tools are introduced .
• People leave the company and new people start.

This list can be made long. My point is that some changes a three week sprint is not enough to make reflection from. You need more input data to spot the delta.

My frirst trial

After I have read Joakim Sunden’s post, Running big retrospective at Spotify I finally moved from just talking about it to actually doing it. And it was great!

What I did was:

• I invited all how has been involved during a 6 month period.
• Booked a conference room for a hole afternoon.
• Prepared me well with agenda, post it notes, etc.
• No computer!
• Happy mode curve.

As I mentioned in the beginning the result wasn’t perfect, but it was ok. Unfortunately only developers attended, which only give one side of the project. What I missed was that several invited was invited as optional and not required. Yes, some people actually take notice of this.

The good part was I really believe everyone who was there really enjoyed it. One important part, that I also put extra care to, was that everyone should participate. It’s very common that there are only one or two who speaks all the time (some smart people sit silent in the back and don’t care about agile and processes). By letting everyone write down what they did during the gathering data phase, and put them on a timeline on the whiteboard afterwords, everyone got a chance to share there thoughts and feelings.

Another good factor was the happy mode curve. Everyone was asked to draw a “sinus curve” describing what they felt for the task during the hole project. Is was a clear correlation between the curve and “how well” the project went.

Another the last success factor was to not bring any computer. We did it truly kindergarten way. We used pencil and paper.

I will do it again!

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 - 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.