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.

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.