Solid C++ Code by Example

April 15, 2010

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

February 12, 2010

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

January 23, 2010

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

October 19, 2009

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

April 24, 2009

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

March 26, 2009

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

January 9, 2009

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.