Hannametoden – slik løser du Rubik’s kube (som vist på TV2)

Her er en enkel beskrivelse på hvordan man løser Rubik’s kube (PDF). Jeg skrev den som en lærebok til min datter Hanna da hun var 8 år gammel – derav navnet Hannametoden. Det er en forenklet versjon av en metode som brukes av de beste i verden (CFOP / Fridrich). Hun brukte et par dager på å lære seg å løse kuben på egen hånd basert på denne “oppskriften”. Vi besøkte “God Morgen Norge” på TV2 den 17. Februar 2012 hvor blant annet denne metoden ble presentert (artikkel).

English summary: this is a very simple description on how to solve the Rubik’s cube. I wrote it to my then 8 year old daughter – hence the name of the method. It is a simiplified version and a strict subset of the method used by the best cubers in the world. It is in Norwegian, but since it is a visual guide you might enjoy it anyway. Click the PDF link above.

Solid C++ Code by Example

Sometimes I see code that is perfectly OK according to the definition of the language but which is flawed because it breaks too many established idioms and conventions of the language. I just gave a 90 minute workshop about Solid C++ Code at the ACCU 2010 conference in Oxford.

When discussing solid code it is important to work on “real” problems, not just toy examples and coding katas because they lack the required complexity to make discussions interesting. So, as a preparation I had developed, from scratch, an NTLM Authentication Library (pal) that can be used by a client to do NTLM authentication when retrieving a protected webpage on an IIS server. Then I picked out a few files, the encoding and decoding of NTLM messages, and tried to write it as solid as possible after useful discussions with ACCU friends and some top coders within my company. Then I “doped” the code, I injected impurities and bad stuff into the code, to produce these handouts. At the ACCU talk/workshop the audience read through the “doped” code and came up with things that could be improved while I did online coding (in Emacs of course) fixing the issues as they popped up. With loads of solid C++ coders in the room, I think we found most of the issues worth caring about, and we ended up with something that can be considered to be solid C++, something that appears to have been developed by somebody who cares about high quality code. Here are the slides that I used to summarize our findings. Feel free to use these slides for whatever you want. Perhaps you would like to run a similar talk in your development team? Contact me if you want the complete source code for the authentication library, or if you want to discuss ideas for running a similar talk yourself. I plan to publish the code on githup soon – so stay tuned.

UPDATE June 2010: The PAL library is now published on github. A much improved slide set is also available on slideshare.

Hard Work Does Not Pay Off

As a programmer, you’ll find that working hard often does not pay off. You might fool yourself and a few colleagues into believing that you are contributing a lot to a project by spending long hours at the office. But the truth is that by working less, you might achieve more – sometimes much more. If you are trying to be focused and “productive” for more than 30 hours a week, you are probably working too hard. You should consider reducing your workload to become more effective and get more done.

This statement may seem counterintuitive and even controversial, but it is a direct consequence of the fact that programming and software development as a whole involve a continuous learning process. As you work on a project, you will understand more of the problem domain and, hopefully, find more effective ways of reaching the goal. To avoid wasted work, you must allow time to observe the effects of what you are doing, reflect on the things that you see, and change your behavior accordingly.

Professional programming is usually not like running hard for a few kilometers, where the goal can be seen at the end of a paved road. Most software projects are more like a long orienteering marathon. In the dark. With only a sketchy map as guidance. If you just set off in one direction, running as fast as you can, you might impress some, but you are not likely to succeed. You need to keep a sustainable pace, and you need to adjust the course when you learn more about where you are and where you are heading.

In addition, you always need to learn more about software development in general and programming techniques in particular. You probably need to read books, go to conferences, communicate with other professionals, experiment with new implementation techniques, and learn about powerful tools that simplify your job. As a professional programmer, you must keep yourself updated in your field of expertise — just as brain surgeons and pilots are expected to keep themselves up to date in their own fields of expertise. You need to spend evenings, weekends, and holidays educating yourself; therefore, you cannot spend your evenings, weekends, and holidays working overtime on your current project. Do you really expect brain surgeons to perform surgery 60 hours a week, or pilots to fly 60 hours a week? Of course not: preparation and education are an essential part of their profession.

Be focused on the project, contribute as much as you can by finding smart solutions, improve your skills, reflect on what you are doing, and adapt your behavior. Avoid embarrassing yourself, and our profession, by behaving like a hamster in a cage spinning the wheel. As a professional programmer, you should know that trying to be focused and “productive” 60 hours a week is not a sensible thing to do. Act like a professional: prepare, effect, observe, reflect, and change.

[This is a reprint of a chapter that I wrote for the newly released O'Reilly book 97 Things Every Programmer Should Know]

Solving a Rubik’s cube in less than 60 seconds

A couple of months ago I bought a Rubik’s cube in a nearby shop and after reading some guides on the net I learned how to solve it. A few hours later I could solve it in about 4 minutes all by myself. After a few days of practice I was down to about 2 minutes, but it was difficult to see how I could improve much further using the beginners method I started out with. My cube and dexterity does not allow me to do more than about 2 moves per second so I realized that I had to reduce the number of moves, rather than speeding up my fingers. After reading several websites about speedsolving techniques I set my self a tough goal – to become a sub-60 cuber. I was determined to study and practice the art of solving the cube until I could solve a Rubik’s cube in less than 60 seconds on average.

I can now often solve it in less than 60 seconds, but I am not stable enough to call myself a sub-60 cuber yet, but I am very close. Give me a few more weeks (or months) and I will get there. While playing with the cube on the bus, at work, at home, in the pub, basically everywhere, all the time, I sometimes meet other geeks that want to learn how to solve the cube fast as well. So I thought I should write up a guide about how to get started.

If you do not know how to solve the cube you need to study one of a billion guides that are available on the net. Here is a beginner solution by Leyan Lo that I recommend. Once you can solve the cube without referring to a guide, you can start to read more advanced stuff. The ultimate guide is written by Jessica Fridrich, but it is not easy to read. I found CubeFreak by Shotaro Makisumi to be the most useful site out there.

After studying these sites, as well as hundreds of other sites and watching plenty of youtube videos, I have ended up with a simplified Fridrich method with a four-look last layer. Here is what I do to solve it in less than 60 seconds:

1. Solve the extended cross ~5 sec (always a white cross)
2. Solve the first two layers (F2L) ~30 sec (keep cross on bottom)
3. Orient the last layer edges ~5 sec (1 out of 3 algorithms)
4. Orient the last layer corners ~5 sec (1 out of 7 algorithms)
5. Permute the last layer corners ~5 sec (1 out of 2 algorithms)
6. Permute the last layer edges ~5 sec (1 out of 4 algorithms)

My current focus is to improve the F2L step as I am still struggling to get under 30 seconds, but I am confident that with some more practice I will manage to get closer to 20 seconds and then I can label myself a sub-60 cuber.

For further inspiration, here is a video of a sub-120 cuber and a sub-10 cuber.

Happy cubing!

Code Entropy

While preparing my talk at Smidig 2008 I kept thinking about the second law of thermodynamics.

Given two snippets of code, A and B, that have exactly the same external behaviour. If an expert programmer is more likely to change A to B than B to A, then snippet A has higher code entropy than snippet B.

Let us consider a very simple example:

{ int a=3; while (a<9) { ... ; a++; } } // snippet A

and

{ for (int a=3; a<9; a++) { ... } } // snippet B

The external behaviour for these two code snippets are exactly the same. However, most programmers would agree that snippet A is better rewritten into snippet B. So, in this example, during a refactoring session, it is likely that someone will change A into B, but unlikely that someone will change B into A. Hence snippet A has higher code entropy than snippet B.

Now, extend this idea into larger functions, classes, modules, applications, software design and architecture. Can entropy be used to describe the state of a codebase?

Code Cleaning

Take care of your codebase. Keep it clean. A good codebase will enable you to create more great solutions for your demanding customers. If you do not take care of your codebase, then it will rot and your projects (and company) will probably fail.

There is only one way to keep it in a healthy state, follow the boys scout rule: always leave the codebase in a better state than you found it. Whenever you make a change, try to write clean code yourself and clean up surrounding code.

I just gave a lightening talk at Smidig 2008. My talk was about a selection of techniques for improving existing code, how to keep your codebase healthy and why you should do it. Here are the slides and a recording of the talk.

JavaZone – Where to go next?

JavaZone 2008 was yet another great success. Two days, ~2300 geeks, 6 tracks and 100 sessions. This was my sixth time in a row attending the conference.

The conference has grown rapidly from ~400 people in 2003 at Chateau Neuf. The conference then moved to Radisson SAS at Holbergs plass, with ~900 people in 2004, ~1000 in 2005 and ~1400 in 2006. When Radisson SAS was too small to host the conference, JavaZone was moved to Spektrum in 2007 and the number of delegates could be lifted to ~2300. From a technical point of view JavaZone 2008 was more or less exactly as in 2007, the capacity has already been reached. The amazing thing is that the conference has been completely sold out every year, usually several weeks before the event. So where to go next?

I believe that as long as the program commitee does a good job to renew itself, it is in theory possible to keep the current format for another couple of years. Even if the arrangement is exactly the same, people will come as long as the program changes every year. However, how fun is it to arrange the same thing over and over again? Given a decline in the funfactor for the organisers, greed will sneak in and erode enthusiasm and positive attitude. For people motivated by money greed is usually not a problem, but JavaZone is a community driven conference based on a lot of voluntary work – greed will destroy. The dilemma is that JavaZone might die if it continues to follow its winning strategy.

I propose to move the conference to another city next year. Let a local javaBin group be responsible for arranging JavaZone in their home town. I would surely concider to travel a bit to attend JavaZone myself. Actually, I think I would very much enjoy travelling and staying at a hotel with friends from Oslo and meeting local geeks in a new city. Arranging JavaZone in another city will probably also reduce the size of the conference. But so what? A 600 delegate conference in Stavanger, say, might be just as valuable as a 6000 delegate conference near Oslo. Or, perhaps JavaZone 2009 should be in Trondheim, as a kind of a preparation for XP2010?

The next generation of superprogrammers

Most students coming out of university these days are completely clueless when it comes to computer programming. This seems to be getting worse for every year. However, in between all the garbage (where garbage in this context means students not really interested in or capable of programming a computer) there are some really exceptional and brilliant talents that might just need a few more years of experiences to become really efficient superprogrammers. This number is growing. The challenge is to find and recognize these talents, and are they willing to work for you?

I believe the next generation of superprogrammers is to be found in the free and open source software communities. They have little motivation to work with traditional closed source and proprietary software. Why should they? Yes, they want to work on challenging and interesting software projects, but also they want to share their best ideas with others – where the latter is perhaps the most important motivation factor. They want their work to be viewed by others, they want respect, recognition and to be admired by their friends, they want to be part of a world-wide community. In order to hire these people you need to realize that money, internal recognition and a “career” is not enough. You might need to change your business strategy.

Consider hiring a brilliant poet, painter or musician where the message is that their work can only be presented, displayed or heard inside the company – a ridiculous proposal and of course they will refuse. The same thing is true for the next generation of superprogrammers. Given a choice they will work for a company where their work is visible for the outside world, or even better, where their work is a contribution to the software community as a whole.

We see already that many companies have a hard time realizing the impact of free and open source software. Those who do not get it will die. Those who manage to attract the next generation of superprogrammers will win.

The Software Development Community in Oslo

Oslo has one of the most active software development communities in the world. For software developers that care about their profession, there are plenty of interesting things happening every week. Here are some activities, groups, meetings and conferences worth mentioning:

The Oslo XP Meetup and The Oslo Lean Meetup often invites hot-shots to present stuff about agile and lean software developement, but we also have small gatherings and programming experiments. By far, the biggest and most active community is javaBin, they have an active website and monthly meetings. The javaBin people are also responsible for organizing the big annual JavaZone conference which attracts more than 2000 delegates. Den Norske Dataforening is the old norwegian computer association, they have a few interesting meetings and they also organizes the annual Software conference. On smidig.no you find an agile software developer community, many of these people are also involved in organizing the Smidig conference. The Ruby community is also strong, and recently there was a Ruby Fools conference in Oslo. We even have a C++ Users Group. The Norwegian Developers Conference will probably sell out at around 1k delegates in June. I should perhaps also mention UXnet Meetup, Norwegian .NET User Group and Norwegian UNIX User Group. Last, but not least, a lot of us meet at Bilabong (Bogstadvn 53) on Tuesday evenings every odd numbered weeks to drink beer.

I am an active member of around half of these groups. Knowing norwegian is not a requirement, since many of these events are in english. If you find yourself in Oslo one day – feel free to contact me and I will introduce to the geek-life of Oslo.

Being Agile? No Speeding Please!

“Why do you have brakes in a car? Because then you can drive faster. [1]“ I like this quote, and I find it very relevant to modern software engineering. Teams that know when and how to use the brakes can drive a project fast and still arrive safe and sound at the final destination. But some agile teams are speeding; driving too fast, reluctant to actually use the brakes, and so they drive a project off the road. For example, sometimes you see teams being so much focused on implementing customer visible features that they forget about the importance of a sound and solid internal infrastructure. It seems like the old “nah, we are in a hurry, let’s write tests and documentation later” (which nobody did of course) has now been replaced with “nah, we are in a hurry, let’s do proper design and architecture later” (and this will of course never happen either).