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.

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

My lifetime chance

I had my lifetime chance, but I turned it down

In the beginning of this summer I was offered a dream job, but I turned it down and I will tell you why.

What's a dream job

A dream job is something very unique, you and I have probably different ideas what that would be. What we do have in common is that it is something that we really want to have. It might not exist, or we are not aware if it does, or it exist very few of them. Probably its something that is really hard to get.

Something else that also could be said about a dream job, is that it gives something to you. It could be lot of money, a carer opportunity, working with latest technology or  something really interesting and motivating. It could also be so that it requires sacrifice from us that we are not willing to give.  

The first contact

In the beginning of the summer I was contacted by a recruitment firm and they were interested in my profile for a potential job position. This wasn't the first time I have been contacted, but I am a open person, so I always listen.  

-Wow! Is this for true? Does a such job exist?  Does they really want me?  

That was my first thoughts.  

Note: I have a good job with great colleagues and benefits, so I am not desperate looking for a new job, but I always listen if someone offering me something better. The "worst thing" that can happen is that I have to practice to market myself.

I discussed the offering with my family if I should proceed or not, mostly because it would require time away from my family and it was a international company without a office in Sweden (the purpose was to start up a business in Sweden). I decided to proceed. It sounded as a dream job and a lifetime chance. I updated my CV, mailed it to the recruitment firm and then the process started.  

The interview process

During one and a half month there were several interviews over phone and Skype, with the recruitment firm, potential manager and colleague and they all went well. Afterwards it was time for a test were my technical skills should be verified. I did really well (has I been told). It felt great and I actually started to believe that this was something for me, but also I was something for them.  

Because this company don't have any office in Sweden and I am full aware of differences in cultures, I raised some questions early, so we (I and them) could stop this process early if necessary. It would later show that the differences were not understood well enough.  

After all phone interviews and the test, it was time for the first face to face meeting in a hotel room in Copenhagen. The interview process started to reach its end. If this meeting went well it would then mostly be about formal issues if we would come to an agreement or not. I went to the meeting, it was a tuff meeting. They throw questions at me and I tried to answer them as good as I could. There were no room for rest and I was under hard pressure. In the end of the meeting there were room for me to ask questions. My focus was to be calm and answer honestly on all questions. If this job change should be successful, it must be a win-win situation.

I believe the meeting went well and I had probably proceed to the next step if it not were for something one of the interviewer said. I won't go into details but it concerns something really important in our culture and that was one of the the things I raised early during the process. This was the end.

Summary

Why am I telling you about this? When you do business with other people and they have different culture, you have to do your home work. You don't need to understand the other culture, but you must accept there is a difference, words can have different meaning and what you value in life is not necessarily the same. If you do your home work well, you will have a better chance to be successful in your business.  

About the job role, I am convinced it was perfect for me (and vice versa) and it offered lot of new challenges and possibilities. Unfortunately there was a culture collision and I felt very sad to call back and say no. I got to taste of something that could have been my dream job.

Now life consists of so much more than work achievements and I feel strong and proud of myself that I turned the offering down. Even if I didn't got this job, I have learned a lot.

• I got to practice to market myself
• I learned more about international interview process
• I learned more about the importance of culture awareness
• I learned more about another company
• and the best part, I learned more about myself

Course reflections

Last week I hold my second internal company course, Coding standards and behaviors, with focus to make my colleagues more interested into the topic. In the end all attended had to give feedback on the course and it resulted in the image below.

Feedback from the course Coding standards and behaviors

And now some reflections...

The target group

The course was open for all who was interested to learn more about the topic. In the invitation I had included an agenda to reach the right target better. I do believe I did well with the invitation. I don't only want to have geeks in the audience.  I do know that the discussion get better when people have different backgrounds. Also, I get better feedback.

My preparations

I started with a pre-study about the course content 2 months before the actual presentation date and started preparing the PowerPoint presentation about 1,5 week ahead. During the first phase I tried to read and collect as much information as possible, e.g. documents, books and blogs. I tried to summaries everything in headings. The second and last phase was about sorting the important and most interesting parts into slides. This is the hard bit!

What I aimed for

The main focus was to make people more interested in writing safer code and using coding standards and coding style, as a help to achieve it. Also by being aware about strange behaviors (undefined and unspecified) in language, like C, are also helpful. I tried to have simple example but I also added a few more complex, with purpose to show how hard it is to understand some parts.

Was it appreciated?

This one is the tricky part, but I do believe it was based on three facts:

1. All the seats were filled the same day the course as announced
2. The picture above shove that most of the attendees marked it above average on the interest scale
3. I received some personal and positive feedback afterwards.

Because the target group was quit wide I expected some feedback were people thought it be not so interested or it wasn’t what I had expected. The questions are:

• Can I do anything about it?
  Yes, by a) more précised target group and b) more detailed agenda.
• Should I do anything about it?
  It depends. If I am asked to hold the same course once more I will probably update the course description. But in the same time I want to keep the content a little bit open, especially if it’s something new I have to do research in.

Why do I teach?

Because it’s fun! I also learn more about the subject when I need to teach it.

Some tips if you want to hold a presentation

If you haven’t held a presentation before, you should now that creating good informative slides take really long time. First of all you have to define two things:

1. What is your story?
2. How is the target?

The first one is a help for planning. Do you know everything already today? Or do you have to do a lot of research first? It also helps you to stick to the plan. The second one decides on what technical level you should have on your presentation. Is it a Java for dummies or advance cache optimization. If the target group is more senior, you should be prepared for trickier questions. They can even tell you that you are wrong :-)

When you finally start with the art of creating slides, here are some general tips:

• Stick to short and few sentences
• Pictures are nice
• Verify your colors on a project screen.
• Font size. can the person in the back read it?
• Style consistency. The layout should be similar between the slides
• Add questions (as a reminder for you to wake up the audience:-) )
• Avoid preaching
• Add some extra energy on the start end slide

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!

Keep it small

It has been written about before. Its nothing new. Yet it is so difficult to keep the code small and I am talking about functions, files and modules.

Every day I see functions that are so large that its more or less impossible to understand what it does. Writing unit test takes more time than writing the acutal product code. Metrics like cyclomatic complexity and fan-in/fan-out is so high you get terrified. The code speak:

- Don’t touch me! You are on a mine field!

Why is it so hard to write good code?

We can’t blaim lack of tools because there are a dozens of the them out ther. Some of them are even free!

I belive its about people and culture. If you are working in a enviroment were people only focus on delivery, the quick and dirty solution will often be the way forward. And often it works fine. Its first when someone new looks at the code the problems gets visible. If same people work with the same code all the time, the problem gets hidden, because they have grown togehter with the code and knew the history behind every statement.

By writing small functions, your code gets easier to maintain, understand and modify.
By writing small functions, it gets easier to write tests, which is you saftey net tomorrow.
By writing small functions, its easier to reuse code and keeps the footprint smaller.
By writing small functions, the are less bugs and they are easier to find.

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