This post originated from an RSS feed registered with Agile Buzz by Jimmy Nilsson. Original Post: Do you prefer better or worse code over time? (DDD Motivation 3) Feed Title: Jimmy Nilsson's weblog Feed URL: http://www.jnsk.se/weblog/rss.xml Feed Description: Patterns, OO, DB, .NET, ... Latest Agile Buzz Posts Latest Agile Buzz Posts by Jimmy Nilsson Latest Posts From Jimmy Nilsson's weblog

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