www.hans-eric.com

When people talk about tools in the context of software development, they usually refer to stuff like Integrated Development Editors, Automatic Build Systems, Testing Frameworks, Documentation Extractors, or other useful applications that makes their lives as developers easier. Those are all great and productive tools, but they are not the most valuable ones. What really makes an effective developer is the habits he or she possesses.

One such habit, that helps me tremendously in my work, is keeping personal logs. I keep all kinds of logs: a work diary, a solutions log, books I’ve read, ideas I’ve had, a success journal. Well, to be honest, the last one doesn’t have much content; probably because of my Swedish background. For us “modesty is a virtue” and that’s what’s holding me back. At least that’s what I tell myself. 😉

When I keep a journal I prefer a simple format. Usually word documents are sufficient, sometimes with a special header format that visually separates the notes. There are times when I use a Wiki, but since I prefer a chronological order I tend to go with simple documents. They are easier to move around, and with tools like Google Desktop Search there’s no need for firing up a database to hold my straggling thoughts.

I like to think of the solutions log as the bare minimum, something that every developer should have. Of all my journals that I keep, I value the solutions log most. This is because it’s the most useful one, but also the easiest one to update. Whenever I run into a problem that doesn’t have an obvious solution, I follow the same pattern:

1. Search the Internet for a solution. Nine times out of ten this puts me right back on track within minutes.
2. If I can’t find a solution on the Internet I ask a colleague.
3. If a colleague can’t help me (this is also a nine out of ten-er), then I have to find the solution on my own. This is a tedious task. Good thing it doesn’t happen very often.
4. I document the solution in my solutions log.

My solutions log have the form of Q&A. But instead of questions it has problems, and the answers are called solutions. My P&S (as I call it) have helped me many times, because problems have a tendency to resurface. When they do – often years later – I know where to look for a quick solution.

I’m also very fond of my book log. I read a lot of books and to keep a track of them I make short notes. I don’t write fully fledged reviews but small notes on how I found the book and what I learned from reading it. Whenever I come across a topic I know I’ve read about, I consult my book journal. The notes there work like triggers that bring back the memories of the subject.

This was the first post in my new series: Tools of The Effective Developer. If you have an idea you want to share of an invaluable tool, send me a comment and maybe I’ll add it to my Blog Post Ideas Log.

Cheers! 🙂

In my previous post I mentioned that I wasn’t sure of how the D Contract Programming feature works in an override scenario. Wekempf inspired me to delve deeper into the matter. Here is what I found.

Contract Programming states that preconditions may be weakened by a deriving class, but never hardened. For postconditions the reverse is true: they may be hardened but never weakened.

The D Programming Language specification states:

“If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied.”

In my experience this isn’t the case. Consider the following code:

class A {
  void f(int a)
  in { assert(a > 0); }
  out {}
  body {}
}

class B: A {
  void f(int a)
  in { assert(a > 1); }
  out {}
  body {}
}

Method B.f overrides the corresponding method in A. If B.f is invoked with an argument of 1, the in-clause of B.f should fail and A.f succeed. According to the specification only one of the two needs to be satisfied. Let’s see if that’s true.

A o = new B;
o.f(1);

The program halts with a contract failure in B.f. The preconditions of the base class is never even checked.

What happens if I add a call to the base class method?

class B: A {
  void f(int a)
  in { assert(a > 1); }
  out {}
  body { super.f(a);}
}

It turns out that the super-call triggers the in-clause of the base class A (and only that one). It seems like the semantics differs from the statement in the specification. The current behavior opens up for abuse of the general principles of Contract Programming by allowing preconditions to be hardened and postconditions to be loosened.

I don’t care all that much though. To me it seems difficult to have the language enforce those rules anyway, at least while keeping the contracts flexible. And, the current behavior is what I’d expect if I wasn’t aware of the Design by Contract principles.

Update: It turned out that this feature is currently not implemented in the DMD compiler.

If you are a defensive programmer like me, you make heavy use of assertions to guard assumption you make in your code. For example, a method for adding an order item to an order object could look something like this:

class Order
{
  private List orders;

  int addItem(OrderItem item)
  {
    assert(assigned(item));
    item.order = this;
    assert(assigned(items));
    items.add(item);
    assert(items.count > 0);
    return items.count;
  }
}

This style of programming adds some clutter to the code, but makes the program more robust and reliable over time.

The D Programming Language have built in support for contract programming and I have been curios to see if that can be an alternative to my defensive programming style. At first look it seems to be a close match. Both techniques allow you to make safe assumptions in business logic code. The difference is where you put your defensive code.

In contract programming, or Design by Contract as it was originally called, there are the concepts of pre- and postconditions, conditions that are expected to be met on the entrance to and on the exit from methods. Additionally you have the concept of class invariants, which asserts a certain state before and after (but not during) a method call.

So, a transformed contract programming version of my defensive style example above could look something like this:

class Order
{
  private List orders;

  invariant { assert(assigned(items); }

  int addItem(OrderItem item)
  in { assert(assigned(item)); }
  out {assert(items.count > 0);}
  body
  {
    item.order = this;
    items.add(item);
    return items.count;
  }
}

This may not seem like less clutter but it does two important things: First it separates the defensive code from the business logic. Pre- and postconditions are neatly placed in in- and out-blocks, while business logic dwells in the body-block.
Secondly, general assertions that may need to be checked in every method of the object (like checking that the orders list in the above example is assigned), are handled in in place: the invariant block. Nice and DRY.

It seems like I could use Contract Programming for the same purposes as the normal defensive programming technique, but there are a couple of issues that keep me from taking the step:

1. I’m not sure how preconditions and postconditions are affected in an override scenario. The language specification says that preconditions are OR’ed together, meaning that if one precondition passes the others are ignored. My own tests show a different behavior, but I need to take a closer look to be sure.
2. Contract Programming and Normal Defensive programming are conceptually two very different things: Contract Programming, like the name suggests, are taking place in between the programming interfaces of objects, while the assertion defensive style is more general. You can say that Contract Programming defends the Program Design against abuse, while the defensive programming style defends the implementation against unexpected events.
3. Contract Programming moves the defensive code away from the code that benefits from its protection. This could become a maintaining problem.

I currently feel that Contract Programming should be used only in the context for which it was created: big projects with many developers, where a massive (not agile) design phase precedes an equally massive phase of implementation. But, I’ll probably use class invariants to DRY up my general asserts where applicable.

Agile software development techniques have long been utopia for low level system developers. The C programming language has been the most reasonable choice for implementing hardware near applications and drivers; But C was not designed with agility in mind. Hence methods like test driven development has been a pain to implement using C.

Now an alternative exists: The D Programming Language is designed to combine the low level programming abilities and performance of languages like C and C++, with the productivity features of modern languages.

You could describe D as C with features like object oriented programming, exception handling, garbage collection and design by contract. Cool agile features indeed, but D has another one that I instantly fell in love with: built in support for unit testing.

In D you can declare unittest blocks.

unittest {
  assert(sometest, "sometest failed");
}

The unittest construct makes it very easy to practice test-driven development. For instance, lets say we want to create a new type for three dimensional vectors. In order to be test-driven we need to start with the test:

unittest {
  Vector3 v;
}

We compile the program using the -unittest switch.

dmd -unittest test.d

Of course we get a compiler error, Vector3 is still undefined. Lets define it.

struct Vector3 {
}

This time the program compiles. Back to the unittest. Now let’s try a simple assignment.

unittest {
  Vector3 v = Vector3(1.0, 2.0, 3.0);
}

This, again, produces a compile time error. Vector3 doesn’t have the x, y and z fields, so we implement them.

struct Vector3 {
  real x, y, z;
}

The code passes compilation. Next step: implement vector addition. We start with the test.

unittest {
  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);
  Vector3 vr = v1 + v2;
}

As we expect, the code doesn’t compile. We need to overload the + operator.

struct Vector3 {
  real x, y, z;

  // Overload + operator
  Vector3 opAdd(Vector3 a)
  {
    return Vector3(0, 0, 0);
  }
}

Now the program compiles, but we don’t know if the add operator produces the right result (which it doesn’t with the current code). To check the result we can use assert.

unittest {
  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);
  Vector3 vr = v1 + v2;

  assert(vr.x == 4);
  assert(vr.y == 4);
  assert(vr.z == 4);
}

We compile, and it compiles without error. To run the unittest code we simply run the program. Unittest code is executed after program initialization, but before the main function. If a unittest fails the program terminates prematurely. Our program terminates (as expected) with an AssertError. Lets correct the add operator.

struct Vector3 {
  real x, y, z;

  Vector3 opAdd(Vector3 a)
  {
    return Vector3(x + a.x, y + a.y, z + a.z);
  }
}

It compiles and runs without errors. Great!

As you can see, test-driven development is a very smooth and simple process in D. There is no need for a separate framework, just compile and run your application. Also, the test code dwells close to the production code, which makes it easier to maintain and keep up-to-date. In fact, you can put unittest blocks anywhere in your code, even within the piece of code you are testing.

struct Vector3 {
  real x, y, z;

  // unittest blocks are allowed
  // within structs.
  unittest { ... }
}

Any type of code is allowed within a unittest block. This means that you can declare functions to do repetitive tasks.

unittest {
  function assertEqual(Vector3 a, Vector3 b)
  {
    assert(a.x == b.x);
    assert(a.y == b.y);
    assert(a.z == b.z);
  }

  Vector3 v1 = Vector3(1, 2, 3);
  Vector3 v2 = Vector3(3, 2, 1);

  assertEqual(v1 + v2, Vector3(4, 4, 4));
  assertEqual(v1 - v2, Vector3(2, 0, -2));
}

The test code is only included in the executable if it is compiled with the unittest flag, so there’s no need for a separate test project or conditional compilation. This is a very clean solution, highly suitable for a traditional language that compiles directly to machine code. Although I’m a big fan of testing framworks such as JUnit, I find it much easier to work with the built in unit testing features of D. Of course you don’t have advanced features like mock object support, but I guess that will be offered soon with some kind of unittest-based framework add-on.

If you have doubts about the foundation of the D Programming Language, you should be relieved to hear that it’s been designed by Walter Bright, who have spent almost a lifetime constructing C and C++ compilers.

You’ll find the complete code within my code sample pages.

I am currently employed at a government owned, medium sized company. The company’s IT-division is struggling to satisfy the diverse needs of the other divisions, and is constantly undermanned. One clear indicator of this is multiple project engagement among developers. It has become the default state.
It’s understandable that management give in to the pressure and tries to squeeze the most out of its staff, but unfortunately it is counterproductive. It’s because the more goals you push onto someone, the less commitment he or she can put into each one. And as we all know: if commitment goes down, production goes down.

You form a project to achieve a specific goal, a goal you want to reach as soon as possible. So projects are all about focus, and you can not focus on more than one task at a time. It’s inevitable that you’ll lose time juggling projects. Thus, part time engagement makes projects move slower.

So, what to do? The same things you always do when resources are scarce: prioritize, divide and conquer. Always form teams that work full time on a single project. They will be more productive, and if you’re lucky they might even jell. Let the teams finish before you assign a new task. Instead, see to it that projects are small and can be completed within relatively short time. If a project swells and get big, find the smallest set of features that would still be useful, and form the project around that. Remember, the process of iteration can be applied at the project level too.

Project iteration has several advantages: it increases the closure frequency which helps keeping the teams performance rate high, it increases the chance of success for the individual project, and it releases something useful to the users sooner. And, it provides a constant stream of opportunities for you to make new strategical decisions based on small manageable projects.

To conclude this rather messy post: Don’t mess with my team, let us stay focused and finish what we have set out to do.

Do you work in a team that jell? Then you know the feeling that comes when the team starts to do everything right: solving problems before they even surface, finishing every iteration early, delivering high quality software – while having fun. That feeling is something you will never forget, and you should consider yourself extremely lucky to have experienced it. It’s very uncommon.

One cannot make every team jell. All you can do is provide the basic ingredients and hope for the magic to kick in. All teams in a jelled state have this in common:

• A jelled team has a specific goal, a goal that is shared by all members.
• All members of a jelled team have a high sense of responsibility and commitment.
• All members of a jelled team feel they are accomplishing something of value.
• All members of a jelled team take interest in each others work, since it’s part of their goal.
• The members are enjoying themselves. They long to get to work to spend time together while moving the project forward. Laughter is frequent.
• A jelled team has great communication: with customers, management and in between members.

As a project manager, if your team enters the jelled state you should step back and let the team dynamics do the work. Concentrate on keeping the team jelled, which most of the time is the same as doing nothing at all. Focus on protecting the team from unimportant external interference, and on stuff that boost the team’s confidence and wellbeing.

Appreciation and the sense of completion is very important to keep a team jelled for a long period of time. I once read (don’t remember where) about a team manager that hung a bell in the center of the workplace. The developers were instructed to ring the bell whenever they had done something good. It may sound silly but it’s actually one of the best ideas I’ve ever heard to boost team spirit. Whenever the bell rung people left whatever work they were doing to join the bell ringer and hear about his accomplishments. That team fed appreciation to itself, and provided a constant feeling of accomplishment.

So, how do you know if your team is jelled? Well, one way would be to hang such a bell in a strategic location. If the bell starts ringing on a regular basis chances are good that your team is jelled. If people also leave their workstations to cheer with the happy fellow – then you know for sure.

I have been working on an article for a Swedish computer magazine. The article is to compare Java and C#.NET. In the writing process I have gone through lots of material, mostly articles found on the Internet.

So far the quality of those articles have been varied. Most of them are old and to some extent out of date. But there is one that is high quality: A Comparison of Microsoft’s C# programming language to Sun’s Java programming language, by Dare Obasanjo. This paper was originally written in 2001, but has been updated in 2007 to include the latest changes. If you are either a Java or a C# programmer and have little or no knowledge of the other, that article is all you need to catch up.

During my work on the article of my own, I have come to the conclusion that there are very few major differences between the two platforms. In fact, there is only one difference that makes a difference: Java supports multiple platforms, while .NET supports multiple languages.
In theory .NET could be as platform independent as Java, but the way the .NET Framework API is designed it makes a complete port difficult, although the mono project is definitely an interesting attempt.
On the other hand, in theory Java could be language agnostic too. And there has been attempts to target the Java Bytecode, but no successful ones. Sun doesn’t seem interested in these projects, and are not giving them any official support. The problem lies in the fact that Java Bytecode was not designed to support multiple languages, the main goal was for it to be compact and take little bandwidth when sent over a network. And Sun cannot make major changes to it’s bytecode due to backward compatibility issues.

The bottom line in my article research is this: C#.NET is the best platform for Windows based systems since it was in fact designed for it. Java on the other hand is the only option for systems that are targeting other operating systems.

A common habit amongst us software developers is the practice of sub optimization. If you find yourself thinking “I might use this function/class later, I’d better make it general,” or “I’ll use a static variable since it’s faster” then you are guilty of sub optimizing.
Optimizing prematurely is bad, and usually get you into trouble. It tends to make your code unnecessarily complex and difficult to maintain. A much better practice is what the agile methods, like Extreme Programming, recommend.

1. Write a unit test.
2. Start with the simplest possible implementation to make your test pass.
3. Refactor the code for the purpose of making it easier to maintain, fulfilling the principle of DRY (Don’t Repeat Yourself). The unit test is your insurance that the functionality of the code is unchanged.

If you follow these simple rules, and leave the optimizations until you really need them you will avoid spending time optimizing things that doesn’t need to be optimized (what’s a couple of milliseconds in a process that take several seconds?) You’ll also gain simpler, more readable code and spend less time maintaining it.

I’m a great believer in automating time consuming tasks. Since deploying my rails application (the Forlorn Hope movie site I told you about in my last post) has become increasingly painful I decided to automate it. Today I succeeded. It is not a simple task for someone who’s knowledge in Unix server administration is limited, but I made it! I’m finally there.

The basic ingredient is Capistrano, a rails/rake extension designed to automate the deployment of rails applications (although not restricted to that). I may do a write up some day but for now I will just enjoy my newly won ease of deployment. You know: change a little bit here – DEPLOY! – change a little bit there – DEPLOY! Wah, I love it!

If you don’t want to wait for my write up there are plenty of information on the Internet to get you started. Be prepared for extensive tweaking though.

Installing a rails application at TextDrive
Lighttpd the painless way
You need to install the subversion client
How to deploy your first rails application using Capistrano in Windows
Shovel – Rails deployment with Lighttpd

Some friends of mine got the crazy idea of making a movie of their own. Since I’m not much of a n actor I figured I’d help them by setting up a website for the movie. I picked Ruby on Rails and RadRails for the task, and TextDrive as the host.I have been meaning to bring the code base into version control for quite some time now, TextDrive is offering SubVersion as part of their hosting plan. But since I haven’t had the opportunity to try SubVersion before, I’ve been stalling.

Today I decided to make the journey. I was planning on books to buy and checking the internet for GUI frontends, when it struck me: maybe RadRails have support for SubVersion. I fired up the IDE and – yes! The context menu of the project node contained the promising Team|Share project menu item. You can choose between SubVersion and CVS – GREAT! No need for a GUI frontend.

Now I needed to set up a SubVersion repository at TextDrive. It proved to be a nobrainer using the TextDrive administration web interface (webmin). Back to RadRails. My worries about importing an existing project was swept away as the Share project-wizard guided me through the process. In less than 15 minutes I had gone from having no clue to having my project version controlled under SubVersion. If all my tasks were this easy…

Thank you RadRails! Thank you SubVersion! Thank you TextDrive!