Archive for the ‘Software Development’ Category

Face to Face meetings and Presentation Skills

This has been a very busy week.

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.

Categories: Training, Working Together

Who do we write the code for?

“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:

class InheritedClass {

  public void SetFilter(FilterBaseType filter) {
    this.filter = filter;

  public override object SetNewFilterObject(object filter) {
    object oldFilter = this.filter;
    this.filter=filter as FilterBaseType;
    return object;

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

    // ... 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:

class BaseClass {
  public virtual void TemporarlyDisableFiltering();
  public virtual void ReenableFiltering();

class InheritedClass {
  private FilterBaseType disabledFilter;

  public override void TemporarlyDisableFiltering() {
     this.disabledFilter = this.filter;
     this.filter = null;

  public override void ReenableFiltering() {
     this.filter = this.disabledFilter;

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.

Categories: Software Development

Null objects

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:

var a = result ?? default_value;
var b = result != null ? result : default_value;

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

Categories: Software Development Tags: , ,

Impressions from the WPF and Silverlight Course

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.

WPF and Silverlight training

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

Talking @ NDC 2011

I am really looking forward to going to the Norwegian Developers Conference this summer, and very exciting to be given the chance to speak at the conference together with two of my colleagues.

This is the abstract of our talk:

Modernizing a large desktop application through vertical porting

Schlumberger’s market–leading desktop seismic–to–simulation software Petrel® helps geophysicists, geologists, and reservoir engineers maximize oil and gas reservoir performance. The first version of Petrel was launched in 1998 and was developed using C++.  During the past years, Petrel has gradually adopted C# and .NET technologies through a new managed API, called Ocean, which is built on top of the legacy C++ core and facilitates plugin development.  However, significant parts of Petrel still use a stack consisting of C++ for business objects and C++⁄CLI with Windows Forms for the UI (which is also used in the pure C# parts). In order to utilize new technologies such as WPF, increase developer productivity and decrease maintenance cost, replacing the old C++ and C++⁄CLI stack with a pure C# stack as much as possible is desirable.

In this talk, we describe how we did a vertical port of a subsystem in Petrel, the Seismic Attribute system, from a C++⁄CLI⁄Windows Forms stack to a new managed architecture using C# and WPF. Doing a port vertically means porting the entire subsystem at once rather than porting each layer separately. The Seismic Attribute system consists of user interfaces, storage, advanced algorithms and an external interface which enables plugin development of new algorithms with custom user interfaces. Porting the old C++⁄CLI–based system to a new managed architecture is thus no small undertaking.

We will describe the considerations which led to us doing the vertical port versus keeping the legacy system, the WPF–based Model–View–ViewModel (MVVM) design of the new system, how we integrated our new architecture with the rest of Petrel, how we collaborated with teams doing ports of other parts of Petrel, new innovations resulting from the porting work, and – most importantly – mistakes and lessons learned.

Clean Code

“A Handbook of Software Craftsmanship” – this was the intriguing subtitle of Robert C. Martin’s book “Clean Code” that I picked up at the JAOO conference in Århus, Denmark, last October.

The book really served as an eyeopener for me, and it made me think about how I can improve in my craft as a software developer, and how I can help the people around me improve.

There are a lot of problems that can arise in your code if you are not careful when writing it. The book brings many different heuristics for how to make your code better, and I recommend it for anyone writing or reading software.

So how can we become better at writing clean code ourselves?

I think the first step is to become aware of the problems, and to see examples of both bad an good code. A book like this can of course help with that, but I think it is very important to have a forum where you can discuss coding techniques and issues with others. In our office, we’re trying to get this by having a software craftsmanship study group where we, about once a month, get together and discuss topics about our craft. We’ve started by going through the chapters of Martin’s book, and it has been creating some very good discussions so far.

I’ve noticed that since I’ve started to think more about clean code, I’ve changed my view of coding. Code that I used to find quite good doesn’t look so good any longer now that I’ve learned how much better it could be. I really appreciate code that is readable and maintainable, and I find that these factors usually are more important than other quality attributes like performance. This is of course not always true, but a great deal of our code is not run in critical inner loops, and I would much more have it well readable and maintainable than super fast.

I Am Not What I Code

While driving to work one morning last spring I was listening to a political program on the radio. There was a debate about a report the government has presented to Stortinget, the parlament. Two politicians where in studio, one from one of the governing parties, and one from the opposition, from the concervative party. What struck me was how unwilling the person from the side of the government was to listening to critisism.

Naturally I wrote it off as her being a politician, not willing to see the other side of the matter. But somehow it sounded like there was a bit more to it.

After a while it struck me – she had probably been involved in the work to create the report, and the other side was picking it apart, saying that the handcraft of the work was not very good. On some level she must have been reading the attack on the report as an attack on herself, probably unconciously. So she became very defensive, and would try to attack the opposition instead of answering the critizism or admitting that they could do some things better.

This made me think about how we work in software development. A healthy development process should always encourage team work using tools like peer reviews and formal tecnical reviews, and maybe even doing the coding together in pairs or teams.

The idea behind this is that more minds are better than one. Even if I am very good in one domain, I might not always have the best idea. Having someone looking over what I design or code, could trigger an idea in their mind, an idea that I never would have thought of.

But when these tools haven’t been in use regularly, you risk ending up in a situation where people have very strong feelings about their own code. They would object if someone else suggested any changes or wanted to remove their code – not because the change or removal is wrong, but because it makes them feel bad.

It’s not hard to understand those feelings. I know that when I have worked hard on something, it don’t feel good to learn that there is no longer any need for it. But that is the reality. We have to be agile and allow for change when making software, that also includes living with the discovery that something we’ve coded no longer is needed.

What’s important is to not let ourself or our self worth be defined by what we code. If someone is criticizing something I’ve coded, I should listen to it and allow them to come with their thoughts about it – not take it as a criticism of me as a person.

How can we get to a state where this is natural? I believe that having regular code reviews and shared ownership of the code would help getting people out of their silos. If we can get in the habit that all code is something we can improve on, and direct our pride against the wellness of the complete code base and the great working end product instead of the “brilliant” pieces of code that I wrote, I think the end result will be much improved.

Basically I think it comes down to having a strong team feeling.