Navigate / search

Not because it’s easy, but because it’s hard.

“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone”

President John F. Kennedy
September 12, 1962

I had an interesting conversation today with our Product Owner (Proxy Product Owner, but that’s another story) about Scrum.

The conversation focused on the issue of demonstrating completed work. We have found that some pieces of work haven’t lent themself to being demonstrated. We’ve let those slide, we’ve cut other corners too.

Today I suggested that it’s time that we start taking things like this more seriously and we should start by at least facing up to the challenge of finding a way to demo everything we build.

The PO (or PPO I guess) is of course the intended beneficiary of these demos, so you’d imagine I’d have an enthusiastic ally. Turns out, not so much. She argued reasonably cogently that it wasn’t necessary to demo EVERYTHING.

Her reasoning basically amount to this. If something can be demoed then great. If demoing will take a lot of effort, then I’m willing to trust the team. If they say it’s done, I’ll find out fairly quickly if it’s not.

On the face of it it’s hard to argue with that, and who doesn’t like being trusted?

I believe that the reason this particular Product Owner is so trusting is that she is in fact a Proxy Product Owner, sitting close to us, and constantly aware of what we are doing. In short, she is in a privileged position that makes the benefit of demos less obvious.

Once you establish that demos are desirable rather than mandatory, you give the team an out that they may abuse.

Woah, hold on there Richard, now it sounds like you don’t trust yourself and the team! What ever happened to self organising, empowerment, all that touchy feely scrummy stuff?

Well, yes, but there’s something to be said for the words of another US President, “Trust, but verify”.

We don’t verify because we believe the developers will pull a fast one, we verify to make sure the developers knew what they were supposed to be delivering. We also verify because it focuses the developers minds on a higher bar than merely “checking something in”

Am I suggesting that the team might claim something was done that wasn’t?
No. Not deliberately, but I do think there’s a chance that the team might think something is done when it isn’t.

Am I suggesting the team might not bother to demo some things that they would be generally be capable of demoing?

Yes, categorically yes, I believe that allowing people to avoid following procedure when it’s too “hard” will serve only to redefine what we consider “hard”. In short, making things optional is likely to lower the bar.

What we are trying to do here is raise bars, not lower them. We’re trying to empower teams so that they can improve from within. We should trust that challenging a team is likely to achieve better results than making the hard stuff optional.

Will we always come up to the standard we set?

No. But that doesn’t mean we should take our failure to do so lying down. Failing to demo something, or indeed cutting any corner should be a big deal, an exception, “too hard” is not in itself a sufficient reason.

We want to maintain a clear and shared understanding of how important it is to not cut corners, without becoming dogmatic. That’s a very fine line to walk.

It is precisely in the things that are hard to demonstrate that demonstrating is most useful. The job of finding a way to demonstrate a feature will in itself challenge us to think differently about the software. Perhaps the difficulty stems from a bad design, or a decent design that could be better, or perhaps it stems from not really understanding the value of the feature to the users.

Even if we have a Product Owner who trusts us and who is willing to give us a pass on some of our responsibilities, we should decline. For our own sake and for the sake of the team.

We, as a team should choose to demonstrate our work and do the other things that our process or framework or methodology commit us to, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone.

Music Moments

A break from the tech stuff tonight and a post I’ve thought about for a long time but never got around to writing. I’ve noticed over the years that there are a handful of “moments” in music that I never tire of hearing. By “moment” I don’t mean a favourite song, or album or favourite lyrics or favourite tune. I literally mean a moment, a word maybe a note, or a syllable.

I don’t really understand why these stand out for me, they just do. Drop me a comment if you too have recognised this phenomenon of musical moments, and let me know what some of your favourites are. I doubt I’m the only one, at least I hope I’m not. Even more interestingly, let me know if any of the moments I describe below strike a chord for you too.

I don’t really want comments saying “jeez your taste in music stinks, try listening to this Japanese group of blind blues musicians that nobody has heard of”. I’m too old for that shit. I’m no longer interested in whether a particular set of soundwaves vibrate my eardrums better than yours. It’s just music.

Without further ceremony, here are some favourite musical moments.

  1. Do You Want To Know A Secret – The Beatles
  2. 37 seconds into this Beatles Track George Harrison sings “I’m in love with you” and it’s the “I’m” that always gets me. For the rest of the song his vocal is soft, melodic, but for that one word it rasps a little, there’s an edge to it. He sings that line exactly the same way twice more in the less than 2 minutes that the song runs to. I don’t think I’ll ever tire of it. The vocal on this stood out for me as a kid before I realised it was George singing.

  3. Fairytale of New York – The Pogues and Kirsty MacColl
  4. “Cars Big as Bars”. There’s an almost imperceptible wobble in MacColl’s voice as she sings the word Bars, I honestly don’t know if it’s really there or if It’s something I hear in my head when she sings, but I love the way she delivers that line, and that word in particular. I did a search this Christmas for as many covers of the song as I could find and really nobody comes close to the performance of MacGowan and MacColl. The whole songs is a masterpiece, but the moment in the song I like most is “Bars”

  5. Cathy’s Clown – The Everly Brothers
  6. The Harmonies on this are great, I didn’t think it was possible to drag a one syllable word like “Love” out to the extent that they do, but the line I like most is “I Die Each Time”. I have no idea why I like it, or why in a song that I like generally that that line would stand out, but it does.

  7. Blue Moon of Kentucky – Elvis Presley
  8. When you listen to the original Bill Monroe Waltz and then hear what the song became in Sun Studios it’s hard not to wonder what it must have been like to turn on a radio in the Summer of 1954 and hear it. I love the whole song, but the line that stands is “Keep shining bright” in the opening verse. It’s got reverb on the vocals, it’s got the slapping on the bass, that Rock and Roll Sound.

  9. Boys Of Summer – Don Henley
  10. This song nails Summer in the way Fairytale of New York nails Christmas. 3 mins 4 seconds in there’s a little guitar riff that I like. I only say that because it’s too obvious to claim to like the “I can see you” line, but dammit I do, I like that line.

  11. Cliffs Of Dooneen – Christy Moore
  12. This song has been in my head for as long as I can remember hearing music. I think this was the first song that made me fall in love with what a minor chord can do. It was only years later when I messed around with a guitar that I realised what a minor chord was. In the line “But of all the fine places that I’ve ever seen”, the word “seen” hits me every time I listen to the song.

  13. Don’t Give Up – Peter Gabriel and Kate Bush
  14. I could listen to Peter Gabriel sing ingredients off the back of a cereal box, but this song stands out as something special even by his standards. I kind of forget sometimes that Kate Bush is no slouch as regards vocals, but for me every word Peter Gabriel sings on this is suberb. There are two moments that stand out for me. About 2mins 49secs in, just after Bush sings “there’s a place where we belong”, there are two notes on the Piano that mark a transition in the song and to my uneducated ear it’s magic. So simple, yet it almost turns into a different song. The other stand out moment is at about 3:25 when Gabriel sings “Got to walk out of here”. Love that voice.

    OK, that’s a few I have lots more, maybe I’ll add them in another post.

Introducing black

This entry is part 5 of 5 in the series FitNesse

black Quick Start Guide

As much as I love using FitNesse, and as much as I love using SLiM to hook FitNesse up to .Net, there are issues.

The data structure that you must create in order to return results from Query Tables is a bit of a headache. It consists of Lists of Lists of Lists and the Column headers are repeated for each row.

The data structure for Table Tables is marginally better, but still a pain.

Finally, sharing data between tables can involve messing around with Static Data and singletons, which means a certain amount of wheel re-invention, when you need to write new tests.

The solution for me has been a little library that takes care of these tasks. There is nothing technically difficult here, just time consuming tediousness.

The library ‘black’ is tiny (because it does very little), but it hopefully does it reasonably well. It’s still a little rough around the edges, but it’s ready to share.

For now I’m publishing the Quick Start Guide, I’ll publish the code on GitHub in the next day or so.

If you use FitNesse then give black a try and let me know if it’s useful, or if there are other features that you’d like to see.

Landing planes and managing projects

To land a plane you need to line up with the runway, figure out the right rate of descent and airspeed, then monitor and manage those, all the way down to the ground.

Your goal is to touch down on the runway, rather than before or after it, while travelling fast enough that the plane doesn’t stall and fall out of the sky, but slow enough that the wheels stay attached when they hit the ground, and you can stop within the amount of runway you have at your disposal.

Simple?

Well, not so much.

How not to land a plane
If you drop the average person with no experience of flying into the captain’s seat, and ask them to land a plane, they will almost certainly get into trouble very quickly. Even if you line them up with the runway and tell them the rate of descent and airspeed they need to maintain, they will probably still lose control of the aircraft.

What inevitably goes wrong is that a layman assumes that you should use the throttle to control airspeed, and you should use forward and backward movement of the yolk or joystick to control the rate of descent. That’s understandable. A plane is just a three dimensional car, and in a car we control speed with the gas peddle, and direction with the steering wheel.

With a plane things are reversed. If your rate of descent is too fast, increase the throttle. This will flatten out your descent and get you back on track. If you are too high, decreasing the throttle will cause the plane to fall faster.

While getting back on the correct rate of descent with the throttle, you control the airspeed by pulling back on the yolk to raise the nose, which slows the plane. If the plane is too slow, pushing the nose down will speed it up.

Landing your first project
Training for new project managers is often either non existent, or amounts to a one or two day course.

Contrast this with the on the ground, theoretical training required by a pilot. For a sense of what a pilot goes through in ground school, take a look here

Landing a plane is actually much simpler than bringing a typical software project in on time. But we impose some of that difficulty on ourselves, by not knowing which levers to pull to control the project.

We seem permanently stuck, like amateur pilots using levers that are intuitive, rather than asking whether we might crash less projects by trying something different. How many projects have run into trouble, only for the corrective action to make matters worse?

Throwing more bodies at a late project, Calling extra meetings, demanding more status reports, introducing or abandoning tools or practices, cutting corners in QA, Version Control, Deployment. Shipping more features with more bugs, rather than less features with less bugs.

Lessons
The pilots teach us a number of lessons that we can apply to projects.

  • Few people have an automatic ability to fly planes, or manage project. These are skills that need to be learned.
  • Pilots can not afford to learn from their mistakes, so the learning is front loaded with serious training that is both broad and deep.
  • The intuitive ways of controlling a plane or a project are often the wrong controls and are more likely to make things worse than better.
  • A layman may have some chance of landing a small aircraft and some people have been “talked down”, but they have virtually no chance of manually landing a large commercial airliner.

This last point is interesting. No layperson has ever been called on to land a “heavy” jet. With the technological advances modern aircraft stand a much better chance of landing themselves than of being successfully landed by a layperson.

The interesting thing about lay pilots is they are significantly more likely to be able to land a single engine light aircraft 10 times than land a jet once. In fact while the first one or two landings of the light aircraft might be a little bumpy, the pilot will likely improve with each effort.

This “many small landings” instead of “one big landing” is the essence of Agile project management.

Are Unit Tests the new Comments?

It’s verging on heresy to even talk of Unit Tests and Comments as being in any way related. They serve different purposes, they work in completely different ways, They have nothing at all in common.

Except…

Comments

  • Document Interfaces, API’s etc.
  • Drive development by writing pseudo code comments first.
  • Mark outstanding work using TODO comments.
  • Explain particularly complicated pieces of code.
  • Leave messages for future developers to help them avoid breaking the code.
  • Document expectations, side-effects etc.
  • Must be maintained to ensure they stay in sync with the code.

Unit Tests

  • Document Interfaces, API’s etc.
  • Drive development by writing tests first.
  • Mark outstanding work using failing tests.
  • Help tease out particularly complicated algorithms and develop them systematically.
  • Leave tests for future developers to help them avoid breaking the code.
  • Test expectations, side-effects etc.
  • Must be maintained to ensure they stay in sync with the code.

OK, I’m using a little bit of poetic license here to highlight the similarities. You can find a handful of similarities between almost anything if you look hard enough. Nonetheless, there are similarities. Automated unit tests solve many of the same problems that comments have traditionally been thrown at.

From Mandatory to Code Smell
Once upon a time comments were pretty much mandatory. Coding standards routinely included rules and guidelines on how to write them. Every file would contain comments as a header.

The Comment Age was so pervasive that relics of that era are routinely found in legacy code. There are even teams that still observe the rituals, and pay homage to the comment gods, despite advances in technology making such worship unnecessary.

Increasingly however, comments are seen as a code smell. With better development tools, and a drive for self-documenting, clean code, some of the major reasons for comments have been mitigated. The notion of aiming for “comment coverage” is absurd. The notion of writing code that is convoluted enough to require explanation is frowned upon.

Unit Tests as a Code Smell
Is it unthinkable that unit tests could ever be considered a code smell? During the Comment Age it would have been unthinkable that comments could become undesirable.

With unit tests we’ve already moved past the idea of setting minimum thresholds for test coverage (or some have, at least). We have higher level integration and acceptance tests that can map to deliverable features and provide a means of catching regression bugs.

Why exactly are tests written at the level of individual code ‘units’ considered inherently good? Aren’t such units by their very nature implementation details? And if they are, why are we testing implementation details?

Ah! you say, unit tests have a function in driving out the development of complicated functionality? Possibly, but we once thought that comments were an acceptable aid to understanding difficult code, we’ve since decided that simplifying the code is better. Is there any reason something similar might not happen with unit tests?

Inside-out vs Outside-In
The Stones vs Beatles debate in TDD is “Inside-out” vs “Outside-In”.

The inside-outers start by unit testing the internal small components of their software and then work outwards composing the system from tested parts. They may or may not wrap the whole thing in higher lever end-to-end tests. These developers are unlikely to believe unit tests could ever be unnecessary, much less frowned upon.

The outside-in developer creates higher level tests first. They may or may not use lower level tests to drive the development of internal components and units.

If the outside-inners prevail in this debate, then the fundamental “goodness” of unit tests may come to be questioned. You may find yourself in a code review some day needing to justify why the high level tests weren’t sufficient. Why did you need to test all the way down to unit level for a particular piece of functionality.

Keeping in sync
Whether or not any kind of tests come to be regarded as a code smell may hinge on the effort required to keep them in sync with the code base. For comments the ease with which comments and code could diverge from each other was a serious problem.

Automated tests have the inbuilt ability to be executed against the code base and report whether or not they are still in sync. However while it might be easier to discover divergence, the holy grail is avoiding it in the first place. If refactoring were to routinely break large numbers of unit tests, that may hasten the day when unit tests are called into question in the way comments were.

The brittleness of tests
There is a perception that higher level tests tend to be more brittle than lower level tests. I don’t know whether this is true, and if true whether it’s a fundamental reality, or just a sign that the higher level tests are being written incorrectly.

In theory, the highest level tests should be focused on what the system does rather than how it does it. The lower we go with tests, the closer we get to implementation details that should in theory change more frequently (at lest they should if we’re refactoring our code).

No matter how hard we try to avoid testing implementation details, if you have a very high coverage of unit tests, it’s going to be virtually impossible to perform any kind of significant refactoring without breaking a few unit tests. It should however be possible to perform fairly broad refactoring without changing the outwardly visible behaviour of the system.

So, where then does the perception that it is the higher level tests rather than the lower level tests that are the more brittle?

I don’t know. We could guess that developers are not refactoring their code to anything like the extent they should or could be. This gives a false sense of security about the extent to which unit tests are decoupled from implementation details. It’s a guess, I don’t know if it’s true.

Less is More
Tests are code. Generally speaking, if you can deliver equivalent value with less code, then that’s a good way to go. If we can get the all or most of the benefits of unit test coverage, by writing fewer tests at higher levels, then that would seem to be the way to go.

The question is can we? Are there inherent benefits of unit tests that can’t be either replicated by higher level tests, or mitigated by technology or techniques?

I have no idea what the future holds for software development, or for unit tests, but history tells us that today’s best practice can become tomorrow’s code smell.

Lying at Interviews

The issue of dishonesty in interviews and on CVs is frankly a topic that bores me. Pinning down the character, suitability or professionalism of a candidate in an interview is notoriously difficult. Catching a candidate in a lie is much easier, and it gives you an answer to those more difficult questions.

What I find much more interesting are the lies that flow in the other direction. Perhaps lie is too strong a word, let’s say the “false impressions” that are allowed to pass from interviewer to interviewee.

What am I talking about? Let’s take a look.

Question:
Can you tell me what the SOLID Principles are, and why they are important.

On the face of it an easy OO Design related question that should give you some idea of the level of programmer you’re dealing with. But, what does it imply?

To me that question implies that your company gives a shit about the SOLID principles. It says that you expect your employees to adhere to them. It says that if I come work here I should expect to be working with a code base that exhibits some attention to these principles.

Is that true?

Question:
Can you show me some code you’ve worked on, have you contributed to any Open Source projects.

This is a great question and it’s finally starting to be asked. Not too long ago if you offered to bring along some code to an interview you’d be told not to bother.

The problem with this question is that it’s often followed by a lie. If the candidate asks to see some of the code written by the team he or she will be joining, they are generally told “we can’t show you that, it’s proprietary”.

This is a lie. In truth it’s an unfair imbalance, open source code is intended to be public, it’s often crafted to a degree that makes no economic sense. Internal production code on the other hand isn’t usually as pretty.

But hey, dems the breaks, and good candidates understand the difference. They’re not hoping to see perfectly crafted code, they’re hoping to get a sense of the raw materials they’ll be working with for the next few years.

The proprietary thing is a lie. No more than about 10% of the code in your applications is in any way novel (if that). There is a ton of boring plumbing code that is exactly like all the plumbing code in every other company.

If you really can’t find one class, or one method that isn’t sensitive and that can’t be shared with candidates, you’ve got bigger issues.

Stop lying about the sensitive nature of your code, be grateful that you’ve got a candidate willing to ask, and don’t risk losing them out of silly pride.

Question:
Here’s a machine with Visual Studio and Resharper involved. Please work through the following programming challenge using Test Driven Development. We’ll observe.

This is a fantastic way of getting a feel for the kind of developer you’re faced with. If you’re really smart you’ll realize that it doesn’t even matter so much how they do on the programming challenge. You can usually tell within 15 seconds of watching someone interact with Visual Studio how comfortable they are. If they are writing and running unit tests and barely touching the mouse, you might just want to hire them on the spot.

But, is there something implied by this exercise?

Well, if you ask someone to demonstrate TDD skills, or if you stipulate it as a requirement in your job spec then yes, there’s an implication that the candidate will be given a chance to use those skills when hired. If that isn’t the case then don’t bring it up in the first place.

Another example is the requirement for specific language experience.
“We need someone with 4 years C# experience, so here are a few questions on C# syntax”

The implication here is that the hardest part of working with your code base is going to be the fact that it’s written in C#. Frankly I doubt that’s the case. Any half decent programmer (and presumably that’s what you’re looking to hire) will have no problem working with any language you throw at them, particularly if there’s an existing code base for them to learn from.

What programmers will have trouble with, even good programmers, is working with your big ball of mud. The syntax of C# can be Googled, there are endless books on the subject. Your code base is specific to your company, it’s probably under documented, and nobody on the interweb has a bloody clue how it works.

Stop trying to give the impression to candidates that as long as they have the equivalent of 4 years experience in some or other language that they’ll be able to be productive with your code base. It’s a lie.

The list goes on, but the bottom line is this, as candidates we should always listen to the questions that we are asked and be prepared to turn them back on the interviewer.

Ask me about SOLID? Be ready to convince me that you’re company cares about them for more than interviews.

Ask to see my code? OK, but show me yours.

Want to hire someone with experience of Agile methods, show me that you use Agile methods.

Want someone with C# experience, or Java, or Ruby, show me that knowing those languages is going to be the only thing that will stop me being productive from day one.

I’m not saying candidates should be brash or antagonistic, but when you’re asked about something that you find interesting, that’s an opening for you to ask whether you’ll actually get to work in that area, or whether it’s just asked as an interview question.

I’m always amazed by developers who tell me they hate interviews and can never think of anything good to ask when they have to chance to ask questions. You’ve just sat through perhaps 30 minutes or more of questions about various practices and technologies. Ask some of those same questions back again and see if they were just interview questions, or whether they are things that are actually important for the position.

Information Crunching and Ubiquitous Language

A well-known scientist (some say it was Bertrand Russell) once gave a public lecture on astronomy. He described how the earth orbits around the sun and how the sun, in turn, orbits around the center of a vast collection of stars called our galaxy. At the end of the lecture, a little old lady at the back of the room got up and said: “What you have told us is rubbish. The world is really a flat plate supported on the back of a giant tortoise.” The scientist gave a superior smile before replying, “What is the tortoise standing on?” “You’re very clever, young man, very clever,” said the old lady. “But its turtles all the way down!”

That old story popped into my head today as I toyed with the role of primitive types in object-oriented solutions. A colleague and I set out a little while ago to TDD what we thought was a simple problem, and perhaps see if it was good material for a Kata.

What we’ve found is that we ended up spending a lot of time touching on aspects of Domain Driven Design like Knowledge Crunching and Ubiquitous Language.

One aspect of what we’re doing is worth a little mention and I’ll write more on the whole exercise later.

The detail of the problem aren’t important for now, but it involves manipulating weights. Initially we were using Integers to represent the Weights, and that would have been fine technically, but we found we were having trouble visualising the domain and thinking about the problem. When we opted to define a Weight class to wrap the integer value, things became clearer.

We could for example add a method to a Weight to divide it into smaller weights, something that we needed for our problem.

But what should such a method return?

var weight = new Weight(5);
var result = weight.BreakInto(5);

What type is the variable ‘result’, in the above code. Clearly it’s not a weight, it’s 5 weights. Is it an array of weights? a List?

If it is some sort of collection/array, then what happens with the following code:

var weight = new Weight(5);
var result = weight.BreakInto(1);

In this case result holds only 1 weight, but it’s type isn’t Weight, it’s type is whatever collection we opted for above, but it’s a collection that contains only one weight.

This is a pattern we see all the time in our code, and it’s annoying. In our domain breaking something into one piece should result in the original object, not a collection. But in our code We start with an object and end up with a collection containing the original object. We can’t compare them or treat them equivalently.

Perhaps “breaking” something into one piece is illogical and shouldn’t be possible. This has a certain intuitive attractiveness, but I can’t help think that it may bite us at some point in the future, with ‘breaking into 1 piece’ becoming a special case, something akin to using null values as a special case.

This problem is even more acute when we treat weights as integers because we lose all connection with the problem domain and were wrestling with the distinction between an integer and an array of integers that contains only one value. Much too abstract.

Creating the weight class clarified some things for us, but we still needed to square away the relationship between a value and a collection of values.

Here’s what we came up with. It’s not perfect, there’s still a distinction between an object and a collection, but it’s one I can live with, for now at least.

var weight = new Weight(5);
var weights = weight.BreakInto(5);

if (weight == weights.Weight)
    MessageBox.Show("OK");
else
    MessageBox.Show("FAIL");

We introduce a new object called Weights, which is the return type of the BreakInto method on the Weight Class. Weights is a collection of weights. How the collection is implemented isn’t important, it’s not even exposed by the Weights object.

What is exposed is a property called Weight. So, a collection of weights has a Weight. This makes intuitive sense. The weight of a collection of weights is the sum of the weights it contains.

We actually create an IWeighable interface so that any object can have a Weight.

    interface IWeighable
    {
        Weight Weight { get; }
    }

Our Weights collection implements this interface. Note the Weight property returns a Weight object which makes explicit the fact that a collection of Weights weighs something.

Now we’ve got a whole new problem. In our Information Crunching about this problem we were throwing around words like ‘Weight’ and ‘Weights’ like very heavy confetti, and failing for quite some time to notice we were overloading the term ‘Weight’.

A Weight is a physical object that can be placed on a scales. It has a property also called Weight which indicates how much the Weight Weighs.

Clear?

So, does the Class Weight in the code above represent the object, or the property? Both? Neither?

It’s kind of frightening that in a very simple, clearly defined problem domain with very few moving parts, can conceal these kinds of problems, concepts and overloaded terms.

How much harder then to really crunch through a realistically large complex problem domain.

If this exercise has taught me anything it’s that when it comes to Domain Driven Design, you need to follow a few Self Discipline Rules. I haven’t gone back to Eric Evan’s book to see if these are in there in some form, but I’m sure some variation of them is.

  1. Small bites – This is complicated work. Pick off small concepts and analyse them to a) understand them and b) reflect them in the ubiquitous language and the system design. TDD teaches us to code in tiny (sometimes stupidly tiny increments). DDD may well mean doing something similar in the context of design.
  2. Rethink Rethink again, and again. – In our example we looked at the problem from scratch for 5 or more days in a row, and each time we saw it differently. Sometimes we saw the problem in dramatically different ways. It’s ridiculous to think that you’ll hit on the “right” solution at your first or second try. The best way to know if you’re on the right track is to listen to what the design and the code is telling you. All systems send messages, sometimes not very subtle messages to the programmers that work on them. If the system is pushing back, it may be time to rethink. That may involve rethinking very fundamental stuff, up to and including the Ubiquitous Language.
  3. Stop Navel Gazing – While your Ubiquitous Language, and Design needs to be changeable and allowed to evolve, you still need to deliver something. Endless rounds of information crunching in an attempt to get “happy” with the domain before you start implementing is arguably worse than starting to implement without the up front information crunching/design.

One interesting tool for provoking talk that helps shape the Ubiquitous Language is to ban primitive data types. If you simply assume that a Weight is an Integer or a Long, you’re though process ends there, it’s like a full stop in the design process.

If design from a perspective that the fundamental data types don’t exist, then every value, every attribute in your system has to be given a name, and once you have a name you have something that can participate in the ubiquitous language. You also a hook to hang behaviour on.

But, you say, ultimately we end up with primitive data types right? I mean you have to build objects out of something?

Maybe.

Or maybe it’s turtles all the way down.