Domain Driven Design – Part 1: Shared (Ubiquitous) Language – This Seems Familiar

On the recommendation of my manager, I starting digging into the on-line version of the book Domain Driven Design Quickly. I found it a bit hard at first, not to read, but rather to stomach, for about the first 30 pages or so I felt a little bit… talked down to. While some of the terms being used, such as ‘Ubiquitous Language’, might have been new, the concepts behind them were anything but. I realized that these concepts were not just ‘not new’ to me, but that they were old, old enough to pre-date my time as a Java programmer. Back in the heydays of the dot-com boom, I had made my start in technology not programming Java, but rather creating workflow applications in Lotus Notes, and as part of that work I had to practice much of what is being described in this book.

Like using a shared language.

Specifically what I did in that time was mostly consulting work involving supplanting existing paper-based systems with Lotus Notes-based ones. That kind of work requires domain knowledge, in fact, it was almost nothing but domain knowledge combined with what by my modern measure would be only a small bit of programming. In every case, job #1 was not the code, but to get a hold on what the clients were doing in their real world processes. Once that was achieved, then the job was to find a way to recreate it, as faithfully as possible, in the digital realm, and maybe, if we were lucky and had time, see what ways we could optimize our new (old) system to make it more efficient. I learned very quickly that without the domain knowledge, you were never going to get the design right.

Now of course, the people I was working with to get the domain knowledge were not programmers (if they were, they wouldn’t have needed me) so that’s where the shared (or ubiquitous, if you want to waste three syllables of your time) language came in: it was my job to learn their language. More importantly, it was my job to get the concepts present in their language into my head and then translate those into a digital form that retained those concepts. This way, even though the end product was something new, it remained familiar to them and therefore as easy (hopefully easier) to use as the original paper version.

Of course, that’s not nearly all there is in the book, but that’s the first main bit. Know Your Domain. Luckily, it’s something I got introduced to very early.

House Rules for the Planning Game

One of our product teams uses something we call the Planning Game to come up with a collective view on what we are likely to get done in the next few iterations; it’s a minor variation on a common agile technique called Planning Poker. Briefly, a business analyst proposes a story card for inclusion in a future release; developers assign a difficulty score; and the business analyst places the card on a matrix with V columns and N rows, where V = velocity and N = number of iterations being planned. We colour in a number of squares proportional to the story’s difficulty, which keeps us from cramming too much into a single iteration. The business analyst can (and does) move the cards around as it becomes clear which ones are hard and which are most valuable.

Our good friend and frequent visitor Antony Marcano suggests we consider another variation called a Story Matrix that he and Kerry Jones have used successfully. The main difference is that the estimation process occurs more visibly, with comparisons between different stories made explicit. And Antony has an even more complex and clever idea involving a matrix with both difficulty and value reflected on it (please blog this Antony!)

Do we need these more refined versions of the Planning Game? Probably not on the small product where we currently use it, but they might help us on the larger product that doesn’t work this way at present. Are you using a Planning Game variant? How well is it working for you?

More Javascript goodness.

As we move more and more into programming in Javascript, it’s helpful to try to keep as many of our good Java habits as possible – although each language does come with its own particular idiosyncrasies. One of Javascript’s bad habits is the pollution of the global name-space. There are a couple of ways we can reduce our risk of collision in the name-space, one of which is the use of the module pattern. The author of the article below isn’t so fond of it, as you might be able to tell from the URL, but he does an excellent job of presenting not just the pros and cons of the pattern, but the pattern itself in a very clear and efficient manner. – Why I don’t love JavaScript’s Module Pattern

May I See Your Gold Card?

Steve Freeman reminded me the other day about the notion of a Gold Card. Briefly, this is a card on your kanban board that indicates a developer is working on a self-motivated task, not one prioritised in the normal way. Each developer has a fixed budget of gold cards (say one or two a month) and each card represents a strictly timeboxed period of work (half a day or a day, perhaps). During the gold-card time the developer can work on any feature in the product he or she chooses; often the task involves trying a new tool or process, or writing a spike version of a new feature. When finished, the developer shares what he or she learned from the task, and often the ideas developed turn into normally prioritised stories that the team can work on in the normal way.

One of our development teams has occasional short periods when everyone seems to slow down a bit and take a breather – this is probably healthy because no one can go at full speed forever, but we don’t have a good way to take advantage of this need for periodic change of scene. Thus when we hit one of these slowdowns, we just operate less productively for a few hours or a day until everyone recovers. Gold Cards may be one way to meet the natural human need for a break without slowing down overall progress.

Our other development team uses a different method – they have one planned slack day each iteration, when everyone works on one of a number of useful but not-prioritised product tasks. This seems to work well for them, though they are a lot smaller than the other team.

Can you tell us about other teams who have tried Gold Cards? How do you manage slack on your team?

CI Whac-A-Mole – Keeping All Your Slaves In Line

We have lots of Hudson slaves in our build farm, and we like to keep a close eye on how fast the farm as a whole is running. But how about individual slaves? Is each one pulling its weight? Are there some that aren’t even running? Because both Hudson grids and Selenium grids seamlessly handle slaves joining and leaving the cluster, it can actually be hard to tell who’s up and who’s down – and sometimes it feels like you’re playing a carnival game, bringing up one server just to notice a short time later that another has gone down.

These days we have really good uptime from all the servers in our farm. We didn’t replace any of the machines (many of which are outgrown or abandoned user desktops, so not the most upstanding citizens) – but we do monitor all of them using Nagios and Cacti. We get a Nagios email quickly when a machine goes down or just stops participating in the cluster, and it’s pretty easy to bounce it and get it working again straightaway. And we can track historical performance using Cacti – this sometimes points up servers whose performance is deteriorating, or confirms a guess that a particular machine isn’t doing well.

Specifically, we get an alert if any slave:

  • isn’t running (i.e. can’t be seen on the network);
  • is low on disk space;
  • has high CPU load; or
  • has an unusual number of processes or users.

Further, we make sure our Selenium slaves are listening on the right ports, and that Hudson slaves are running the right process (using a Hudson plugin we wrote).

What else do you monitor? What might we be missing from the list above that would keep our slaves hard at work?