I didn’t reach the ideal number of users for a usability study (only four in this case), but I got plenty of interesting information from just watching and asking questions. Looking at people while they use your software is very enlightening for a software engineer.

What surprised me the most was that even though I took special care in designing a user friendly interface and I had a pretty good guess about the users’ computer know-how, I still overestimated their ability to work with the software and missed opportunities to make things simpler. A lot of software engineers are just like me I believe, they don’t have a good grasp about what happens when someone sits down and starts working with their software.

The number one recommendation that I can make is: do usability testing. Odds are that you’ll have an epiphany and find many ways to improve your project. In the mean time, maybe you’ll find the following thoughts useful:

• In order to do usability testing you need at least one user, preferably three or more. The trick is that it has to be a real user, someone that will use/is already using/is likely to use your software. You can’t just go to Bob the tester and ask him to allow you to watch him. Sure, watching Bob will help, but you won’t get any mind-blowing insights from him; he probably has a much too similar way of thinking to you.
• Explain to your test partners that you’re not testing them, you are testing the software and they can’t do anything wrong or somehow break the computer. This should make them feel more comfortable and allow them to be as natural as possible.
• Tell them why they’re there, what your software does and what you hope to achieve with your test. Ask them what they think about the software at first sight.
• Try to be general with your instructions: for instance I wouldn’t say “Let’s open the invoice window and add three items by clicking the ‘Add item button’.”, I would say “Let’s try to create an invoice” or “Let’s do an invoice for three widgets. How do you think we could do that?”.
• Watch carefully. Having the users think out loud helps, but I managed fine just by telling them to stop whenever they’d like to ask me questions or point out something that grabbed their attention.   Steve Krug recommends that the session should be recorded. Pen and paper are acceptable in my experience, even if you have to stop for a few moments while you’re writing.

Having done more than ten usability sessions so far, I’ve made some general notes about what works and what doesn’t when it comes to UI. I’ll publish  those in a following post.

What’s interesting about these rants is that the ranter isn’t really using C++. They’re C hackers, or they program mostly in Python, or they used C++ at the beginning of the 90s. So I thought it would be interesting to write about my experience with C++.

First, a little background info…

I started learning C++ about 10 years ago, first the C part and then the ++ part. Nothing serious, just toying around with small projects to learn and have fun. I didn’t use it professionally until about four and a half years ago, when I started working on a large scale C++ project. Since then I’ve used it almost daily.

Two and a half years ago I came across Qt almost by accident: the large scale project that I was working on was being ported to Linux and the port was enabled by Qt. Since then, I’ve used Qt almost daily too.

Right now I’m working on a  Qt C++ project that’s about 25KLOC in size and growing. It’s a multi-platform, threaded client-server and it’s a line of bussiness app if you’d believe it. Working on it is fun, and I’m glad that I picked Qt and C++.

Okay, enough with the history, what about C++ and its warts?

Issues that bother me in practice

• Compile times and the include dependency specification: this is a problem that every C++ programmer will have sooner or later. It can be delayed and mitigated with a good physical design, precompiled headers and distributed compilers/linkers, but it can’t be solved without throwing away compatibility to existing code completely.
• The small standard library: not a big issue in itself, since you can find other libraries for anything you might want to do, but it’s unpleasant to install all those libraries and make sure that they work together nicely. Using more libraries instead of a large standard library also means that you have to wait on each library vendor to port the library to different OSes/compilers, upgrade it and so on.
• lack of reflection: I like Qt’s moc and I miss it in standard C++. I also wish it had more features.
• lack of type inference: even with typedefs I’m typing more than I have to. C++0x will thankfully fix this.
• localization & internationalization support in the standard library: the implementation is complicated and difficult to use. After browsing through C++ IOstreams and locales I’ve decided to just use Qt and not worry about it.
• template error messages: they’re long and hard to understand. I usually parse a template error message in about 10-20 seconds depending on the difficulty. The worst offenders are metaprogramming-heavy libraries such as Boost Spirit. In that case, I try to analyze the code first and see what might be wrong. STLFilt can help.
• functional programming support: this will get better in C++0x, but I can’t use C++0x now, at least not on all platforms and with the other libraries I’m using. Functors and free functions are cumbersome to use with algorithms.
• tools and parsing: C++ has access to solid, mature tools, but those tools are much harder to develop than for other languages and generally don’t have as many features.

Issues that don’t bother me at all, but are regularly brought up in rants

• memory management: never a problem for me. The last time I’ve had a memory leak was about two years ago and it got caught at code review. C++ has good support for memory management and good tools that can be used for runtime debugging. It might as well have GC, I wouldn’t be able to tell the  difference.
• memory corruption: memory corruption can be both exciting and scary. Exciting because you have to go down to the memory address level and do some sleuthing, scary because it can take days or weeks to find some bugs. I usually don’t sweat these bugs, they were very rare in the code I’ve worked on, and when they occurred they were easily found. e.g: the last one I’ve solved in maybe 30 seconds, the tools have gotten very good. The worst I’ve encountered was a problem with an embedded STL in a large project that took a week to figure out and only because of my lack of experience at that time. Some people love debugging.
• multi-threading: it is hard in most languages. The trick is using higher-level libraries such as QtConcurrent, Intel’s TBB or OpenMP. Sure, if you’re doing PThreads it’s going to be painful.
• string formatting and string support: I generally don’t use iostreams or std::string, but when I did I found them acceptable. Unicode support was the biggest issue, but “there’s a applib for that”. Now I use Qt’s strings and streams; they’re as easy to use as Python as far as I’m concerned. Don’t want Qt? Use boost::format or any other of the nice formatting libraries.
• templates in general: I use them when needed to break dependencies, write generic code, etc. I try to keep template code manageable, without going into the metaprogramming stuff; they are one of my favourite C++ features.
• exception rules: I don’t see any problem with exceptions in C++ as long as you’re using RAII. Other languages (e.g.: Python) use them extensively for error handling.
• STL & Boost: I’ve used both for a lot of time and I find them very useful. Contrary to popular belief, most templates don’t use metaprogramming techniques. You don’t have to install Boost, it’s mostly headers. A large part of Boost became TR1 so it should even ship with your compiler now.
• const: This one came from Zed, I don’t think I’ve seen that many people complain about const. Personally, I constify everything that I can, even const type* const.
• everybody learns a different 10% of C++: strange, because I use all of it and always have. It’s not that hard either, I’m not a genius… Sane projects have coding guidelines and architectural documents. If your teammate can waltz right in with a template metaprogram or is generally macro-happy and it doesn’t raise eyebrows at code review, you have bigger problems than using C++. I’ve had to fix two C++ projects so far; my only job was to do what it takes to make the programs work and ship them to the customer. Most problems were memory leaks, superfluous use of casts, functions that didn’t compile on all platforms and so on. Fixable. What I couldn’t fix – and had to patch up as best as possible – were issues with the program logic and architecture. Those were not caused by C++.

Ok, but what about…

You probably have your favourite C++ misfeatures.  Odds are that they don’t matter than much in practice, or workarounds are available. Maybe I just got used to them and consider them a C++ tax.

Then I see an interesting story and open it in a new tab. Here comes the master password dialog and it gets killed again. Now I use the new tab to surf to /r/cpp. The master password dialog cheerfully strolls into view.

Popping a dialog when the user selects a user name filed would be better, as it avoids leaking membership information when visiting a web site. I would also like to see this dialog redesigned – right now it’s a simple application-modal message box with an editor widget in the middle. If you have ten tabs open and you open another tab to a site that has its password stored, you won’t be able to interact with any of the tabs until you either enter the master password or dismiss the master password dialog.

Despite them – in the real world – more people are using C++ and the language itself is getting better:

• Compiler and tool support is better than ever.
• The C++0x FC draft is out, and the big C++ compilers already implement a significant part of it. It brings a larger standard library, better performance, more functional programming, easier syntax for some operations and improves the type system.
• With Qt, C++ has access to the equivalent of the .NET libraries or the Java class library. Free and open source.
• It’s available on even more platforms: Symbian and Maemo/MeeGo, and even Android or iPhone.

C++’ers gonna C++ and haters gonna hate… :)