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.

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?

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.

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

Agile methodologies encourages you to do things in small steps, often in cycles that can be measured in seconds or minutes. It does not really matter if you do ‘think/change/test’ or ‘add test/change/refactor’, sometimes you will meet challenges that require many hours or days or even weeks to do properly. Just as we in the old days could spend months on a Big Design Up Front (BDUF) before starting to code, we must now be prepared to pause once in a while and spend some time thinking. For example, suppose you are to implement a feature where you need to store some values for later retrieval. You realize that you need some kind of persistence mechanism - and it is obvious that a big chunk of internal infrastructure is missing. This is a time where you need to slow down and make sure that you do this properly. Being agile should not be used as an excuse for just mocking up some poorly designed ad-hoc persistance mechanism.

If you do not slow down when required you will end up with bad design and architectural rot. Soon developers will start to complain about: “it is hard to find stuff”, “it is hard to add stuff”. Despite everybody working very hard, the real progress of the project is next to nothing. The project is like a car stuck in the mud, now pressing hard on the accellerator pedal is not what you want to do. This is not a time for more hard work, now you need to start thinking. You have wasted a lot of time and effort already, but if you are willing to backtrack a bit you might be able to fix the bad design, improve the architecture and get the project back on track. Not slowing down when required will cost you a lot in terms of time and effort, but also in frustration and lost confidence from developers and management. Actually, just like when driving a car, the penalty of driving too fast is so high that (most of us) always prefer to have a large security buffer. If you are eager to successfully complete one project after another, then behave and drive sensible. But of course, in software engineering there are no real cops watching you, so if you can see a very long open stretch, then go for it…

[1] I first heard this quote from Kevlin Henney at 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 a superb experience. I just wish I knew about this conference years ago and I will definitely try to go next year as well.

(Disclaimer: this is a report based on what I heard and remember, not necessarily what was actually said or written. I do apologize upfront for any sloppy understanding and recollection of a particular subject, session and happening.)

On Tuesday (Day 0) I attended a one-day tutorial about Erlang - the programming language. I do believe that we are about to see a paradigm shift in the way we think about programming computers. Declarative and functional languages might soon play an important role, also in the industry. The tutorial was presented by Joe Armstrong, Mr Erlang himself. I enjoyed the tutorial very much. I hope to get more time to do play around with Erlang soon.

Tuesday night a group of us went out for a curry at Chutneys. Highlight: The bill. Why? As someone proudly announced: “Hey folks. This is fantastic! We are 23 geeks and the bill is of course exactly 529 pounds!”. When everybody around you smile and find that amusing - then you know you are among friends.

Wednesday started with a keynote by Tom Gilb (slides). Tom was concerned about delivering real business value to all stakeholders in a project. He proposed to add an “agile envelope” around the agile methodology and lean principles. Several in the audience was provoked when Tom insinuated that agile practitioners are not really trying to deliver business value… and you know that you are at the right conference when someone just stands up in anger and shouts (something like) “Tom, what you are saying is wrong!”. He continues to promote the Impact Estimation Table. And as usual his solutions involves meassuring and quantifying stuff - which makes me sceptical.

Roger Orr talked about writing programs in a networked world. I found the talk interesting even if it was not too much new for me here. Having worked with networked applications for over a decade, most of the stuff was known. At the same time, it is always useful to get reassurance on things that you think you know. Key messages: Good networking interfaces are the key to good support and maintenance. Prefer higher level abstractions, allowing for multiple potential transport protocols. Make sure that you handle versioning issues. Security usually conflicts with other goals (eg, supportability) and it is often not possible to add proper security late to a product.

How to become Agile was a talk by Jutta Eckstein about introducing agility to a project or to an organization. The key idea was that a successful transition is impossible without involving management. But at the same time, introducing agility top-down does not work - trust is lost at the beginning. People are often looking for recipes, which is kind of opposite to what agile methods is all about. It is useful to identify and empower change agents that can assist the process. The change agent is often someone from inside, but they might need some support from outside at first. People tend to listen more to external people than internal people even if the message is the same. As most agile experts seem to agree upon, Jutta claimed that doing retrospectives is the most important agile technique. It is a big mistake to skip the retrospetive sessions. Between projects you might need to use a whole day, while an hour might be sufficient between iterations. Useful links (The World Cafe, Virginia Satir, Shuhari, Agile Software Development in the Large).

Perhaps the most entertaining talk at the conference was Robot Wars by Ed Sykes and Jan-Klaas Kollhof. They believe that there is an exciting robotics market about to evolve, and they have been looking into different development tools. They demonstrated how to use Microsoft Robotics Studio to program Lego NXT robots. Then we got a demo of free alternatives for robot programming. For their final demonstration, Ed and Jan-Klaas added a camera purchased from mindsensors.com to show how a robot could chase another using a very simple application. I have an NXT myself and I thought this was really great stuff.

There is something in the air… said Simon Peton Jones, Mr Haskell himself, during his opening keynote on Thursday. His talk was about Caging the Effects Monster - the next decade’s big challenge. The key message was that in order to improve and reach nirvana in programming we need to be able to control the effects and implement large parts of our programs without any side-effects. Simon demonstrated some really nice examples and rationale for functional programming. He also presented strong indicators showing that functional languages are attracting substantially more attention these days. Links: ( Haskell, F#, Erlang, OCaml, Scala, monads)

The Selfish Object was a talk by Kevlin Henney. The key idea was that instead of focusing on what an object can use or be given, you should focus on what it wants. Need and want is not the same thing. The same goes for object interfaces. When extracting interfaces, focus on the usage and not on the implementation, fex, do not name the interface after the implementation, but find a name based on client usage. Avoid singletons, there is never a real need for them, you can always parameterize from above (Pfa) instead. Don’t use approaches like Template Method (NVI). Through techniques for controlling dependencies, such as Pfa (parameterize from above), dependency inversion, role-based naming, and more, you might end up with a better radial architecture (onion ring) than the more traditional one-way architecture (layer cake). Later same day, John Lakos summerized nicely: “I want to depend on the interface, the whole interface, and nothing but the interface. So help me Kevlin.”.

Just after lunch there was a BOF session about local ACCU groups. Since I am involved in a lot of geek activities in the Oslo area, I was interested to hear what kind of things local ACCU groups were discussing. How to get speakers and how to attract people to the events was discussed. Apparently getting a location for events is difficult. In Oslo we often use pubs for small events (up to 120 people), this seems to be more problematic in UK for some reason (perhaps there are not that many pubs in UK?). The ACCU group in London have had success with borrowing meeting rooms from the big banks. Another group had managed to use the computer section of a book store, a really nice idea. Recording of presentations was also discussed. But, first of all recording introduces a lot of work and also the speaker and audience is less likely to interact and engange in interesting discussions if recorded. This aspect is also true for the ACCU conference. Recording the sessions removes the magic.

John Lakos ran through 562 slides in his talk: Toward a Common Intuition and Reusable Testing Methodology. It was an excellent presentation, but it was deep stuff and I have to admit that was not able to absorb all the ideas - it was like drinking from a fire hose. But there was a very interesting and solid discussion about what it means to be “the same” and what the salient attributes of something are. In C++ a lot of errors arises due to ignorance to these subjects. John, what about dividing this talk into two, where the first is named “The same? What the fuck do you mean?”, that would be more like sipping a superior single malt.

The next session I attended was about Memory Allocation by Andrei Alexandrescu. The main message was: If you try to write your own allocator, you will fail. Over and over again, we see that the best general purpose memory allocator outperforms a special purpose memory allocator. If you have identified, through proper profiling, that you indeed have some specific needs, then you should use a reaps allocator (regions with free-list), otherwise go for the Doug Lea memory allocator.

The last session of Thursday was a special version of Just a Minute hosted by Ewan Milne. Funny, but perhaps not so useful. As I did not know about the “Just a Minute” concept, I thought (for some reason) that we would get some sort of Lightning talk session. We have used this format (1-10 minutes talks) successfully at several events in Oslo. I would love to see a session of lightning talks at ACCU next year.

The opening keynote on friday was presented by Andrei Alexandrescu. He talked about fundamental challanges in programming languages, and briefly introduced Stepanovs litmust tests: If you can’t implement max, swap or linear search properly, what are your chances to implement really complex stuff? To kind of underline the point, Andrei demonstrated an even more fundamental problem, even implementing the identity() function is really complex in C++. Fortunately, with C++0x we are apparently moving in the right direction.

Despite being a dedicated Emacs power user, I have to admit that I sometimes envy the tools that Java developers have available - Eclipse being one of them. I wish I could use Eclipse on C++ code as well. For the last few years I have been downloading the latest version of Eclipse CDT once in a while to give it a go. For now, I do not see that it adds any value to my C++ development environment, but I am still optimistic because I can see improvements every time. When I saw that Peter Sommerlad was giving a talk about C++ Refactoring and TDD with Eclipse CDT (slides). I thought I might learn more about the state of CDT - and I did. Some of the new refactoring tools that have been added looks interesting, but I got the impression that they are still quite fragile for variable C++ coding styles.

Testing is a way of showing that you care. This was a key message from Kevlin Henney in his talk Know Your Units. There are many testing techniques - unit testing being only one of them. But it is important that you distinguish between what is a unit test and what is not. A test is not a unit test if it uses external resources or if it require a particular order of execution. By focusing on doing unit testing correctly, you will often be forced into making sound design and architectural decisions. Tests that are not unit tests according to the definition might also be very useful but they serve another purpose - often they focus on finding bugs. A useful technique when writing unit tests is to prefix the test name with ‘require’ as in ‘require_that_sqrt_of_4_is_2()’ rather than ‘test_sqrt_4_is_2()’. Your tests should look like requirements and this naming style will guide you into writing better unit tests. Other guidelines: The more general a method gets, the less useful it is for a particular application. Get rid of your singletons, they make your code untestable. Don’t ever invite a vampire into your house, you silly boy - it renders you powerless.

Before the Speakers Dinner friday night, two teams met at the squash court to settle the long term debate of whether braces should be aligned:

// aligned style
if (is_ready())
{
do_foo();
do_bar();
}

or disaligned:

// disaligned style
if (is_ready()) {
do_foo();
do_bar();
}

I was (of course) playing for the “disaligned” team and it was a fierce competition for about an hour and a half before we gave up… failing to declare a winner. It was decided to bring in more combatants and do a boat race later in the evening to settle the debate. If I remember correctly the ‘disaligned style’ team lost, but as you know, in a boat race having most supporters and the biggest team is not an advantage…

I would have liked to see Roger Orr presenting the keynote on Saturday morning, especially since I later was told that it was a really good one. But I did not get to bed before 5am saturday morning and sometimes you have to prioritize hard.

Detlef Vollman gave a talk about C++ for Embedded Systems. This was a particularly useful session for me since it is exactly what I do for a living. Some messages: In embedded systems, power consumption is often the biggest problem. Immutable strings make sense, so you might need to implement your own string class. In low-level classes you should not use dynamic memory allocation. Don’t fall into the OOAD trap where you only analyse a system top-down, for embedded systems you must also use a bottom-up lego approach. C++ is a multi-paradigm language, which is very useful for embedded systems. Only use OO if it really gives you some benefit.

For the last year I have been following the C++0x process closly, so of course I had to attend C++ 2009 in 90 minutes by Alisdair Meredith. I already know about most of the things that are going into the new standard, but my knowledge is superficial. For example, when I first saw the proposal about rvalue references I did of course realize how useful they are for making dead hard quiz questions, but after Alisdairs talk I understand more about why some of these things are important additions to the language.

Then finally, there was a panel debate about the State of the Practice lead by Giovanni with Tom Gilb, Hubert Matthews, Russel Winder, Peter Sommerlad and James Coplien in the panel. They all seem to agree that as an industry we have really screwed up badly. Sure there was a lot of good points made, but I suspect they have a somewhat biased experience base. Big names like these guys are often brought in to fix stuff in failing projects rather than watching successful projects completing a masterpiece. In addition, it is always comfortable to be the one critisizing instead of being optimisitic - being a pessimist is the safe bet in all things with a large degree of uncertainty. But at the same time, the session was indeed interesting. Some stuff that was dicussed: Are there too many lay programmers out there? Do we need to become a registered profession? Perhaps we must split CS into displines like telecom, banking, military, and so on? Are we going into a cultural rot? Is software development a normative discipline? Do customer buy a service or a product? Does better compilers make it just easier for lay people to write bad software? Will making a registered profession have impact on free and open source software development? Is the free market for software working?

And then the conference was over.

Sunday morning. 6am. Three alarm goes off. Must not be late for my flight back to Oslo. Looking out of window. England covered in snow. Wow! Prepared for a really bad trip home. Luck. Flight was just a few hours delayed. Wife and two kids. It’s always nice to come home…

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.

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

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