TDD Q&A

I got a very interesting comment from Rick Pingry and I’m taking a liberty to respond to him in the post format, because I think his questions deserve so. In general, Rick expresses his doubts about going TDD all the way and raises some really good questions about practical side of TDD. What’s interesting (to me at least) is that he works on a C++ application, so it’s good to hear that even the C++ world is catching up with some modern trends :)

Reality check: is your project meaningful?

Here is a simple reality check for you: do models (entities) in your project tend to have names like Item, Content, Object, Data or ContentItem? If so, your project may not be meaningful to your users. You’re probably going to (or already do) have problems in communicating with them.

You see, the end users and domain experts don’t think in this terms. They don’t order “items” to build some “thing”. They order laser cannons and remote controllers to build a giant laser-beam-shooting, remote-controlled robot.

That's what they're building.
So you better do a good job with what YOU are building.

If you call some entity an Object it means you don’t really know what it is and what it does. I bet the domain experts don’t call it an “object”, they call it “a part used to build a giant robot”. Can you see how much more information is given by a good name? Your “object” is a Part, so it has some technical characteristics, it belongs to some robot(s), it is probably stored in some warehouse, it may have a price, versions, dependencies, requirements, subclasses etc. This list could go on and on.

A laser canon, not just an “object”…

On the other hand what does the name Object tell you? From my experience, it tells you that the developers don’t understand the users, the users don’t understand (and hate) the application, the specs are missing or outdated and no-one is able to identify a single use-case for the system. In short, not much of a success.

So, what’s your favorite meaningless name?