Did Bell Labs initially try to hide that C was based on BCPL?

During research for my talk “History and Spirit of C and C++” (pdf, 11Mb) I realized that the reference manual Ken Thompson wrote for B in 1972 (pdf) was in parts a verbatim copy of the reference manual that Martin Richards wrote for BCPL in 1967 (pdf) (in particular look at page 6 in both documents or see slide 118-126 in my presentation). I guess that is fair as B is semantically basically the same language as BCPL. However, the odd thing is that in the more official reference manual for C dated 1974 (pdf), BCPL is not even mentioned at all.

“Good artists copy, great artists steal.” Perhaps this is just another kudos to Bell Labs, but I certainly found it interesting. It has to be said though that in all the interviews and later writings I have seen by members of Bell Labs, including Ritchie and Thompson, they are very open about BCPL being the main inspiration for B and C.

Call for Papers: C++ track at NDC Oslo 2015, June 17-19

There was a lot of interest for the very strong C++ track that we did at the NDC conference in Oslo last summer. Here is a summary I wrote after the event, including links to the videos that we recorded.

We are repeating the success this year, June 17-19. A few big names has
already been signed up, but we also need your contribution. If you
would like to be part of the C++ track this year, please submit your
proposal soon. The CFP closes February 15. Feel free to contact me directly if you have any questions about the C++ track.

Videos from C++ track on NDC 2014

As the chair for the C++ track on NDC Oslo, I am happy to report that the C++ track was a huge and massive success! The C++ community in Norway is rather small so even if NDC is a big annual conference for programmers (~1600 geeks) and even with names like Nico, Scott and Andrei as headliners for the track, I was not sure how many people would actually turn up for the C++ talks. I was positively surprised. The first three sessions was packed with people (it was of course a cheap trick to make the three first sessions general/introductory on popular topics). All the other talks were also well attended. The NDC organizers have already confirmed that they want to do this next year as well.

NDC Oslo is an annual five day event. First two days of pre-conference workshops (Andrei did 2 days of Scalable design and implementation using C++) and then 9 tracks of talks for three full days. As usual, NDC records all the talks and generously share all the videos with the world (there are 150+ talks, kudos to NDC!).

I have listed the videos from the C++ track this year. I will also put out a link to the slides when I get them. Enjoy!

Day 1, June 4, 2014

• C++14, Nico Josuttis (video)
• Effective Modern C++, Scott Meyers (video)
• Error Handling in C++, Andrei Alexandrescu (video)
• Move, noexcept, and push_back(), Nico Josuttis (video)
• C++ Type Deduction and Why You Care, Scott Meyers (video)
• Generic and Generative Programming in C++, Andrei Alexandrescu (video)

Day 2, June 5, 2014

• C++ – where are we headed?, Hubert Matthews (video)
• Three Cool Things about D, Andrei Alexandrescu (video)
• The C++ memory model, Mike Long (video, slides)
• C++ for small devices, Isak Styf (video)
• Brief tour of Clang, Ismail Pazarbasi (video)
• Insecure coding in C and C++, Olve Maudal (video, slides)
• So you think you can int? (C++), Anders Knatten (video)

With this great lineup I hope that NDC Oslo in June has established itself as a significant annual C++ event in Europe together with Meeting C++ Berlin in December and ACCU Bristol in April.

Save the date for NDC next year, June 15-19, 2015. I can already promise you a really strong C++ track at NDC Oslo 2015.

A final note: Make sure you stay tuned on isocpp.org for global news about C++.

A CppQuiz a day, keeps the debugger away!

C++ is a difficult language to master. Very difficult. It does not take more than a few days away from the keyboard before you start forgetting some of the details that will bite when you visit the dark and dusty corners of the language (sometimes because you work with code written by others).

Last month, Anders Schau Knatten officially launched a great tool for practicing your C++ language skills:

http://cppquiz.org

I recommend that you visit this site once in a while to challenge yourself. A good score on this quiz does not make you a great programmer, but it does suggest that you have a deeper understanding of the language than most. Being fluent in a programming language makes it much easier to avoid the dark and dusty corners so that you can concentrate on writing high quality software instead of spending time in the debugger.

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.

Deep C (and C++)

Programming is hard. Programming correct C and C++ is particularly hard. Indeed, both in C and certainly in C++, it is uncommon to see a screenful containing only well defined and conforming code. Why do professional programmers write code like this? Because most programmers do not have a deep understanding of the language they are using. While they sometimes know that certain things are undefined or unspecified, they often do not know why it is so. In these slides we will study small code snippets in C and C++, and use them to discuss the fundamental building blocks, limitations and underlying design philosophies of these wonderful but dangerous programming languages.

Jon Jagger and I just released a slide deck to discuss the fundamentals of C and C++ (slideshare, pdf).

The Champion, the Chief and the Manager

Successful product development projects are often characterized by having an enthusiastic product champion with solid domain knowledge, a visible and proud chief engineer, and a clever and supportive project manager. And of course, the most important thing, a group of exceptional developers. From an organizational point of view it makes sense to require that all projects should clearly identify these three roles:

The Champion: The product champion is a person that dreams about the product, has a vision about how it can be used and can answer questions about what is important and what is less important. The product champion is required to have a deep and solid domain knowledge and will often play the role of a customer proxy in the project. This position can only be held by a person that is deeply devoted and has a true passion for the product to be created. The product champion is the main interface between the project and the customer/users. (Sometimes also known as: Product Manager, Project Owner, Customer Proxy…)

The Chief: The chief engineer is a technical expert that has a vision of the complete solution and is always ready to defend this vision. At any time, the chief engineer should be able, and willing to stand up to proudly describe the solution and explain how everything fits together. He/she should feel responsible for technological decisions that the exceptional developers do, but also make sure that the solution is supporting the business strategy. The chief engineer is the main communication channel between this project and other projects. (Sometimes also known as: System Architect, Tech Lead, Shusa, …)

The Manager: The project manager is a person that leads a team to success by managing the resources on a project in an effective and sensible way. He/she will be responsible for actively discovering and removing impediments. The project manager is the main interface between the project and corporate management. (Sometimes also known as: Scrum Master, Team Leader, …)

Of course, for very small projects these three roles can be fulfilled by one person, but for projects of some size there should be three people filling these three roles: one product champion, one chief engineer and one project manager. These three people must work together as a team, form an allround defence (aka kringvern) around the project, while being available to the developers at any time. Their task is to “protect” and “promote” the project to the outside world so that the exceptional developers can focus on doing the job.

I believe that identifying these three roles is the only thing an organization needs to impose in order to increase the chance of success. Then the team of exceptional developers together with their servants decide everything else, including which methodology and technology to use.

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!

Technical Debt

With borrowed money you can do something sooner than you might otherwise. If you are willing to incur technical debt you can release a product earlier than you might otherwise.

We all recognize these stereotypes: The sales team is willing to (and sometimes do) sell a product and cash in the money long before development is finished. While the engineers are reluctant to let go of their baby because there are always things that can be improved. A successful business needs engineers and salespeople that are willing to compromise and cooperate on this conflict of interest. Technical debt is a powerful metaphor that can be used to work on a compromise, especially when we are talking about software development.

Technical debt in a software project includes internal things that you choose not to do now, but will impede future development if left undone [1]. Examples of technical debt might be: We need to upgrade our compiler to a more recent version, but let us ship the product now and upgrade the compiler later. We do not properly understand how to implement this feature properly anyway, but this hack seems to make the customer happy for now. We have identified some dirty code that is slowing us down, but we choose to fix it in the next release instead. These are all examples of prudent and deliberate reasons [2] for taking on technical debt which can be compared to borrowing money for sensible housing. There are also less responsible ways of incurring technical debt though, perhaps caused by; lust, gluttony, greed, sloth, wrath, envy or pride. Examples might include: writing bad code, skipping analysis and design, over-engineering, résumé-driven development and so on. This kind of technical debt is more like unauthorized overdrafts and check bouncing, and is best avoided if you have a long-term vision for your product.

Like financial debt, a technical loan will incur interests, and if you are not able or willing to pay back the loan then you risk go into bankruptcy. The nice feature of software however is that paying back is usually both possible and comparatively cheap. While making effective and strategic decisions about what internal qualities to postpone you should keep track of them and write down an estimated effort needed to do it properly. This will give you an idea of how much you owe at any point in time. Then, after rushing a release out of the door, you can immediately start to pay back by doing the postponed things properly and get a flying start into the next release. Retrofitting stuff like this might appear to be more expensive than “doing it right the first time”, but since we are dealing with software it is often the right approach.

Perhaps the most powerful feature of the Technical Debt metaphor is that it communicates well between technical and non-technical people [3]. By quantifying the current technical debt in your product it should be possible to get management both interested and involved in the importance of controlling the debt burden.

References:
[1] www.c2.com
[2] martinfowler.com
[3] blogs.construx.com/blogs/stevemcc

UPDATE June 2010: At Smidig 2009 and XP2010 I presented a talk titled “Technical Debt is Good!” based on this material. Here are the slides (pdf) that I used in norwegian and english respectively.

Your codebase is like a kitchen

The state of your codebase determines what you can achieve. In some ways your codebase is like a kitchen. I just presented a lightning talk about this analogy at the ACCU Conference. Here are the slides.

Advanced Feedback-driven Development

For any non-trivial project: Software development should be considered a continuous learning process and a cooperative game of communication between professionals. Effective software development can be achieved through frequently repeating cycles of preparing, changing, observing, reflecting, and learning.

While the statement above is obvious to many, it is easy to miss the key points. For instance, you must make sure that you facilitate the learning process by implementing effective feedback mechanisms, do frequent iterations and be willing to re-plan the project continuously. You must also implement information radiators, enable osmotic communication, and get rid of things that hinders communication (yes, I am a fan of Alistair Cockburn). But first of all, you must assume that your developers are professionals that know what to do given a vision, trust and enough information. You should certainly not treat your developers as mere resources that need to be directed and told what to do and how to do it.

I am fortunate in that I work for a company that really gets it. I invite you to take a look at these slides. The key thing that this particular project do better than most is to do fast and automatic testing on all levels which gives developers confidence when making changes. Automatic feedback from all levels was a key success factor to get the first version out of the door, and now we have a workflow that will support further development for years. I think it make sense to describe what we do as advanced feedback-driven development – AFDD.

Software Architecture is a key enabler for your Business Strategy

Last month I organized an internal 4-day workshop in Software Architecture at my company. Twelve lead developers representing several product groups and development sites attended. The instructor was Dana Bredemeyer himself.

The workshop was excellent, although quite different from what I expected. Bredemeyers workshop was all about techniques for translating your strategy into architecture. Little was said about how to translate architecture into implementation, but that was ok. I have to admit that so far in my career I have thought about software architecture as something that first of all is useful for the implementation of software. But now I realize that for a business relying on complex software, focus on architecture is indeed a key enabler for your business strategy.

All software implementations have an architecture. By studying the code base and a running system you might be able to both illustrate the architecture and explain the expected behavior of the system. For many, perhaps most, development efforts this is a sensible way of working – apply most of your energy on writing code and just take a brief look at the resulting architecture at regular intervals to see if it makes sense. Let the user requirements drive the implementation, and use your test scenarios to verify the product. Because you will never get exactly what you plan for, the resulting product will determine which business strategy you can use to make money and the architecture will restrict how to evolve your business. The products drive the business (see figure 1).

For a business with only a few products on the market this can be a very efficient way of making money. Your product might be successful and the business attracts money that can be invested in making the same product even more fancy to attract even more money. Adjust your business strategy according to the products that are available.

However, as the business grows and the product portfolio diversifies, you need to focus more on architecture. Why? Because you might want a mechanism to let a strategy run the business, not the products. The key is to focus more on architecture so that you can drive it with your business strategy, and let the architecture strongly influence the implementation so that you get products that support the strategy. It is then possible to let a strategy drive your business (see figure 2).

Beware, I am not trying to tell you that heavy focus on architecture is the only way to succeed. It is certainly possible for huge businesses to experience massive success with large and complex software systems without paying too much attention on the architecture. However, the key point is that if you want to control your business by defining strategies you need to focus on the architecture – otherwise not much will happen if you position yourself inside the strategy bubble and try to twist the knobs.

C++ Idioms by Example

I read a lot of code. Often I like what I see, but 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. There are plenty of really good books about this topic, but most of them start at a slightly too advanced level – they assume that the reader already know about the basic stuff.

I have tried to make a little contribution by illustrating some of the really basic C++ idioms and conventions using a contrived but still complete example. Please take a look at this presentation.

When presenting this stuff, I usually hand out the first code snippet to a group of people, then I do online coding while the group suggests improvements and we discuss why it is so. Interesting enough, it seems like we always end up roughly at the same place. This presentation is just one of several paths that might happen when a group decides what to improve or not.

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.

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.

JavaZone 2007 – and a tribute to Totto and Stein

This week I attended JavaZone 2007 – two days, Rammsund, more than 2000 participants, no boring keytalks, free food and drinks, 6 tracks and 1 hour talks. Long days and no breaks, still plenty of opportunities to mingle with friends, strike up a conversation with the speakers and establish new connections. This is by far the most valuable developer conference that I know of, even for non-Java developers (I am doing mostly C++ these days).

I have been to JavaZone every year since 2003. The first two years as member of javaBin and one of the core organizers. It has grown from a small one-day happening with 350 participants into a big two day conference with more than 2000 participants. While most conferences seems to grow and/or degrade into something useless after a few years, JavaZone is growing while getting just better and better for each year – I am really impressed. It seems like the core values of the event has remained more or less unchanged during the years. The event is completely controlled by a group of enthusiasts (javaBin). Commercial sponsors are very welcome but they do not control any aspect of the conference. This is a hard core conference made by developers for developers. Great stuff!

But, if I have to single out the three main reasons why JavaZone is such a success, I guess everybody with some insight will agree when I say: Thor Henning Hetland (Totto), Stein Grimstad and Carl Onstad. With help from a lot of extremely able and willing people of course, they have created one of the best developer conferences in the world. I know them well, they are incredible personalities and great people to work for. After 6 years, Totto and Stein have decided to step down and let somebody else take over JavaZone. It will be interesting to see what happens, but there are several very capable candidates in javaBin that can take over their roles. My guess is that as long as the core values defined by Totto and Stein remains, JavaZone will continue to succeed. I am already looking forward to JavaZone 2008.

Building a C++0x version of gcc

I am really excited about the upcoming C++ standard, nicknamed C++0x. It would be great to have a compiler that supports some of the proposed features, instead of just reading about them. So I set out to build the C++0x version of gcc.

Here is a quick description that worked for me (OS X 10.4):

$ svn -q checkout svn://gcc.gnu.org/svn/gcc/branches/cxx0x-branch gcc0x
$ cd gcc0x
$ ./configure

This gave me the following error message:

configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2.1+.

which I fixed by porting mpfr and gmp.

$ sudo port install mpfr gmp gmp-cxx-wrappers

and then I could configure, make and install like this (compilation takes about an hour):

$ ./configure --enable-languages=c++ --with-gmp=/opt/local --with-mpfr=/opt/local
$ make
$ sudo make install
$ /usr/local/bin/g++ --version
g++ (GCC) 4.3.0 20070628 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Now I can write C++ programs and play around with new language features, such as static assertions, variadic templates, delegating constructors and decltype. I can also use some of the new library stuff, such as <regex>, <tuple>, <type_traits> and more… Cool!

Note, for some reason I get a warning during linking. It says:

/usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib ...

The code links and run so you can perhaps just ignore the warning, but here is a workaround that silence the linker:

g++ -Wl,-dylib_file,/libgcc_s.1.dylib:/usr/local/lib/libgcc_s.1.dylib foo.cpp

Have fun!