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.

Daily Stand-up Meetings - Perhaps the third question should go first?

It is about 10 years since the first time I participated in a project using daily stand-up meeting. I was immediately fascinated. Since then I have always encouraged development teams to do daily stand-up meetings and to get rid of the traditional weekly status meeting.

Modern software development is about taking advantage of the fact that most often you have a group of very intelligent and capable individuals working together as a team. Given accurate information developers will know what is the right thing to do for the project to succeed. Given enough freedom (this is often forgotten) the developers will also be able to do the right thing. The daily stand-up meeting is an effective mechanism for making sure that everybody on the team have enough information to do the right thing.

There are a lot of formats for running the daily stand-up meeting (ref). But common for most of them is that everybody on the team should answer three questions in this particular order:

1. Did?
2. Will Do?
3. Impediments?

Sometimes I observe stand-up meetings where the third question is skipped. Nobody in the team mentions anything about problems, hindrance, obstacles or anything that impedes their work. It is very unlikely that this is true. In a software project there is always something that can be improved to speed up the team.

Actually, of the three questions, the third question is by far the most important in a daily stand-up meeting. The “Did?” and “Will do?” question is also important, but the information is often also available in the software repository and the task bord. Apart from the daily stand-up meeting, there is often no formal mechanism for making sure that everybody knows about what slows down the team.

Therefore, I propose that we should order the questions according to their importance. Allow me to suggest that in the daily stand-up meeting the team members should answer the following questions:

1. Any impediments in your way?
2. What are you working on today?
3. What have you finished since yesterday?

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

Report from ACCU 2008

I just came back from 7 days in Oxford attending the annual conference arranged by ACCU. Around 300 delegates (I was told), interesting program, very suitable conference location and excellent organising comittee lead by Giovanni Asproni. The conference was packed with people that really care about programming like myself and they all behaved as if we were long time friends. It was this feeling of… feeling of… coming home. The conference was

Erlang gives me positive vibes

During my years at university (1992-1996) I was very excited about declarative programming langauges. We studied plenty of examples where a clumsy solution in a typical imperative programming language, such as C and Java, could be replaced by a few elegant lines of code in for example Haskell, ML, Lisp or Prolog.

After leaving academia, 12 years ago, I have only been working with imparative programming languages, mostly C, C++ and Java. Apart from occationally hacking away in Emacs Lisp there has been little to remind me about the theory and excitement about declarative programming languages. Until recently…

A major concern today is how to utilize mulit-core architectures. It is not unlikely that we will soon have processors with thousands of cores each running relatively slowly, rather than a few cores running at several gigahertz. Dispite a massive increase in theoretical processing capacity it is not obvious how traditional imperative programming can use such processors effiently. Even quad core processors today are giving headaches to programmers concerned about performance. OMP, MPI, TBB, Fortress, C++0x and so on might promise some short-term relief, but it is probably wise to prepare for a paradigm shift in how to program computers.

During the last year, I have read and heard more and more about Erlang. Several of my geek-friends have suggested that Erlang is rapidly climbing on the list of interesting programming languages that can also be used for serious stuff. In particular Erlang has popped up in discussions about how to handle the multi-core “problem”. Then suddently I received an invition from Syver Enstad and Marius Mathiesen to join a studygroup in Erlang. Today we had the first meeting, discussing the first chapters of the “Programming Erland” book by Joe Armstrong. I would have said yes to their invitation regardless of language (I am a programming language geek), but at the same time it was in particular timely that Erlang was the subject.

So far I have not read more than a few chapters in the book, installed the intepreter and played around with some toy examples, but I am already feeling an excitement about Erlang and declarative programming again. Considering the attention that Erlang seem to get these days and looking at the installed base of serious applications and libraries, Erlang gives me positive vibes. Perhaps I am right now learning about some technology that will play a central role in an upcoming paradigm shift?

Discovering the importance of hygiene in software engineering

Last month I spent a week with Uncle Bob (Robert C. Martin). First I attended a three day course about “Test-Driven Development and Refactoring Techniques” hosted by ProgramUtvikling. Then we hired him for two days at my company to do some direct coaching for a small development team. Of course, I learned a lot about test-driven development, refactoring, astrophysics and software professionalism. But there was one thing he said that I have been thinking about a lot - he suggested that the “discovery” of test-first in software engineering might be compared to the discovery of the importance of hygiene in hospitals by Ignaz Semmelweis in the middle of the 19th century. These days it seems like a lot of professionals are accepting the importance of test-first in software engineering. But there are still large groups of software developers that are very ignorant to what is happening in the industry. Some programmers will probably never get it, these are the once proudly claiming that; “this new stuff about test first and unit tests applies only to web-kiddies”, or “We are real programmers and we know how to write real code”. While others, in particular C programmers, often uses the lack of tool support as a bad excuse for not following principles of modern software development. I guess the situation we are in software engineering right now is not unlike how the medical establishment rejected Semmelwies’ ideas, just to realize decades later that washing hands before treating patients does make sense.

Test-Driven Development in C

At Smidig 2007 I gave a 10 minute lightening talk about Test-Driven Development in C. Here is a link to the slides.

C++0x - A quick and dirty introduction (November 2007)

Together with Lars Gullik Bjønnes, I recently gave a quick and dirty introduction to C++0x as of November 2007. We did not have any intention about making a complete and accurate description, but rather present stuff that we find interesting. It includes:constexpr, static_assert, template <typename… args>, scoped enums, aligned_storage, decltype, auto, defaulted and deleted functions, rvalue reference, delegating constructors, std::array, std::shared_ptr, std::tuple, std::minmax, std::function, std::bind, std::regex, std::thread, … and more.Here are the slides from this talk.

Oslo C++ User Group

Oslo C++ User Group (ocppug) had their first meeting this week at The Scotsman. Twelve very knowledgeable men showed up for this meeting (Fredrik, Christian, Igor, Terje, Alf, Johan, Sergey, Samuel, Syver, Frans, Einar Otto and myself). The topic was C++0x, the up-coming C++ standard, hopefully to be finished by 2009.

I opened the meeting by giving a “Quick and dirty introduction to C++0x” (pdf, html). Einar Otto Stangvik provided a solid discussion about why multi-threading in a language not designed for concurrency is difficult. He gave a talk about “Threading in C++0x” (pdf). Terje Slettebø gave a talk about “Concepts in C++0x” (pdf) and he showed the reasons for introducing it into the language.

The meeting started at 1900, we finished the formal part of the meeting around 2130. Then we went downstairs to have some pizza, more beer and lots of good discussions. I really enjoyed this meeting, and I am already looking forward to the next meeting.