Published: Fri, 23 Mar 2012 16:45Copyright: Copyright 2008 by Jimmy Nilsson
Fri, 23 Mar 2012 16:45
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
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.)
Sun, 19 Feb 2012 23:00
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.
Wed, 18 Jan 2012 22:00
Tue, 10 May 2011 20:00
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.)
Mon, 18 Apr 2011 16:05
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".
Mon, 18 Apr 2011 16:00
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:
Tue, 23 Mar 2010 23:50
...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.
Thu, 18 Feb 2010 16:20
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.
Thu, 18 Feb 2010 16:15
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?
Thu, 18 Feb 2010 16:10
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.
Wed, 20 Jan 2010 09:20
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?
Wed, 20 Jan 2010 09:00
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.
Wed, 16 Dec 2009 23:45Very 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 ex[...]
Fri, 23 Oct 2009 15:35
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.
Thu, 20 Aug 2009 17:05
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!
Thu, 20 Aug 2009 17:00
I'm going to give a workshop about DDD in the cloud at Progressive.NET in Stockholm next week. See you!
Sun, 16 Aug 2009 23:55
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.
Tue, 14 Apr 2009 12:15
Sun, 29 Mar 2009 23:50
Fri, 27 Mar 2009 09:50
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...
Tue, 6 Jan 2009 23:25
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...
Tue, 6 Jan 2009 23:20
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?
Sun, 16 Nov 2008 23:58
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.
Fri, 24 Oct 2008 01:16
OK, I've published a long list of very positive blog posts about DDD. Now I think its time to balance that a little bit with some problems. Heres the first one:
Fri, 24 Oct 2008 01:10
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 couldnt 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 wouldnt 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. Thats 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...
Thu, 16 Oct 2008 22:20
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.
Thu, 16 Oct 2008 22:10
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).
Mon, 22 Sep 2008 23:45
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... :-)
Thu, 19 Jun 2008 13:35
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.
Mon, 28 Apr 2008 01:45
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:
Thu, 27 Mar 2008 10:30
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.
Thu, 27 Mar 2008 10:20
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:
Wed, 19 Mar 2008 23:55
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.
Fri, 14 Mar 2008 14:55
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.
Fri, 7 Mar 2008 13:40
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...
Tue, 4 Mar 2008 10:48
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!
Mon, 3 Mar 2008 11:45
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.
Mon, 3 Mar 2008 11:40
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 Im going to write a series of blog posts about my answers to it. The first one comes here.
Mon, 25 Feb 2008 15:00
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
Sat, 16 Feb 2008 00:45
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!
Mon, 04 Feb 2008 23:15
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
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?
Sun, 13 Jan 2008 22:20
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.
Mon, 7 Jan 2008 23:55
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.
Sun, 06 Jan 2008 23:45
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?
Thu, 3 Jan 2008 23:30
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:
Wed, 7 Nov 2007 9:42
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.
Wed, 7 Nov 2007 9:38
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!
Sun, 21 Oct 2007 23:55
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 dont 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?
Fri, 5 Oct 2007 8:50
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.
Mon, 1 Oct 2007 12:05
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!
Thu, 20 Sep 2007 23:55
My latest book, "Applying Domain-Driven Design and Patterns" has been translated into
Russian (more information here).
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.
Thu, 20 Sep 2007 23:50
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.
Wed, 29 Aug 2007 10:22
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?
Wed, 22 Aug 2007 17:10
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 isnt 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.
Sun, 19 Aug 2007 23:12
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 havent 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.
Thu, 16 Aug 2007 01:15
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. Ive 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.
Tue, 10 Jul 2007 01:40
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).
Mon, 02 Jul 2007 14:00
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.
Sun, 01 Jul 2007 23:55
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.
Fri, 29 Jun 2007 16:20
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.
Fri, 29 Jun 2007 16:15
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 wont 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!
Fri, 29 Jun 2007 16:10
Thu, 14 Jun 2007 08:20
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.
Thu, 14 Jun 2007 00:30
(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... :-)
Mon, 04 Jun 2007 23:55In 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 c[...]
Mon, 04 Jun 2007 09:55
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
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, Im 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.
Sun, 03 Jun 2007 23:55
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.
Wed, 30 May 2007 09:00
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?
Mon, 14 May 2007 11:37
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.
Thu, 10 May 2007 11:15
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?
Thu, 10 May 2007 11:10
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!
Wed, 18 Apr 2007 23:40
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...
Tue, 17 Apr 2007 23:38
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?
Tue, 17 Apr 2007 23:30
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?
Mon, 16 Apr 2007 23:50
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?
Tue, 10 Apr 2007 12:45
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.
Sun, 25 Feb 2007 22:25
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:
Sun, 25 Feb 2007 22:20
Tue, 20 Feb 2007 11:55
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!!!".
Tue, 20 Feb 2007 11:52
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.
Tue, 20 Feb 2007 11:50
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 cant 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, its 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!
Sun, 18 Feb 2007 23:55
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?
Wed, 10 Jan 2007 23:50Ah, 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. 1. 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... 2. 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. 3. 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. 4. 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. 5. 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. [...]