The Importance of Removing Impediments

What is an impediment?

I do not actually know, because it is such a difficult word. But what I do know is that the time I have to wait for a build to finish is not productive for me. It even costs the customer money. This is for me an impediment.

If the time it takes to build the application is too long it starts imposing challenges on me. When it takes too long I do not want to build too often.. If i do not build too often, the tests is not run often and I will not commit code very often. This leads to finding bugs much later than I normally would have if I had ran the build more often. So I use more time fixing the bug because I have produced much more code since i made the bug somewhere in the huge codebase.

Did you get it? If not let's run som numbers on it instead. Lets say that it takes 8 minutes to build and that you use most of the resources on your computer while doing it. The best you do is drink a cup of coffee or read up on some documentation while you wait. Let's say you do the cup of coffee and wait for 8 minutes to see if the tests fail or pass. Its not only you in the project, but ten people that does the same thing. We all do it 2 times a day, because it takes so much time and we dont like coffee that much. We do it every day of course. So the numbers become:

8 minutes x 2 times x 10 people x 5 days = 800 minutes = 13.3 hours

Not only does it take you 16 minutes a day to build, but it takes the whole project 13.3 hours to build a week. Let us then say that you work 40 weeks a year and your project runs for 2 years.

13.3 hours x 80 weeks = 1064 hours

So during the lifespan of your project it has been used 1064 hours for running the build. What if those hours could have been used to implement more functionality because you have so much good code that your build did not take any noticable time at all. Imagine that the cost where 1000 NOK per hour that would amount to 1064000 NOK used on build/coffee during the project.

1064 hours x 1000 NOK = 1064000 NOK

That is not just an impediment to me, but to the customer. Build time matters! So remove those impediments while you still have time left to do so. If you are not busy building the application of course...

Smidig 2009: Påmeldingen er åpnet

Påmeldingen er åpnet for Smidig konferansen! Jeg tror årets konferanse kommer til å være like fantastisk lærerik som i fjor!

Smidig på twitter
http://smidig2009.no

Do the rights things at the right time

Yesterday I attended the oslo xp-meetup with an expectation of hearing some inspiring thoughts on software developing using xp and agile techniques. What I did get was a very good presentation of lean startups and how to do the things that matter the most at the right time (like in xp and lean).

It was Kent Beck who presented his new ideas on what he defined as "the flight of a startup". The analogy used the different phases an aeroplane is in before it's cruising at 30.000 feet.
1. taxi
2. takeoff
3. climb
4. cruise

Kent emphasized the need to be careful about spending cash (if it was limited) in the taxi and takeoff phase. The most important issue that I noticed from my perspective was during takeoff where you actually remove functionality thats not being used because you want to get better scalability. I'd call it reduce the risk of cluttering up your good ideas with the bad ones. But as Kent said, removing features are not easy and often we tend to let them stay in there. Another interesting statement from the re-inventor of TDD was that you should ALWAYS track usage in you applications.

I will start to do just that. I will start putting in functionality for tracking usage in my applications. This to be able to get actual feedback on what is being used in the application and what is just waste. Then we have an actual map of the used functionality and with this we can start doing some real work. Removing functionality thats not being used will be removing code that slow us down.

If he is doing this talk somewhere near you, take the trip and listen in on the ideas. It's good stuff.
Another very nice post on startups here

I have a brain!

A friend of mine is writing his masterthesis on frequences in an MR machine. This machine scans your brain. Yesterday he asked me to help him out with his last scan for his thesis.

Do you have a brain? Use it! :)

Communication and Context

What about it? We all know that communication is important and most of us also know that the context of where or what the communication is about is just as important.

Consider some of the pictures i took while in China. They show a will to communicate with you as an english speaker, but they do not always make sense. Anyway here are a few of them:


The next one is harder to understand the meaning of.. Mingtien means tomorrow, so maybe they mean tomorrows language café? or language coffee?




Think about the context when you communicate with someone. They might not understand what you are trying to communicate even though they understand the language.

Motivation and Attitude

Most of our life we stick to some basic values. Sometimes we do things we would usually not do because someone or something motivated us to do so. Its the attitude to be open to change that is one of our most important traits.

It is time to start motivating for change. Its your life and it should be you who decide what you want to do with it.

Have a look at this movie from the HOME project. It speaks of motivation for change on a global scale.

http://www.youtube.com/homeproject

Mockups, what is it good for?

Some people like to think in terms of text and others prefer diagrams or drawings. I am a huge fan of drawings. But I prefer drawings that do not draw too much attention to details that are not important in the context. When looking through some old favourite blogs I found this post about the level of detail in a demo. Its a great summary of what not to do when you want to show ideas and get creative feedback.

And guess what? I've been in a discussion with someone about this before. In the discussion someone mentioned a tool that gave you the possibility to make mockups fairly quick with a look of a sketch. I've now tested and even bought the tool for my self to use at work when making backlog elements for further specification. Since my drawing skills are rather lacking the tool helps me to make some really nice sketches. The tool (Balsamiq) is really easy to learn and I use less than 5 minutes on the sketch below.

The level of detail enables us to communicate on the content instead of the details of the dialog window like colors and text size.

And as Kathy mentioned at CPU; it does not give the customer the idea that we are almost done with implementing it, because it looks almost finished on the openoffice slide!

This is because the details that really doesn't matter right now is not there. I would go as far as to say that this is good enough for specification purposes in most cases. It will get changed later in the development iteration anyway, when the customer sees the real screen during development he will then ask for new or altered functionality. The important part here is that this sketch often contains enough information to start developing the desired functionality. This removes the waste of making too much spesification. And did I say that this sketch is so much easier to change than a photoshop picture?