How do you overcome a hardware soul?

The other day this painful article comparing Tesla's AutoPilot and Mercedes' DrivePilot was published:
The War For Autonomous Driving: 2017 Mercedes-Benz E-Class VS. 2017 Tesla Model S
The main point of the article is that Mercedes' DrivePilot isn't working well and the tester also even considers it to be life threatening.

I guess that Mercedes beats Tesla when it comes to the build finish and the feeling of quality, but if what the article and the linked articles say is correct, the current DrivePilot function should be taken out of the Mercedes.

Even though Mercedes has a great deal of money, people and hardware competence, for some reason entering a totally new, software focused area is not working out for them. Or could it be for those exact reasons?

As a rule, having a lot of people and money hinders software development, but let's take a look at another hindrance. I call it "hardware soul". You may be fantastic at hardware development but it doesn't automatically follow that you are good at putting together a great combo where development of software plays a large and important integral part.

At the end of 1980s mini computers were hot and at one time I worked a lot with software development aimed at machines from Prime and Bull. When you bought a mini computer from Bull for example, you got the software bundle practically for free, such as Oracle's database server. It was said that Bull's sales people's performance was measured in the number of kilograms they sold. What was important, what was the soul, was hardware. It's been a long time since I heard of Bull and Prime, but Oracle is doing well.

When iPhone was launched, my company carried out consultancy projects for a traditional large terminal vendor. They invested in software too, but from a solid hardware background. We imported iPhones from the USA at the launch, but when we showed them to our customer to shake them up a little, they were totally uninterested and just laughed at it all. I guess they grew tired of hearing about this several years ago. By the way, I think iPhone is a good example of a combo that had a lot of new thinking when it came, both regarding hardware and software.

There are many other examples: due to their software, graphical cards and printers have created a great deal of frustration over the years. A more widely known example was when "smart TV" started out - the whole experience felt anything but smart.

Could it be that in companies with hardware soul, the software is dealt with in a step-motherly way and those employees that are seen as being the least skilled regarding what is "important", i.e. hardware, are put in just to make it? Or that the "not invented here"-syndrome messes with the hardware soul so they think they are also the best at doing software on their own? Or that they hire the cheapest consultants they can find?

Anyway, there's nothing new here. A colleague mentioned this phrase that stuck with him something like 25 years ago: "You have to see software as the heart and soul of a system, not a coat of paint."

I totally realize that I'm kicking in open doors here. But let's end with what is interesting. As an organization, how can you deal with the problem of having a hardware soul when you don't want to share the same fate as the dinosaurs?

I think that just leaving the whole thing alone and letting it slowly evolve into a balanced soul is a recipe for disaster. Staying true to the hardware soul and skipping the software ambitions is probably a good way of maintaining the status quo for quite some time. But it's also like giving up, I think.

I think one easy solution that stands a good chance would be to start a new, tiny, autonomous organization and leave the old one alone. That way, the soul of the old organization will not fight back too strongly for the new initiative to succeed.

But having just one suggestion for dealing with such a large, common problem is a bit poor... On the other hand, is it really possible to change your soul? As I said in the title, is it at all possible to overcome your soul in order "to overcome a hardware soul"? It's like a teenager telling her grandmother that she looks weird in teenage clothes, but instead of getting the grandmother to relax and accept who she is, she tells her to work on getting really with it. To change her from inside, to overcome, which of course doesn't make sense.

Could that be why I only came up with one good solution and that that solution wasn't about changing, but creating something new? Is the answer not trying to "overcome your soul", but creating a new one instead?

  A powerful gift (tool)

This Easter I was skiing in Austria with my wife and youngest son. It was odd to see a sign saying +14 degrees Celsius when entering a lift gate, but it was still possible to ski. Well, somewhat at least. And only until noon. :)

Yet something I remember even more happened a minute later in the same lift queue. The three of us were lined up next to each other to go in the same lift when a small eight-year-old boy leaves his skiing school group and says to his teacher in English that he wants to go with us. We find it a bit strange and try to gently suggest that he stays with his group, but he's very persistent. Anyway, as we are all going to the same destination it shouldn't be a problem.

As the lift moves away, he starts talking. A lot! And in Swedish. He tells us that he lives in Belgium, but that he's from Sweden. He's fluent in English, German and French. His family has a holiday home on Gotland (Sweden's largest island). And he tells us a lot more. :)

The main reason I remember this small event was that it brought something else to mind. He didn't know us. He had never seen us before. He only heard us in the lift queue quietly speaking Swedish for maybe fifteen seconds. That was all, and he immediately identified with us and wanted to be with us.

What an amazingly powerful gift (tool) it is to share a language, especially in the context of lots of other languages, such as Swedish in Austria. In no time at all, it creates understanding and togetherness. Mind blowing!

As a developer this can be used to a huge advantage if you really want to connect with your domain experts. Make an effort to speak their domain language, and you will stand out next to most other developers.

The opposite is also true. Just try speaking developer language with a domain expert, using words like higher order function, repository and bitwise operation. It only takes a second for them to zoom out, become bored and leave, not just mentally but also physically! If you stick to the domain language, they will love to hang out with you!

As with any tool, the language can be used both to your advantage and disadvantage. Used well, it's a very powerful tool! Used poorly, it's also a powerful repellent!

  Which curve do you choose?

Important code should be tiny, beautiful, and in control. Anything else is a waste of money. To me it's so obvious and internalized that I forget that not everybody sees it like this. It's hard to have a quality discussion with someone if your opinions differ greatly as you will both be puzzled and then – nothing. It recently occurred to me that many people automatically agree that bad software quality is expensive, but don't really believe it deep down.

Let's have a look at two realities (curves) that we can choose between. To many it's a law of nature that it becomes extremely costly to make changes in software. They think that software must rotten over time and it happens pretty fast.

Boehm's curve (from the book Software Engineering Economics) indicates that the cost of correcting an error will increase exponentially over time in a project. I guess it's possible to understand it so that costs will continue to increase after the first version is in production, leading to changes becoming more and more expensive. This means that all decisions must be taken very early in the life cycle so as to not cost a crazy amount.

Of course it doesn't have to be like this. Beck's curve (from the book Extreme Programming Explained) indicates another way it can be; instead of the cost growing exponentially, it will level out.

This is where how beautiful the code is, how large it is and if it is in control comes in. To create the second curve, there are very high requirements for the state of the software and how it is continuously cleaned up, how it is redesigned, and if it has good automatic tests and automatic deployment, and so on. A combination of many well executed actions will lead to the software being changeable. The value of this for the business is, of course, potentially great.

Maybe the two different beliefs are the reason behind stupid decisions you see being made. But when you have realized that there might be the differences in basic beliefs, it's suddenly not so strange anymore. That's not to say that you necessarily agree with the decisions, but when you understand where the other person is coming from, at least it's possible to understand why the choice was made.

By the way, if you think that you and your organization are careful when you develop, but you still arrive at the first curve, then unfortunately it's probably the case that the code isn't all that great after all.

To summarize: if the software is changeable without incurring dramatic costs even late in the life cycle, it will change everything in the software development thinking.

Unfortunately there's a catch. The "flat" curve is way harder to achieve. It's possible, yes, but not something to take lightly. Anyway, it starts with a choice and I will return to how it can be achieved in an upcoming chronicle.

Have you decided which curve you would like?

(First published in Swedish as a developer chronicle here.)

  Don't cheat with the user interface

It's a paradox that many developers who have a large interest in design and maintainable applications often say something like:
"Anyone can take care of the UI, it's not possible to do that much damage there anyway."

Part of the paradox is that the largest amount of code, the ugliest and therefore also the largest maintenance problem, has a tendency to end up in the user interface (UI).

Another part of the paradox is that the success of an application largely depends on the user experience. Sure, the better the code/design is that the UI consumes, the larger the chance that the UI can also be good. But it doesn't happen by itself that the UI code becomes good. In fact, it's often the opposite.

You might recognize some of these examples.
  • The rendering of UI and logic has been mixed into a soup. When the rendering is to be swapped, it's clearly obvious that the logic is affected too.
  • In the large application the logic has been split in different parts - in a good way. For example in accordance to how often they change. The exception is the user interface that is one single monolite where it's very hard to change the different parts separately.
  • After a lot of pain and effort, the team is gaining a lot from automatic testing. Except for the user interface. Unfortunately it often needs refactoring and thereby needs the safety net that automatic tests provide.
  • Good design is used in the domain model, for instance, so that with little code and right abstractions it successfully describes the solution to the problem. But the user interface is done in a "brute force" way, almost totally without abstractions.
Most developers are resilient sorts, but I don't think we should accept what we get from the tool vendors as-is. Tools should often rather be seen as platforms that can be used to develop specific frameworks on top.

If you do as the vendor proposes, you can often expect verbosity in the code and large, hard to maintain codebases. Most often, the vendor hasn't eaten its own dog food. It's not until the tool is used in real projects that the experience and knowledge of what is good and bad emerges - and how the good is used in an effective way.

An indication of the problem is that to most developers design means quite different things, such as in the domain model and the user interface. Of course good software development design in the UI as well is extremely useful (and not only "look-and-feel"-design)!

The user interface has always been important, but has often been treated as the poor relation. The largest maintenance bottleneck is often found in the user interface. Now and in the future, that area requires and deserves to receive a lot of focus.

An interesting approach is framework oriented user interface development. It's anything but trivial to do well. Yet the potential is enormous!

(First published in Swedish as a developer chronicle here.)

  The next big thing is extremely small

In software development we are constantly looking for the Next Big Thing. We haven't given up hope of the silver bullet... one day it must show itself.

It might not be the silver bullet, but I bet a nickel on the next big thing being small, extremely small. We are at the beginning of the era of tiny.

We've had three different eras:
1. The era of following one big vendor and nothing else.
2. The era of using many large open source frameworks.
3. The era of tiny.

If we go 10-20 years back in time, we find ourselves in the time I call "follow one big vendor and nothing else". You found all you needed at one single place. It seemed to be simple and it seemed to be safe. You were taken care of and didn't have to think for yourself all that much.

Often the tools helped you quickly create loads of ugly code that you then had to maintain. There was a lot of focus on "drag till you drop" instead of writing code.

Large database oriented programming models and large solutions to create the illusion that it wasn't the web when you were developing for the web were often used. When the vendors were demonstrating their solutions they often said: "And all this without me writing a single line of code." When you looked at the result behind the scenes it made you cry, but not tears of joy.

After a while some people lost their tempers and there was something of a revolution. About ten years ago and up until now there has been more and more focus on open source and strong communities. Large, generic and important frameworks grew up and were used a lot. Let's call this era the "use many large open source frameworks".

The focus was on agile development, DDD, elegant code, TDD, craftmanship, MVC, O/RM and REST. A lot was good and sound, but a common problem was that whoever used the most number of design patterns in his solution won. It was also now many of us learned – the hard way – that large, generic frameworks shouldn't be invented. The chance of success increases radically if you harvest them instead.

The third stage which is currently emerging is more evolution than revolution. I call it "the era of tiny".

A lot is still around from before, such as test-driven, real DDD and focus on superb code. However, there is a little less focus on using communities and open source projects in order to find all you need in the form of large generic frameworks.

Instead the focus is on turning inwards and solving tasks with tiny, specific framework solutions without all the unnecessary extras. An alternative is to have dependencies to extremely small code snippets that solve one single specific task in a good way. Often those are used as code instead of as binary.

A typical example to make the cooperation between developer and client even better is to use domain-specific languages so that the documentation is also executable.

If you receive the following comment...

    Have you solved the problem with that tiny solution? That's not very "enterprisey".

...then you have done something good.

(First published in Swedish as a developer chronicle here.)

  Developer Chronicle: Too many chefs spoil the code

Let's start with a fairly common question:

"Ouch, we're so behind with the project, what on earth shall we do?"

A response that is just as common is:

"Add more resources! Increase head count as much, and as fast, as possible!"

Honestly, how many people have responded so spontaneously?

Over 35 years ago Frederick Brooks wrote the book "The Mythical Man-Month", where he shows a formula for how to calculate how much the delay increases in a delayed project if you add one more person. How is it, then, that so many think it'll help?

What is even worse, apart from the delay being likely to increase, is that projects with too many people involved have a tendency to lead to a large code base. It is to be expected as a law of nature. It can of course be too large a code base for many other reasons too, but this is one important factor.

Each developer would naturally like to be productive and, just like the others, add X number of lines a day. So the growth of the code base size is directly related to the number of developers.

Even if I am allergic to projects that become overcrowded over time, there's something I dislike even more. That is projects that start to be overpopulated on day one. On top of the problem with too large code base there is an additional problem with X amount of people that are waiting for something to do, which costs a lot to no avail. Pretty soon everyone starts to create their own architecture. Similarly, requirements are created wildly on speculation. The project is simply in a very bad position from the outset.

Why does this happen? I think one reason could be that many people see software development as a keyboard intensive task. Sure, it never hurts to be fast on the keyboard, but it is mostly because the keying should not distract the thinking and the mental models.

If you are twice as fast at the keyboard as your colleague is, are you twice as good as your colleague?

Perhaps, but if you believe a quote from Bill Gates where he should have said that a super programmer is worth 10 000 times higher salary than a mediocre one, your double speed keyboard skills should be a very small advantage. Probably other stuff is way more important.

When I think about it, we have a saying for this phenomenon; the adage is probably much older than Brooks's book and it goes: "too many chefs spoil the broth." So, avoid adding loads more head count on the problem at all costs.

(First published in Swedish here.)

  Developer chronicles

I've been writing the developer chronicle for Computer Sweden (in Swedish) for a couple of months. I'm going to republish the articles as blog posts. The first one is called "Lasagna is not a good role model".

  Developer Chronicle: Lasagna is not a good role model

How about a spot of banter about an architectural phenomenon that I often see in various projects? Since I've made the same mistake in many projects, I guess it's okay to joke about it.

The phenomenon I'm referring to is that there seems to be an architecture principle in many projects which says "the more layers the better." The principle is very common in .net and java projects, especially in the projects known as enterprise projects.

Why does this happen? There are many explanations, but the following stand out as the most common:
  • "It can be good to have many layers. You never know when a layer might turn out to be useful."
  • "Person X / Book Y says it should be like that."
  • "Everything should be similar and follow the same structure."
I think all the reasons above are really bad. The first is an excellent example of accidental complexity. Speculation in advance increases complexity. It is best to resist speculating and make things as simple as possible instead so that they are changeable when, or if, needed.

The second reason is lacking "context is king". No solution is always the best; it obviously depends on the situation.

But perhaps worst of all is the third reason. The code should not be similar because there are different problems and different situations or if it can be similar, it sounds like a serious violation of the DRY (Don't Repeat Yourself) principle. Probably it should not be hand written at all.

Someone wrote a while back that "Architecture is like lasagna. The more layers, the better. "I totally disagree, both in terms of architecture and the lasagna. The taste is not in the number of layers. In fact, that quote makes me long for spaghetti.

What are the drawbacks when having too many layers?
  • When something is changed, there is a tendency that the change affects more than one place in the code due to all the layers.
  • You get tons of completely uninteresting code which means that there is more to read and it takes longer to locate what you are looking for.
In short, it becomes more expensive to maintain.

There seems to be a common tendency for developers to follow a cyclical pattern. At school an early project starts with all the code in a single layer.

Then you move on to an extreme amount, maybe eight to twelve layers, finally becoming situational and allowing the solution to the problem decide the right number.

The approach I recommend is that you do not focus on layers at the start of new projects, but focus on understanding the problem and describing the solution as simply as possible.

As the need for more layers proves itself you add them, but only after having critically evaluated the value relative to the cost.

You won't win by using more layers than anyone else.

(First published in Swedish here.)

  More than 10 000 km apart...

...but the problems are the same.

I was in a phone meeting some time ago with a big Asian company to discuss their problems. They were eight participants, and only one spoke and understood English. So when I said something, the English speaking guy spoke their language and I didn't understand at all. And the same when they discussed things before telling me. The situation and meeting was very tricky and made me nervous and uneasy. Large distances in language, culture and geography... Until they told me about their problems. All of a sudden, the meeting was transformed into well-known territory.

  It works both ways

I've spent a good part of my career trying hard to better understand the businesses I'm developing software for, since that helps *a lot* in delivering more value. This is not anything I'm done with. On the contrary, it's something that I find increasingly important. You can't program what you don't understand. Period.

This works both ways. If a business person wants their software development projects to be more successful, it pays off immediately to show an interest in the projects, to get involved with them and learn more about software development and all the changed and rapidly changing rules. For instance, in order to be able to adjust a software project for the better, it helps if you understand what is going on so you know what you'd like to change.

  Drivers for NOSQL

About two years ago I gave a few presentations about how relational databases are facing more and more competition and that several factors indicate that we will be choosing other ways of storing data in the not too distant future.

The term NoSQL was created last year and has morphed into NOSQL lately (Not Only SQL). This trend is rapidly gaining strength. Below I have written down some of the drivers behind the NOSQL movement. Which ones are missing?
  • TDD and DDD
  • For many, this changes the picture completely. The focus moves away from the storage technology.
  • Application databases instead of integration database
  • Then the storage technology that is used is a private concern of the service/application itself and the decision becomes less dramatic.
  • Internet scale
  • The need for scaling out is changing the scene for certain scenarios and eventual consistency is most often good enough.
  • We don't need many of the common capabilities for certain applications/services
  • And we just don't want to pay a high cost for impedance mismatch if we don't get other large benefits.
  • Querying and analysis finally moves away from the production databases
  • Just an example of one reason why we have less of a need for functionality in specific situations.
  • Certain types of applications don't fit the relational model very well
  • A classic example is "bill of materials". Nowadays social networks is an often mentioned example.
  • Event sourcing is growing in popularity
  • This might mean that you only need a persistent log file for that part, a pretty basic need.
  • Need for rapid schema evolution
  • Or very many schemas, or no schemas.

  New TDD course

factor10's course "Test First with TDD" (or "TDD på riktigt" in Swedish) is given as an open course for the first time in Malmö in Sweden in April. You can find more information and book a seat here.

Oh, and the DDD course is taking place next time in Stockholm in April.

  A new and *good* "VB"

As I write this, the yearly SAW is under way. One of the subjects I put on the table at last year's workshop was that I thought (and still think) it's about time for a new and *good* "VB".

What do you think? Has it become significantly easier to build software since 1991? Have we as a group become significantly more productive? (If so, would you say "yes" even if we take maintenance into account?)

VB had its merits and its flaws, but I think it represented a big shift in productivity for a big crowd. That said, it's not exactly a new VB I envision. It's something kind of in its spirit, but something that doesn't put lots of obstacles in the way of creating *good* software. It should help in creating software that can be maintained and taken further, maybe by more skilled developers if needed after the first successful application is built and used for some time. Probably also in making it easy to involve business analysts, domain experts, testers...

As I wrote here, there is no lack of new RAD tools ("drag till you drop" etc), but they are not focusing on creating expressive and beautiful code, maintainable software. Is it a law of nature that approachable tools must create bad results below the surface? I don't see that. (Please note that I *don't* expect a tool to make design and software development easy, that's definitely not what I'm talking about. I just don't think it has to add lots of accidental complexity either.)

Why so little (no?) interest from the big vendors? It seems quite easy just to harvest some obvious and proven good ideas and concepts to put together in a nice and approachable package to take a big leap, and I think it would represent a huge difference for loads of non-alpha geeks. Sure, it's a moving target, but this might not be moving at all as fast as some of the current RAD attempts...

I put together my own toolbox as do many others, of course. We would probably do that anyway, but that's not the case for everybody. As I understand it, lots of developers go with the tools they get in the single package from the single vendor of their choice.

OK, there are attempts here and there for what I in the header called a new and *good* "VB". Those attempts are as far as I know from small vendors (and open source of course) and I guess this will spread.

Or maybe the "situation" will have been solved at SAW in a few days?

  The DDD course in Malmö

It's time for factor10's course "Fast track to Domain-Driven Design (DDD)" again (in Swedish). This time in Malmö in a few weeks.

  The big picture of software development

Very often when I have tried to understand certain situations that have cropped up over the years and tried to explain where I believe the problem lies, I find myself using a certain simple model again and again. I should have written it up a long time ago, but better late than never, eh?

The model is based on the fundamental questions of Why, What and How.

Why do we exist?
That's a pretty philosophical question. However, in the context of why we as developers exist, why we are needed, why companies pay us to write code, I believe the reason is that we are expected to create business value. That answer would seem to be pretty reasonable for most people in most situations.

What is it that we do to create business value?
I think the answer to that question is code, great code! It's not only the code itself, but its surroundings too, like tests, docs, build scripts, and such. Yet the very code itself is of crucial importance.

If we are in control of the code, then the business people can come with a request for a new feature that will create a new business opportunity and we can achieve it in a matter of, say, a few weeks. A couple of changes in the codebase might translate into millions of dollars. That codebase leads to high business value and the cost for achieving it is low.

The opposite is a codebase that has rotten to the extent that nobody dares touch it at all. The developers walk around it, they even leave the company just so as not to have to work with it. That codebase might need years before it can achieve the afore-mentioned business opportunity. Time to market, risk and cost of change mean that the business value of this codebase is very low.

(There are of course ways of transforming a bad codebase into a great one, but that's another story.)

How do we create great code?
How you achieve great code varies. Some techies would spontaneously suggest Test-Driven Development (TDD), Domain-Driven Design (DDD), architecture-focus, refactoring, and so on. You just add here what works for your team, the stuff that let your codebase add business value.

What I find over and over again is that a good many companies have focused all their attention on implementing a new process. Which process doesn't seem to matter, it varies over time and lately it has been Scrum. It has been seen as a panacea. At first it seems to go very well, but after just a few sprints, the velocity drops. The reason is that the codebase and the architecture haven't received any attention at all... Sure, a suitable process can often help a good team to become even more productive, but it won't compensate for lack of skills. So, I added "Iterative process" as an example of something that is part of the picture for achieving good code. My point is just that it's most definitely not the only thing, of course it isn't. (Also read my factor10 colleague Niclas' blog post called "The holistic view".)

If I had to pick the one answer to how, I believe that the single most important way of achieving great code is to have the best people that you could possibly find. To have only a few, as few as possible, but not fewer. On top of achieving great code that would actually also let you achieve it cheaply. Of course you would have to pay more for the best, but they will be extremely productive (for real, not a fake) and since you only have so few, that also makes the financial side very appealing.

I find that quite a lot of people strongly believe that products will help a lot. After 20+ years in this business, I believe that products are more often the problem than the solution so care must be taken.

In the same way there is the comment about companies believing they need expert help from the vendor of the product they are having trouble with. To me, that's a smell regarding that product.

"We can't solve problems by using the same kind of thinking we used when we created them."
--Albert Einstein

Another silver bullet that doesn't work – on the contrary – is trying to solve the problem by increasing the head count. That's just a good way of increasing the problem and the cost. Quality over quantity, every day!

To summarize what I said above, here's a sketch:

Some more comments
Techies immediately seem to agree with this model. But, and this might come as a surprise, business people seem to like it even more. They might say something like: "So that's why the developers are complaining that I don't value quality. I used to think it was just whining, but now I realize it's about sustainable business value."

Quite often I find that developers ask questions such as: What feature shall I do first? Where shall I focus my refactoring efforts? What automatic tests are the most important? According to this model, there's a clear and simple answer to those questions that points us in the right direction. Choose whatever gives the most business value.

A colleague of mine goes as far as using the code quality of the important codebases for determining if a company will have a chance for success or if it will go out of business. If we aren't fully in control of the codebase, that's a setup for failure. (Obviously, these companies are not automatically doomed, not if they grasp the situation and act with power and intelligence.)

So, the codebase is probably quite important, perhaps the most important asset of the company. It's not something you allow just anybody to work with and make changes to. It's like if you need brain surgery; would you allow someone who had just done a crash course in brain surgery to operate? Of course not, you would probably try to find the best and most experienced person there is. That's quite the opposite approach to how codebases are dealt with in many companies.

  Fast Track to DDD in Sweden

factor10's course "Fast Track to Domain-Driven Design" goes to the Northern hemisphere too, in Stockholm in November by little me. More information (in Swedish) here.

  It should be easy to build *good* software.

Earlier this year I was asked by a large vendor to review an early draft of a new tool. The idea of the tool was to help developers become more productive, that is, to make it easy to build software. But as soon as I started looking, I got the feeling that it wouldn't help the productivity when creating *good* software (and the more I looked, the more apparent it became).

That particular tool doesn't matter, but thinking more about it, unfortunately it actually feels like it's been the same thing for quite a few years and for quite a few development tool vendors. It's obvious we need a much more interesting goal, isn't it?

It should be easy to build *good* software!

  DDD in the cloud

I'm going to give a workshop about DDD in the cloud at Progressive.NET in Stockholm next week. See you!

  Fast Track to DDD in South Africa

I think Aslam Khan has written some of the most interesting pieces related to DDD lately. Now he will teach the two day course "Fast Track to Domain-Driven Design" in Cape Town in early September. You find more information here.

  The CCC-article translated to Chinese

Xiaogang Guo has translated my CCC-article into Chinese. The article will be published in Programmer Magazine in an upcoming issue. You find the translation here.

  Article: Chunk Cloud Computing (CCC)

As a follow up to this blog post I have written an article called "Chunk Cloud Computing (CCC)".

  Some observations over the last few years

Before: Focus on layering
Now: More focus on partitioning

Before: Focus on loose coupling
Now: A balance (include high cohesion)

Before: Huge teams
Now: Extremely small teams

Before: Integration database
Now: Application databases

To be continued...

  NWorkspace == Nilsson Workspace?

I heard a rumor about someone being upset with me because I had named a little framework after my own name. He thought the N in NWorkspace stood for Nilsson. Well... No.
And when I'm at it, that's not the case for NUnit, NHibernate, NPersist, NDepend or NCover either...

  Strategy workshop about Data Access

I've developed a workshop called "Strategy workshop: .NET data access" and Programutvikling in Oslo, Norway, has invited me to run the workshop as an open workshop in a few weeks. You find more information here (in Norwegian).

Here are a few extracts from the description in English:

"There's a lot going on right now in .NET land when it comes to data programmability.
There are many choices available now and each choice has an impact on code quality, maintainability and, overall, bottom line costs.
At the same time lots of .NET developers are starting to embrace Domain-Driven Design (DDD) and Test-Driven Development (TDD), which change the scene much more than most people at first realize.
Suddenly, the choice of data programming options is a strategic decision. What data programming option must I choose so that my teams can spend more time on solving the problem and less time on how to get and save the data?

  Oredev 2008

There is going to be a DDD-track at Oredev this year - the first time this has happened at a conference. I'm going to be giving a presentation in that track, which I have also been given the honor of hosting. The other speakers are Randy Stafford, Dan Bergh Johnsson, Einar Landre and Eric Evans.

Of course there are more DDD people around, such as my factor10 colleague Aslam Khan from South Africa. I'm pretty sure he will be DDD-centric in his talks as well as in his workshop. Other DDD-centric presentations will be given by Patrik Löwendahl, Rickard Öberg and Claudio Perrone.

  DDD anti-motivation

OK, I've published a long list of very positive blog posts about DDD. Now I think it's time to balance that a little bit with some problems. Here's the first one:

New (to most developers)

Even though DDD in itself isn't at all new, it's new to those that haven't tried it before, of course. And if you work in a big team with no prior experience of DDD, then it's very risky using it for a new and time constrained project. There are ways of reducing the risk, but it's still there and it's real.

As a matter of fact, DDD is new to most tool vendors as well. Unfortunately that means that quite often the tools don't help us that much. Sometimes they are even more in the way than they are helpful.

  Swedish surnames

A friend of mine here in Sweden told me a story about when he worked for a large telco here in Sweden and they sent him to one of their offices very far away to work for a few weeks. When he arrived, he was treated as a king and he couldn't understand why. But after a while he understood that they thought he was the son-son-son of the founder of the company Ericsson since his last name was just that. Here we wouldn't think like that since Ericsson is a VERY common surname here.

Another very common surname in Sweden is Nilsson, the second most common actually. Even so, more or less every week I hear somebody who thinks that one of my colleagues in factor10, Niclas Nilsson, is my brother. That's not the case. I just wanted to work with him because he is brilliant and very nice.

Something I'm not that used to though is what happened the other day when Niclas met an old student of mine. My old student asked Niclas if I'm Niclas father! Hey, I'm not even three years older than Niclas...

  Strategic Design (DDD Motivation 7)

A single domain model and a single application typically aren't isolated things, without anything around them. You need to think about the big picture as well. Strategic design is about that.

Eric Evans has said that if he were to rewrite the book, he would put the chapters on Strategic Design at the front of the book and not at the end because nobody reads that far but that part of the book is perhaps the most important.

I know, this is no reason for you to try out an alternative to database-driven design because strategic design isn't the opposite at all, it's not at the same level. No matter if you go for db-driven design or domain models, I think strategic design is very important and therefore it felt important to mention it as a reason to have a closer look at DDD.

  A new course on implementing DDD and LINQ

My factor10-colleague Anders Janmyr and I have developed a new course on implementing DDD and LINQ. Anders will teach the course for Cornerstone in Gothenburg and Stockholm next week as well as in December. You can find more information about it here (in Swedish).

  Have you heard about LINQ?

I'm pretty sure you have, of course. The father of LINQ, Erik Meijer (Microsoft), will be giving a mini-event together with factor10 in Malmö on October 3rd. It's free of charge. Read more about it and register here (some of the information is in Swedish). First come, first served...

  DP Advisory Council at Microsoft

I've been invited by Microsoft's Data Programmability team to be a member of an Advisory Council for Data Programmability and Domain-Driven Design (DDD). I'm really looking forward to it, it's going to be interesting and a lot of fun. More information here.

  And my book goes farther east!

So cool!

Not only has my latest book, "Applying Domain-Driven Design and Patterns" been translated into Russian (more information here), but now I've been informed that the Japanese translation has been published as well. The Japanese version looks like this:

ADDDP in Japanese

  Dealing with complexity (DDD Motivation 6)

The subtitle of Eric Evans's DDD book is "Tackling Complexity in the Heart of Software". So, dealing with complexity is at the very heart of DDD.

One way I see it is that we would like to work with essential complexity, avoiding accidental complexity. The accidental complexity will hurt us, probably by distracting us so it is not possible for us to take care of the essential complexity.

There will always be some accidental complexity around as well, but we should at least try to partition it out from the very core. For example, don't let the infrastructure mess up your domain model.

  Track chair at Devsummit 2008

One of the highlights of the year is approaching. I'm thinking about DevSummit in Stockholm in two weeks' time, where this year I have the honor of being track chair. My track is "Building for the Enterprise" (some of the page is in Swedish).

The theme I came up with was that when building for the enterprise it's not just the big things that matter, but also the "small", daily things. They both matter a lot, so there are presentations about the coarse grained things that you probably decide about only once in a project. For instance, how to apply enterprise scale middleware using the cloud as the middleware and, perhaps, applying a new paradigm, like composite-oriented programming. There are also presentations about more fine-grained things, the sort of things that you think about every day, such as developers' ethics, how every single code line matters and how to test.

Those speaking will be: You're going to love it!

  TDD-supporting (DDD Motivation 5)

Quite a few have tried, and failed with, TDD. Pretty often I believe they have tried to use TDD for an old application structured with Transaction Scripts together with an Anemic Domain Model and quite often every test will touch the database. TDD just doesn't work well in such a situation before you have taken pretty big steps to make the whole situation more test-friendly.

On the other hand, if TDD is used together with an application that has been structured according to DDD, I find the combination is very strong and you don't have to fight to make it work. (Sure, it still requires a lot of work and attention over time, but it's much more harmonious.)

I have quite often been asked whether you should choose DDD or TDD? To me, that's obviously a question that I want to answer with "both". When I have a first sketch of my model, I try it out with TDD. It's like thinking about the model from DDD as a clay model, and the tests of TDD are like hands working the clay.

  O/RM might potentially save manual code/time (DDD Motivation 4)

It's a bit dangerous to declare that you will save a lot of time by using O/RM instead of writing manual data access code. There are situations when you won't, but when O/RM fits well, it can save a lot of time and free up resources that can be put on the core logic instead of the data access logic.

During work on a large application I made the following observation. When I needed to make a change regarding data access that only affected the code using the O/RM, it was done radically (almost a magnitude) faster than when I needed to make a similar change to code where manual data access code was used (because of optimization).

But before you see that potential save in code/time, you do of course have to pay a learning curve. Nothing new there. All new tools/techniques have a learning curve that will kill your productivity for a while, but hopefully you will come out and be more productive than when you started.

  Do you prefer better or worse code over time? (DDD Motivation 3)

Have you ever worked on a code base that gets worse and worse over time? I would guess all professional software developers have at some time, and I have for sure. At the same time, I think most of us value maintainability very highly, and maintainability is very dependent on good code.

Of course, one way of getting better code over time is to use refactoring, but another is to add knowledge to the code as you learn more about the model by applying those examples. All of a sudden you might see a breakthrough in your code, so it's not just about small incremental improvements; sometimes it can be pretty dramatic.

Eric Evans talks about how we shouldn't expect the first model to be the best, or even good. It might take several versions of the application until a really good model shows itself. For that to happen, you have to keep the code extremely nice and clean all the time.

I remember one specific application a few years ago where I saw something like this happen pretty clearly. We had built a new application and it was up and running in production, but there were numerous requirements for the next iteration that were hard to fit into the code without creating a mess. After a while we came up with an "activity" abstraction. I know, in hindsight it's almost silly to talk about it because it's so obvious now. Isn't it always like that afterwards?
Anyway, the abstraction couldn't be found in the domain, so it wasn't just a matter of listening to the domain experts and just building what they said (it never is of course). We invented the abstraction and, after much arguing, we and the domain experts decided that it would solve lots of problems in the current application as well as deal with the new requirements. The production manager was pretty skeptical at first, but six months later she told us that she not only couldn't but didn't want to work without the activities any longer.

When this happened, it made the code better, not worse, and in order for it to happen, we kept a tight focus on the code all the time.

Kind of the opposite of this would be the quite common situation where, early in the project, you can hear "we have to set the database design so we can start working". In my opinion, when there is a database focus that, that also means a pretty static view on the solution. That in turn means that new learning will quite often come as hacks in the code base and the code has already started on its way downhill...

  Collaboration and feedback-focus (DDD Motivation 2)

Even though most people agree that waterfall is not the most optimal process for software development, it's still very common to see specs being thrown over the fence from the domain experts to the business analysts, and the analysis documents over the fence to the designers and the design documents over the fence to the developers and the binaries over the fence to the testers and finally to the customers... Information is lost, feedback is at a minimum. All this leads to blame. (Interestingly, blame seems to go both ways over the fence.)

Instead of this blame-driven process, what I think we need is an approach where collaboration and feedback is at the very heart. In my experience this is a much, much better way of working. To me, DDD is very much about that, gathering the WHOLE team around the model and the ubiquitous language and the code. Collaboration and feedback. So powerful!

  Focus on technology or semantics? (DDD Motivation 1)

To me, this argument is in itself almost all that is needed. As technology people I think we are still, after all these years, a bit too quick with technical details, while at the same time the semantics and the business problem/solution isn't getting the focus it deserves. To me, DDD is very much about moving the focus to the most important place and the place that we typically focus too little on.

This is not to say that technology isn't important, of course it is important. Every software solution is comprised from both sides. It's just about where I would like to put more of the emphasis, for example to get a better maintainability story.

  DDD Motivation

Has Domain-Driven Design (DDD) reached its tipping point? It feels like it has. For example, these days we at factor10 get lots of requests about help with DDD, way more than just six months ago. And it seems to be a global trend because the requests are coming from everywhere.

On a recent DDD coaching project I was asked if I could motivate why I think it is more interesting to look at DDD style instead of a more DB-ish-driven design style (typically with Transaction Scripts and possibly with an anemic domain model or recordsets). I thought that was a great question and I'm going to write a series of blog posts about my answers to it. The first one comes here.

  API Design, part I

API Design might to some not be the coolest thing around, but if you ask me it's extremely important. A few months ago I was playing with it a little and came up with a list that is inspired by the Agile Manifesto:

API design manifesto
  • Code over comments
  • Immutability over mutability
  • Testability over encapsulation
  • Context over generality
  • Small and simple over completeness
  • Backward compatibility over revolution
  • Encapsulation over transparency
I know, I need to explain my thinking for each line above. I think I'll put it into a series of blog posts, but first I'd like to improve the list. A few weeks ago I discussed this topic with a couple of friends at a workshop and I got loads of ideas about how to improve it. Before starting the work I also wanted ask around here for even more input. If you have ideas, please email me: jimmy dot nilsson at factor10 dot com.

  Value Safety

While listening to my colleague Niclas Nilsson's presentation called "Dynamic Languages for Statically Typed Minds" last week at PBT Group in Cape Town it occurred to me that what Dynamic Languages lack in type safety, they gain in *value* safety.

Niclas showed that in static typed languages such as Java and C#, if you instantiate an int with 100000000 (one hundred millions) it's still an int. If you then multiply that int by itself and store it in the same int, it's still an int, but the value is 1874919424. Doesn't look right, does it?

If you do the same in Ruby, instantiate a member with 100_000_000, it's a FixNum. If you multiply that FixNum by itself, it becomes a BigNum. But the value is 10000000000000000 which seems to be more correct than in the Java/C# case. Type safety? No, but Value safety!

  Code Litmus test

A few weeks ago an email was going around about how you could diagnose a stroke without any medical training just by answering three simple questions and get the person to the doctor in time for treatment.

I spoke to my colleague Andreas Brink about using that idea in another context, a little less serious one such as code. He said immediately that only one question is needed and that would take people without much development experience a long way. That question is "Is there any duplication?" Lots of other problems boil down to that simple question. I'm sure we can get Andreas to expand on this further...

Another similar question I've often heard is "Is that testable?" (but that requires experience in test automation). Do you have another favorite?

  Volta thoughts

A month ago Microsoft released Volta, which is a technology preview, but to my surprise not very many reactions have been published. Sure, it's been the holiday season, but even so, and some of the comments weren't as positive as I had been expecting either. I quite often find that early comments to newly released stuff are overwhelmingly positive. However, when COmega was released a few years ago, it was also a bit quiet, and then a few years later some of the COmega pieces received very positive comments (such as LINQ). That said, here are a few comments about Volta I have written after a VERY quick look.
  • Several of the early comments were reactions to how making the network jump implicit again seems to be a step backwards after the recent trend of making it explicit. Sure, I also reacted to that, but as I see it, design never goes out of fashion. You should still make informed and conscious decisions about the design regarding network jumps. Volta gives you a very simple programming model for doing it.
  • The new idea (new to me at least) with Volta is the IL to IL-rewrite. An example that is shown is to use declarative annotations to a Volta WinForms application and thereby make it distributed and with asynch methods. This is just an example of the rewrite-technology. What's the next thing we'll find we need in this space? Very interesting!
  • Retargeting is also very interesting of course. The current example of that is to write code in C# and retarget it to JavaScript.
  • Volta promotes a focus on the core, a focus on the interesting stuff, the domain problem. The other stuff (infrastructure/plumbing) just distracts and shouldn't uglify our code. That's pretty much what I talk about all the time, but Volta's approach is pretty different from the route I normally take.

  Singapore and South Africa

January starts in a whirlwind with a trip to Singapore for a project and the day after I get back I'm off to South Africa for a workshop. I will also be giving two presentations in South Africa after the workshop; the first at a conference in Johannesburg which will be about LINQ+DDD and the second presentation is called "Is DDD more than Entities and Repositories?" and will take place at an event in Cape Town in collaboration with PBT Group. More information here.

  Two problems collaborating

I don't know how many times it has happened that I have a problem that has mystified me, only to realize after a while that there are two very simple, natural problems collaborating. Does that mean that three problems in collaboration would make it close to impossible to understand and solve?

  Another change

It's been pretty quiet here on my blog for a while for one simple reason. It's been an extremely hectic year! Some of the larger and more unusual things that happened were:
  • A new house
    Not new as in brand new, but new as in another. Moving is really hard work (and we aren't actually done yet - the garage is still full for one thing), but it was definitely worth it!
  • A new bike
    OK, not that big a thing, but a fun thing with an engine.
  • A new company
    I have moved all my work efforts to factor10. We've had a fantastic 2007 and everything is pointing to it being an even better 2008!
But the title of this blog post was "another change". The next change for me is that I have given myself the gift of being more active on my blog for 2008. See you around and Happy New Year!

  Free Our CLR Objects

My friend Kim Harding Christensen had a great idea because of IPOCO and all that. Perhaps it's time for a "Free Our CLR Objects" movement. Let's call it FOCO.


As I've said before, the conference arena in Sweden is very hot. Next week it's time for the third Oredev in Malmö and it just keeps on growing. I'm going to speak about "Applying LINQ" for DDD, so hope to see you there. I think it's going to be a great event!

  Pretty close, but far away

LINQ to SQL seemed so promising... of course there were quite a lot of quirks here and there, but promising nonetheless. BUT, it lacks support for Value Objects. I don't even have a decent workaround, because it won't work decently with querying... However, it might be that something can be done with the expression tree to solve the problem, but...

To give a quick and simple example of what I mean, I find it common that I would like to have Customer and Address as two different classes, but as one table (Customers) in the database. Another simple example, assume that your Order has a Price object and the Price object has a Discount object. In the database, there is just an Orders table...

I was looking forward to a solution out of the box from MS, since I thought that would lead to a wide interest in DDD. To me, the problem with Value Objects is a show stopper, but it might not be that big of a problem for everyone.

The Entity Framework, you ask? Well, I don't know too much about it but it looks to be a giant thing. I'm a bit allergic to giant things, and they seem to be a long way from PI at this point. They have even invented something they call IPOCO which is miles away from PI in my opinion, more like anti-PI... So not even the stuff after Orcas seems to be what I need... Why?

  Our society as a metaphor

We all know that metaphors are hopelessly hard to get right. Perhaps you have heard that awful one about how developing software is just like building houses?
Even so, a metaphor can often be useful when explaining something particular in a certain context.

I came up with another (non-perfect) metaphor today, new for me at least. It occurred to me today that where I live, our society here in Sweden is pretty similar to building software (and it's no doubt exactly the same in lots of places). We try to get rid of as many repetitive, uninteresting tasks as possible, and we do it by automation instead of adding head count. For example we want to have lawn mower robots, vacuum cleaner robots, self cleaning windows, and so on. What we are left with are interesting tasks that we WANT to do on our own and/or that are best done by us, such as playing with the kids, eating and socializing. Oh, and taking care of the robots so they know what to do.


Once again, Anki and Magnus are arranging their very popular conference called Expo-C. A special thing with Expo-C is its focus on the learning experience.

In October Expo-C will be in both Växjö and Karlskrona. I'm giving a tutorial on TDD in Växjö and I will be moderating the seminar days at both locations. See you there!

  My book goes East!

My latest book, "Applying Domain-Driven Design and Patterns" has been translated into Russian (more information here).

Sooo cool!

I just spoke to my publisher and the rights for a Japanese version have been sold as well, although it will be a while before it's available.

  Persistence Ignorance important in the .NET-world now?

The other day I was googling and, to my surprise, came across quite a lot about Persistence Ignorance. That "property" seems to have grown in importance and my guess is that LINQ to SQL is the driving force.

To develop the subject of this post, I think that before too long there will be lots of attempts with DDD in the .NET-world compared with how it is today. We'll see.

  Erlang, take 2

For the last few years, Erlang has been receiving lots of positive comments and interest. One of the most recent examples of that was Ralph Johnson's great blog post the other day called "Erlang, the next Java".

I think it has been something like 15 years since I first "saw" Erlang when some of the creators gave a tutorial for the department at the local university where I worked. I still remember that I just didn't get it, blush... I guess I wasn't alone in that since even Ericsson, the company where Erlang was developed, decided to go another route after a while.

Anyway, that is history. It's probably not too late to try to get it now, is it?

  Power balance?

Who holds the power in today's IT world? The guys with the budget? The testers? The developers?

I would say that the operations department has lots of power in many big companies. The operations department sets the scene and it's relatively concrete and rarely changed... Introducing new things to the operations environment isn't done without lots of calendar time passing and lots of friction along the way. You, as a developer, must have very good reasons indeed to want to take on the task of trying to bring about a change in the operations environment.

I believe this situation, regarding where the power is nowadays, is a very strong reason for the potential success of JRuby (and IronRuby as well). I'm thinking about the possibilities that JRuby brings for the developers, without causing problems with the operations department. I mean that even if the operations department is strictly orthodox when it comes to introducing new runtimes in the operations environment, you can now write apps in Ruby and execute them on the plain old Java runtime (POJR?) that the operations department has probably already decided to support.


I mentioned earlier this year that I have been working on a startup that is currently in stealth mode. We are slowly leaving that mode and have actually started several real world projects for real world customers, it's just that we haven't talked much about it in public.

The company is called factor10 and is a consulting company based in Sweden (Gothenburg, Ronneby and Malmo). The basic idea is that by hiring the best people we will be able to help customers in the best way.

You find the web here:
And the rss here:

What this means for me personally is that after almost 15 years in my one-man-company, I will now have colleagues at the same company. And not just any old colleagues - I'm going to be the stupidest one in the company, but I think that's very inspiring. Just to take an example, my colleagues have a long background in and lots of experience with dynamic languages (such as Python and Ruby) and functional languages (such as Haskell).

Another difference for me personally is that I will be more available for hands-on coaching projects, for instance. However, I'm very much of a doer, so that will still be my main thing.

  Java is dead, long live Java

Not too long after Java started to feel tired and worn out, well, as a commodity at least, JRuby has appeared and is making Java hot again. Not hot as a language, but hot as a platform.

It will be very interesting to keep tabs and see which virtual machine (VM) will be the favorite choice for Ruby two years from now. I've heard some criticism of the C-based VM, so perhaps the Java VM has a good chance, or maybe the CLR VM, when it arrives.

  The law of friction

At a fun lunch-time chat the other day, we collectively decided that the friction has to go somewhere in a project. Assume that for some reasons there is friction between the architects and the developers. That could be solved by letting the architects implement and the developers have a simple, open and direct channel for feedback, say. What happens? Perhaps the friction moves somewhere else, possibly between the new real team of developers and architects and the project managers. How should it be solved? Perhaps to really add the project managers to the team, so the friction moves between project managers and product owners. The solution? You guessed it. Now the friction is between customers and product owners... and you can probably find a solution to that as well...

OK, what happens now? We might have a very big team which means friction as well... So we decide to split it and we have some friction between the teams...

So, there seems to be no perfect solution.
But perhaps we can make an educated decision about where we WANT to have the friction (or rather, where it hurts the least).

  OOPSLA in Montreal

I'm going to be giving the same tutorial as last year (slightly improved, of course) at OOPSLA in Montreal along with my factor10 colleague Niclas Nilsson. The tutorial is targeting both .NET- and Java-developers.

  Ralph Johnson's mission

I had the pleasure of meeting Ralph Johnson (one of the GoFers) a couple of weeks ago, which was, of course, extremely interesting. I found out that Ralph is on a mission to push a certain "concept". Guess which one? It makes a lot of sense...

Yep, you're right, it is DDD.

Ralph was very much in favor of DDD and wanted it to be much more prominent in the industry. He saw it as a major factor to improvements in our industry as a whole.

  JAOO2007: LINQ for Domain-Driven Design (DDD)

As I've said before, I believe LINQ will be an enabler for lots of .NET developers to become interested in Domain-Driven Design (DDD). Kim Harding Christensen and I will be giving a presentation at JAOO where we will show and discuss how we have applied LINQ in DDD-ish projects.

  Buy vs build

The discussion regarding buy vs build for software is as old as software itself. Is it possible to find one answer? No, of course not, but having said that, lately I think that a push towards "buy" is quite common. Of course this is very good in some situations, but quite often I think "build" is to be preferred.

You probably don't want to be standard when it comes to the domain specific parts where you have your competitive edge. It's as simple as that. Another factor is that the business of software development has become much more efficient at building domain specific application (because of domain-focus, agile practices, experience, craftmanship...), while at the same time the standard packages have grown too colossal, often being harder to configure than to build what is needed. It's also the case that typically the standard package won't do exactly as you want, no matter how much you configure.

The time to market with good quality is much better today than before when it comes to "build". Dare to take the build decision!

  Experience reports on DDD

The DDD-site has collected a couple of very interesting experience reports. You find them here.

  Post ADDDP

It's now 13 months since my most recent book (Applying Domain-Driven Design and Patterns [ADDDP]) was released and I have (fortunately) learnt a few things.
Not that I regret what I wrote in the book, not at all! It will be contemporary for a good many years to come, if I may say so, subjective as I am. What I'm thinking about for instance is LINQ which fast approaching, and I believe it might be a signal to lots of Microsoft-developers wanting to go for DDD. I also see LINQ as a technique that solves what I solved with NWorkspace, but without you having to write your own abstraction.

That said, there are clearly things I didn't write much about that I'd like to get to grips with at some point. The first thing that springs to mind is that I don't think I devoted enough space to Value Objects [DDD] in ADDDP. I now believe that they are extremely important in order to understand the heart of DDD and something to explicitly work hard on.

With a rich flora of Value Objects in your model, DDD newcomers would not get the "the-domain-model-is-very-similar-to-the-relational-database-model"-feeling that is quite common. Starting to learn DDD with Value Objects is probably a good pedagogic trick.

The Value Objects are also very powerful in connecting with the Ubiquitous Language [DDD]. What's more, you can use them for creating a little internal DSL (or several, of course) in the ordinary programming language of your choice, without having to swap immediately.

  The competence crisis, part 2

(You find part 1 here.)

OK, so it's hard to find developers to hire. What should be done about it? As far as I'm concerned the obvious answer would be to think about how to boost the ones we already have. I see great advantages in that: you get more for less; the developers will be happier; you avoid the "adding head count trauma"; and if your problem really is to get more things done as opposed to increasing your numbers, this problem is solved.

Of course other companies will come and try to grab your developers seeing how they don't have the people either, so you will also have to become the best possible employer. That will increase your costs a bit, but it is nothing compared to the cost of bringing in loads of new developers and losing lots of old ones. When it comes to customers we usually say something along the lines of how it's much easier and cheaper to keep the old ones than get new ones. The same goes for employees.

Oh, and all of a sudden more people will understand that it's nice to be a developer, so that the competence crisis will lessen over time...

I guess I'm kicking in open doors again...

  The competence crisis

In Sweden at least people are talking about a competence crisis, referring to the fact that almost nobody is studying IT at university these days and that companies are consequently having huge problems finding people to hire. How bad will it be in a couple of years?

When a discussion has been a bit one-sided for a while, there must be some grumpy old man who jumps in and says the opposite. I don't think I'm extremely grumpy and not all that old either, but I'd like to toss a few words into the debate.

Please note that I know there are problems in the lack of skilled people so I am not saying it's not a problem. OK, now that's out of the way, over to my arguments.
  • Nope, I don't see off-shoring as the solution to the whole problem. Sure, off-shoring could be an interesting alternative in some cases, but it's hardly going to be the mainstream solution when the hype is over. And if the project is easy to specify in details, why should humans have to transform that specification into code instead of using another approach? Letting developers and domain experts work together, in one and the same room, is extremely efficient and something you don't want to or should give away easily in many projects.

  • If we look back, we can find several instances of forecasted crises that never happened. One example that springs to mind is the story about the expected amount of horse droppings on the streets of London. Quite some time ago a researcher did some extrapolation and stated there would be an enormous problem a few decades later... then came the car and the problem never arose. (OK, there were other problems of course and you might wish for the horse problem instead, but that misses my point here.) Something might radically change the scene. What will that be? We'll see...

  • Brook's law is well known and often referred to ("Adding manpower to a late software project makes it later"). Even so, strangely enough it's tried every so often, but that's a story for another day. Instead, I wanted to take Brook's law one step further. I quite often "joke" about how late projects should move half of the developers to other projects so that the late project can deliver; and sometimes going down by 50% isn't a big enough percentage. Let a very small, but extremely skilled, team work in peace and collaboration. Get the best developers you can find. Quality over quantity. Even if they cost you twice as much as the average developer, that's cheap if they are three times more efficient. Simple and obvious, isn't it?
To sum up my attempt at an "opposite" opinion, perhaps it's even "correct" that only a few are studying to become system developers. At least if those who are are the most interested and suitable. Admit it, you weren't expecting me to say that!

  Some highlights from Devsummit 2007

Well that's Devsummit over for another year, and I think it was very nice, as always. I'd like to write a few words about what I thought some of the highlights were.

Andreas Brink spoke about how maintenance of legacy code is potentially actually more interesting, challenging and fun than developing new code. He also pointed out that to get use out of TDD, you must first be at a certain level for wanting to create nice, clean code (or at least it helps a lot if you are).

One of my colleagues at factor10, Niclas Nilsson, gave the keynote with the title "Dynamic Languages for Statically Typed Minds". There was one thing in his talk (OK, probably a lot of things, but this is the one I recall) that I hadn't before thought about at all. In Ruby it's easy to redefine the visibility of a method from private to public for testing purposes. This was just one small detail in his talk of course, but I started to think about how much pain I quite often go through regarding this in legacy code.

The unplanned, but common, theme of the architecture track day one was collaboration between different groups and that was definitely the theme of my talk as well. I hear about "us and them" in different projects all the time, but in my opinion a move to "all of us" is what we should be striving for. (No, I'm not saying that there should just be one huge über-project for dealing with every need or anything... but within a project, getting everyone to really collaborate, that's what I'm talking about.) But enough of open-door-kicking-in.

  Chief Innovation Officer

It's probably old news now, but I recently heard that CIOs are changing from Chief Information Officer to Chief Innovation Officer. I really like that. I have the feeling that quite a lot of CIOs are stuck with infrastructure problems and the like, and don't get much of a chance to focus on innovation. But there might be a new trend in sight.

  I'm not alone in having "trouble" with ASP.NET

Ah, sometimes it feels good not being alone in having a certain opinion. All in all, I just don't like ASP.NET! I struggle with it when I have to, I solve the tasks when I have to, but I don't really, really like it. It doesn't work in the way I want it to. I thought it was just me and my incompetence, but perhaps that's not the whole story...

My suspicions were aroused when I checked out Ruby on Rails last year and I liked it straight away. For example, Rails is made for testing from the ground up! Ah!

Recently others have also expressed their uncertainty towards ASP.NET. Perhaps it's not just my stupidity. Might there in fact be a problem?

  Creating good example code is hard

It's hard to come up with good example code in documentation, something I plead guilty to in my own writing. Another example, which I guess lots can identify with, is the documentation by Microsoft. When I search the documentation, it's usually the code examples I look at first, and, for some reason, the code examples most often miss the point...

The other day, a colleague sent me a code snippet from a piece of documentation he had written and it was just great! He didn't invent the example, but took it from real life code. Perhaps harvesting code samples is the thing to do, just like harvesting frameworks has proven to be a good idea rather than inventing them.

  Catalysts for agility

A wise friend recently pointed out a difference in perfectionism levels before and after kids. When you have kids, you're just happy if everything sort of works out at all. Getting close to perfection isn't a realistic goal any longer. So, perhaps kids are a good catalyst for becoming agile? To be able to focus on being good enough?

  DevSummit 2007

The conference landscape of Sweden was like a desert just a few years ago. Now, it's the opposite! All of a sudden, people are coming from all over the world to attend the Swedish conferences, instead of (or as a complement to) the other way around. One of the key players is DevSummit. So, one of the year's highlights for me is just around the corner, the DevSummit conference in Stockholm. See you there!

  Clipper story

Not that long ago I was driving to a meeting in a hurry, when the cell phone rang. The voice on the other end met the “stressed-Jimmy-who-isn't-very-fond-of-salesmen” asking if he was selling stuff, such as clippers. It didn't take long before I realized that this was one of the most embarrassing moments I'd had in a long time, since he wasn't selling, he wanted to buy. Not clippers, but mentoring.

Guess what I got from this patient customer at the first meeting? Mmm...

  Linq is love?

Is it time to focus on Linq? I was planning to do so, but I kind of stumbled a bit, especially when I hit the Entity Framework... Is it just me, or doesn't it seem as if the whole area is a bit messy at the moment?

  Charles in space

Here in Sweden, Christer Fuglesang recently gained lots of publicity for being the first Swedish guy in space. Right now Charles Simonyi is getting almost as much publicity over here for becoming the fifth space tourist.

I love it that young people have some other people to hear about instead of just the participants in Big Brother and other such reality soaps. People to look up to who say that science is fun and important, people who say that learning is fun and important. (That's not exactly the message coming from the average reality soap, right?)

Perhaps I find this important because I have kids myself who I'd like to get into the idea of eternal learning. Or perhaps I simply believe that learning is a VERY important part of our jobs as software developers. Anyway, thanks Christer and Charles for emphasising the fact! Who's going to be next?

  Level of abstraction

Quite often I hear/read/learn something that I didn't come up with myself, but is so painfully obvious the moment I get it. One such moment occurred last summer when a friend said that it's not about *increasing* the abstraction level, it's about getting the *right* abstraction level.

And I think that to a large extent that points us to the DSL movement, right?


On April 12th, I'm going to be speaking at SNUG (Skansk .NET User Group) in Malmö. It's not going to be .NETish at all, so if you mostly work with Ruby or Java or any other platform, please also stop by. I will also be hosting an Open Space session or two. More information here.

  Expo-C at Ullevi

Anki and Magnus are at it again, running a new instance of the Expo-C conference, this time at Ullevi in Gothenburg. Here's the text from the front page of the web site:

Software Legends at Ullevi!

Many legends have performed at Ullevi in Gothenburg - Bono, Madonna, Mick Jagger and Bruce Springsteen, to name a few.

Now it's time for two more legends to enter the scene...

Their music may not sound as good, but their lyrics are the better!

Ralph Johnson and James O. Coplien will perform at Ullevi Conference Centre April 23-25! Yep! Can you possibly miss that?

And their companions are as brilliant:
Dan North, Niclas Nilsson, Rickard Öberg and Jimmy Nilsson.

See you at Ullevi!

For more information, visit the Expo-C Gothenburg web site.

  InfoQ interview

The interview I did with Floyd Marinescu at JAOO is now up at the infoQ site.

  Properties vs. fields - refreshing take from Microsofties

My preference for public fields instead of public properties with no behavior (depending upon the context of course), has quite often led to my being "flamed" (well, a bit). I saw that Eric Gunnerson and Jay Bazuzi blogged about it so now it's not even a valid argument to say "because Microsoft says so!!!".

  Reviewing WWW'2007 Papers

First published here:

Even though I have a background from academia, I haven't read too many research papers and especially not recently. That's one reason why it was especially fun to be on the program committee for papers to WWW'2007. I read eight papers and learned a lot about new and interesting ideas. Afterwards I heard that only one of the papers I read was accepted. I was positive to most of my eight, but the level was obviously very high and only my very favorite made it. It's called "Introduction and Evaluation of Martlet, a Scientific Workflow Language for Abstracted Parallelisation" by Daniel Goodman.

  How to increase the temperature at a business village?

The local business village is called Soft Center. I've been around here for the last 20 years, in fact, ever since it started. In the beginning, only IT companies were allowed, but nowadays it's totally different; only a few of the companies are in IT. Sure, some of them are very interesting from an IT perspective (such as UiQ), but there are still not that many. What's more, in two years' time the university is moving to another town, for reasons of consolidation. Is this the death of the business village? Well, I think not.

You can't just sit there and wait for someone to do something. You have to try something on your own, of course... as tiny as it may be, it's a start at least. And if everybody does the same thing, i.e. try something out, the problem is more or less solved.

We (I and two friends) started to host informal lunch events, which was an extremely simple thing to do, and at the first meeting we not only had a good time, we also started collaborating on a few projects! This was mind blowing, in my opinion.

Now we have an rss feed where we announce small get-togethers, such as the next pub visit (which is tomorrow by the way). And our next step? We'll see. Ideas are very welcome of course!

  Reclaiming BDD

One year ago I learned about Behaviour-Driven Development (BDD) from Dan North. I really liked the concept and tried it out on a real world project, with what I thought were very pleasing results. I thought I had a decent understanding of the concept.

So far, so good. Then something happened. I started hearing about BDD in another context, and that other context seemed to be the only one... all of a sudden, I wasn't sure I had understood it at all.

Let's take a step back. What are these different types of BDD that I'm talking about? One is about creating a tiny, formal, executable language for describing requirements and acceptance tests at a high level. A language to unite business people, testers and developers. A language for describing a situation, describing what's happening and describing the result. Let's call this high level BDD.

The other type of BDD is to do with changing the wording of ordinary TDD. Instead of tests, we should talk about specifications of behavior. Tests should be named with "Should" as a prefix. Let's call this low level BDD.

I think I have been doing the low level BDD for years and still calling it TDD (OK, my prefix has been "Can", but...), so not much new to me there. And if there is something new, I think it's easy to grasp in a few minutes. On the other hand, the high level BDD is different. It's not something I've done before, at least not as formalized, and not as a tool for bringing business people, testers and developers together. To me, it's high level BDD that should be pushed (and pushed hard), not low level BDD, which seems to be the pushers' current choice.

Can I hope for the return of BDD? The high level one?

  I've been tagged

Ah, Frans Bouma forced me to get back to blogging after the holidays by tagging me. So I'm now supposed to say five things about me that people probably don't know and then tag five other people.

I chose the program I chose at the high school pretty much because I expected to meet a lot of girls... Mature, eh?
I had a hard time understanding programming in the two hours that were spent on that subject during high school. The teacher wasn't much better either. In one lecture he wondered who had cut a hole in the cover of the floppy disk that was used in the multi-user storage system. Yep, you guessed it, that was the "hole" the read/write head used...

I'm not all that fond of traveling, unless I can take my family with me. Having said that, coming up is the highlight of the year work-wise with a trip to Arosa in Switzerland, where I'll be attending a workshop next week.

I like to cook. I'm not very good, but I like it. I have tried to eat stone age food for three years now. Not strictly at all, but just an ambition.

Even though we have both an Xbox and an Xbox 360, I more or less haven't played since Wolfenstein. I prefer outdoor activities in my spare time like jogging in the forest, skiing, skating, boating, and so on. Oh, and last week I went horse back riding for the first time in 30 years.

I'm currently working on a startup that for the moment is in stealth mode. More soon...

I tag Niclas Nilsson, Eric Evans, Dan Byström, Gregor Hohpe and Rickard Öberg.