First we had a workshop in our office with two visitors from one of our offices in France. We had a lot of issues to discuss, and once again the value of face to face conversation over lengthy email discussions was evident. Though all problems are not yet solved, we have a made a plan which hopefully should get us to a solution, particularly now that we all have sat together and gotten closer to a common understanding of the project.

In addition, the last two days of this week I have attended a training course in “Advanced Presentation Skills”. We were six students in the course who all got to try ourselves as presenters on multiple occasions. The instructor taped us on video during some of our presentations, and we got feedback from the instructor and each other. It was two hectic, but very inspiring days. I learned a lot about my presenting that I hope I can use for my presentations in the future.

One of the most valuable lessons I brought with me from this training was how important the structure of the presentation is. Looking back at the presentation we did at NDC this summer, I can see several things I would have liked to improve. It wasn’t a bad presentation, but we didn’t really make our point as clear as we could.

I also got several hints about my delivery style that I want to keep improving.

“For whom am I writing?” is a question we should ask our self continuously when programming. I often see code that is hard to use, difficult to understand and next to impossible to maintain. That is a clear sign that the author of the code did not consider the readers.

The least important reader is the compiler. The compiler is pretty good at understanding what you mean, and as long as you keep within the language, it will handle it. Instead, we should write for:

The reader of this code

The reader of code that calls this code

The writer of code that calls this code

Thinking of these three roles will naturally lead to many of the best practices for good code (such as those found in books like “Clean Code”). You will have to find good names and good signatures for the methods and classes you create. Also, it is seldom a good idea to be too clever in the solutions we pick. Maybe you’re able to save a few lines of code, but if it means that all that come after you have to spend hours just trying to figure out what you’re doing, it’s not good code (unless you’re writing for a code obfuscation contest…)

We write the code only once, but it is usually read many times. As developers we spend a lot more time reading code than typing in new, even if we often don’t think about it.

Today we came across a code snippet that rewritten in C# would look like this:

As we fist only looked at the inherited class, this looked very strange. Why have the method that sets the filter without type safety, and why is the method returning the old object when setting the new? After searching through our quite large code base, we found that this method was only used in two places – in a test which could simply be replaced with the typed version, and in the base class. The base class looked something like this:

class BaseClass {
// ...
public void InitializeNewRound() {
// ...
object oldObject = SetNewFilterObject(null);
// ... do a bunch of initialization stuff that requires there to be no filter
setNewFilterObject(oldObject);
// ... do some more initialization that should have the filter in place again
}
public virtual abstract object SetNewFilterObject(object handler) { }
}

Since the base class was in a different architectural level than the inherited class, and the filter types was all in the level of the inherited class, the base class couldn’t know about these types (architectural rules in our code base). Therefor someone has at one point found that this was a good way of achieving what they needed – to temporary disable the filter (by setting it to NULL which in this context meant no filter), and then turning it on again.

But the downside was that it took us a while to understand why it was written like this, and how the code worked. So we decided to rewrite the method
into two methods:

This, of course, comes at the cost of adding a field to the inherited class, but the improved readability is well worth it in my view. The next person who comes into this code, will not have to wonder why there are two set methods. Also, someone coding against these classes won’t have to figure out which of the two sets methods to use.

In reality, this code was in C++ and quite complex – otherwise we would probably have found a lot more ways to make it even nicer. But now we’ve at least done a bit to make things somewhat better.

I’m in Houston for a few days for a meeting about a new feature we may put into our software. It’s a long trip for a short meeting, but at least the weather here now is like a very nice summer day at home. It is really nice to be able to sit outside in the sun and enjoy food and drink, even if the native population seem to prefer staying indoors. It has not gotten too hot here yet. But of course, most of the time I have to sit inside the office in a crowded meeting room participating in the discussions I’m here for.

Here in my hotel room, the air conditioning is running full speed. It’s a little cold here now, but I prefer it that way so that I can turn it off during the night and get some sleep.

We’re running a “Software Craftsmanship Study Group” in our office. There we are currently going through Robert C. Martin’s book Clean Code. In our meeting this week, we talked about the chapter of error handling (written by Michael Feathers) and came into a discussion about null objects.

The book advises that you should have a policy of never returning null and, even more importantly, never accepting null as an argument to your methods.

Most people agreed on the latter principle (though there were some debate), as accepting null as an argument

is really a hidden overload of the method

requires the caller to know something about the internal of the method called (that null is a possible option)

reads no better than boolean flag when reading the code

But we had some debate about never returning null. In the case where your method return a collection, it is easy. Just return an empty collection. But what about the other cases?

One pattern that came up was returning “null objects”. A null object is an object that has the same interface as the object you’re expecting from the method, but with no real data behind. A mock, if you wish. The problem with null objects is that they don’t really help much when used. You will often end up writing tests like

if (!result.IsNull())
// do something...

which isn’t really much better than

if (result != null)
// do something...

In fact, it’s possibly a bit worse, since programmers tends to be unsure if they should do the one or the other, and then end up doing both

if (result != null && !result.IsNull())
// do something...

I’ve seen an API that tried to help the users with this by overloading the == operator for the null object to return true when it is compared with null. But as this was in C#, we got a new problem since this overload was not used by the ?? operator. So now, in the following code:

a and b would no longer have the same value. And since refactoring tools like JetBrain’s ReSharper often will suggest replacing the second form with the first, there is a potential for bugs sneaking in.

Another issue with the null objects is that they may be used for a while, but then they are used in a call that causes an exception. It then becomes harder to debug and figure out where the error originated, since the real problem is not where the exception is thrown.

So more often than not, it would better to just throw an exception if there is nothing to return, and add an extra query method that can be called before asking for the result to check if any result is ready (Is… or Has…).

As mentioned in my previous post, I’ve been on a training course with Billy Hollis about WPF and Silverlight this week. The week was split into two different courses, first two days with “WPF and Silverlight liftoff”, followed by three days of “Design Concepts, Architecture, and Advanced Capabilities for Silverlight and WPF”. Some were only attending the first part, others only the second, but we were about half the class there for the full week.

Except for some experimenting, I have not done any serious development with WPF myself before this course, but I hope that I will get some chance to use it as it seems to ba a very good framework for user interface development. Last night, I played around in Expression Blend in my hotel room, and found that I had a much better grasp of the tool now than I did before, since I had learned a bit of the basic concepts on this training course. I suddenly found that the time had gone by and it was well past my normal bed time before I put my laptop down for the night.

Billy Hollis spent two half days talking mostly about design. He emphasized that we must leave the very standardized grafical user interface that the industry have been used to the last thirty years. It is now time to create something better. Once upon a time it made sense to have everything look the same for consistency, but now that so many applications are living on the web, the consistency is gone. The focus should now be on creating usable and beautiful software. When the software looks good, the users will feel good about it, and even have a higher tolerance for errors than they will have otherwise. I think the most important part of making good looking software is to make it feel natural. It should be intuitive for the user how to perform the tasks at hand.

Good usability and good user interface design is not easy, particularly not for the typical analytical software developer. At the course, Billy sent us out in the buildings (the old terminal buildings at Fornebu, the former airport of Oslo) looking for examples of good and bad design in the real world. He encouraged us to get into the habit of noticing the design of the things around us, to better learn what works and what doesn’t.

When software is designed right, the results can be amazing, just think of the experience you had the first time you saw a nice iPad app.

This week I’m attending a couple of training courses on WPF and Silverligt given by Billy Hollis. So far it has been very interesting, and I’ve learned a bit of new ways of thinking about GUI and design.

One discussion we’re having among the colleagues who are here, is how much of this we will be able to use later. Since we’re working on a huge legacy application, mostly written in C++ with the GUI in WinForms on C++/CLI, we have to be careful about trying to be to creative. There is no way we can rewrite the entire application using WPF in a short term, so any use of it will have to be considered very carefully and deliberatlely. However, in parts of the application we’ve already started using new technologies, porting elemenents to new technology with C# and WPF (which is what we’ll be discussing at our NDC talk this summer).