Taste-Driven Development

Having used Test-Driven Development for several years now, I am as convinced as I have ever been of its benefits in producing high quality maintainable code. One thing that bothers me, though, is that TDD itself provides no forces to ensure that the small pieces you build are assembled together into the higher-order structures you intended. For example, you can write a clean, concise fully tested set of classes such that your domain model is directly accessing your custom tags for your web app. Of course nobody interested enough in software to read this would ever do such a thing, but the point remains: with the promiscuous coupling encouraged by IDE's that will helpfully import any class from anywhere without requiring you to think whether this violates good taste in the form of layering, abstraction or anything else, we seem to be constantly having to fight against randomly coupled internal workings in good-sized systems.

So I find I'm constantly looking for ways to do what we do at the class level with TDD and do it at the package/component level; that is, allow the good taste desired in the design to be formally expressed and tested with every build. Developers who aren't up to speed yet on the complexities of the system they're working on would be protected from violating its conventions, and the emergent design can be allowed to flourish in a controlled way. On our current project we use a few things to help, such as simian, jdepend, ydoc, lots of checkstyle checks aimed at code quality and the usual test coverage stuff. But a few of us think that what the world really needs is yet another open source java development tool. Oh, no, you say, not another one. Yes, I'm afraid, it's another one. But this one is different - this one uses a business rule engine (drools) to allow you to declare in a text file your idea of good taste and enforce it for your code base. This one even has a user guide. No, seriously. So if design is your bag, have a look at joodi and let me know what you think. It only has a few rules in it at the moment, so it's not overly complicated.

Oh, by the way, if you think the java runtime itself would show good taste, check out what joodi has to say about rt.jar in the sample reports section of the user guide...you might be surprised!

Here's an example rule from the joodi rule file. This one expresses the simple good taste that cyclic package dependence is bad. It's kind of cryptic at first glance, but it basically says that if there exists a namespace (i.e. a java package) that depends on itself (dependence being part of the joodi fact model when your code is analysed), then create a notification including the cause of the problem so that the report provides full traceability for each notification produced. Using joodi is pretty much down to writing rules like this that express what good taste means to you and your project. Welcome to Taste-Driven Development!

<rule name="Cyclic Namespace Dependence Is Bad">
<parameter identifier="namespace">
<java:class>Namespace</java:class>
</parameter>
<java:condition>
namespace.dependsOnNamespace(namespace) != null
</java:condition>
<java:consequence>
drools.assertObject(new CyclicNamespaceUseNotification(namespace.dependsOnNamespace(namespace)));
</java:consequence>
</rule>

Agile Requirements

I've been doing the odd dog-and-pony show presenting on the topic of agile development recently, which is always a good way to clarify your thoughts and force a few ideas to gel. What's been on my mind is the requirements gathering side of an agile project. Having just delivered a good sized agile project successfully, I'm convinced that the quality of our requirements gathering and the rigour and discipline of our scope management was one of the absolute keys.

Re-routing CVS repositories

I'm putting this here to save myself the hassle of figuring out how to do it on the rare occasions I need to re-route a CVS sandbox to a different repository without releasing and checking out from the new repository. So if anyone else is wondering how to do it (you'll need cygwin on Windows), run this command from the top of your checkout tree:

find -name Root -exec sed -i.bak -e 's:/old/path:/new/path:' {} \;

. You will also need to be careful if you use a Windows CVS server like CVSNT, since using the ':' as the sed separator will require you to escape the colon in your repository path if you have one. By the way, this will make a backup of each Root file called Root.bak, just in case you don't trust it (and why should you...:P)

Star Wars on the (really) small screen

I found another reason to dig my Pocket PC. My usual top reasons are talking books from audible.com and reading electronic books (in really big fonts!) with the Acrobat Reader for Pocket PC.

But having picked up a 1Gb SD card for next to nothing, I thought I'd investigate the supposedly forthcoming phenomenon of pocket movies. Microsoft has been making some noise about their new portable devices that play movies, but you don't need one of those. You just need a copy of this software and you're done. In about the time it takes to watch the film, it's converted to a 250Mb AVI at 320x240 resolution. That's 15 frames per second at a resolution that's higher than your TV, so it's pretty darn watchable. There is a slight weirdness to the screen when rotated to watch in landscape mode, probably because the RGB subpixels on the LCD or up/down aligned in this mode, but you get used to it.

So having recently picked up the Star Wars box set to relive my childhood like all the other 30-something males on the planet, but not having time to scratch myself like all the other 30-something males on the planet, I can now squeeze this necessary pastime into my morning commute and leave all the iPod weenies wondering why exactly they think they're so cool. Rock on.

Why I Hate Domain-Driven Design

I was feeling pretty good about myself I have to admit. Having just delivered a system that took a year of a dozen developer's lives to complete with the full XP experience working like a treat, on time, on budget, happy customer, etc, etc, I thought I'd finally get my life back and start catching up on all the reading I don't do when it's head down, bum up on a project. High on my list was Domain-Driven Design by Eric Evans, as it had been highly recommended by people I respect a lot. So now I'm depressed. It is such a fine book, no, it's a truly mind-expanding, insightful, gee-now-I-feel-stupid kind of book that I now just want to go back and do the whole damn project again. And this time I'd do it properly. Dammit.

If you'd like to share the joy, as usual my recommendation is to get it on the cheap at Safari

Power Pointers

I often get asked how I go about doing a technical presentation, so I thought I'd put down a few pointers for those who would like to do some presenting but think it's all a bit intimidating.

1. Have something you want to say. This is generally not a problem for most serious geeks, although it's surprisingly common to find many who have incredible experience and insight but think nobody is interested in what they might say. That is almost never the case, either, since all of us are sponges for good stuff of all kinds.
2. Care about your audience. It's important to really want to connect with the audience and make them feel important. Even in a stand and deliver situation, I often survey the audience to get a feel for their likes, dislikes and interests. This can help you focus on what they need and want over what you thought they might like.
3. Don't start in PowerPoint. I never, ever begin my presentations by opening PowerPoint and looking at a blank slide. I always open a Word document instead and switch to Outline View. Then I just start brainstorming, imagining I'm having a one-on-one conversation with someone, explaining the topic at hand. No structure is present yet. It's all about noting down all the things you might want to say first. Then it's a matter of learning to use the outline view's features of indenting, outdenting, dragging and dropping to apply some structure to the thoughts. This is very much like the test, code, refactor cycle in development of code. The test is that you can explain the idea. The code is recording the points you need to do that. The refactoring is cleaning up the structure. And just like coding, it works really well if you treat these as distinct tasks and switch between them cleanly.
4. Generate the slideshow from the outline. Once you're done in Word, just hit File->Sent to->PowerPoint and voila! All your top level headings become slides, and the subpoints become bullet points underneath them. You can then click Format->Apply Design Template, go looking for a pre-canned  slideshow and bingo! your show is just about done without a single tedious minute in PowerPoint itself. If you have time, add some pictures and animation, but remember they're the icing, not the cake.
5. Less is More. I much prefer slides with fewer words on them. I do not consider a slide to be of any value without me in front of it to turn it into the presentation experience. Resist the temptation to turn a slideshow into a whitepaper. It's just there to remind you what you wanted to say and help the audience to follow; it's not there to say it for you!
6. Remember that nobody finds it easy. Public speaking is daunting for everyone, and I do mean everyone. I sweat bullets for days before an important presentation, but once it starts it's almost like it's someone else doing it, not me, and in a way it's easy. If you're serious, look into Toastmasters for some training (I did it 20 years ago and am still grateful) or try your hand at a low-risk venue like a user group or other friendly and supportive environment.
7. Have fun!

 

Smell the Tests!

When you are faced with a team that's new to agile development, it's common to spend a lot of time driving home the need to test everything. Along with refactoring, test-driven (or at least test-conscious) development is the most basic skill the aspiring extreme programmer must acquire. We strive to testability in design and the cheapest, most effective quality we can get. So is there such a thing as bad testing? Can tests hinder more than help? Can tests just be a downright pain in the rear?

The answer is a resounding YES! YES! YES!

Just because you code in an object-oriented language does not guarantee that what you write will contain any object-oriented characteristics whatsoever. Similarly, just because you write JUnit test cases does not guarantee that what you produce will display any of the qualities of an effective and adaptable test suite. Naive application of testing frameworks has the same potential for developers to exercise their bad judgement and bad taste as any other technology. Now while I'd certainly rather have a project with lots of less than ideal tests than no tests at all, we need to learn to 'smell the tests' to really get the most out of our (and our customers') investment in testing.

So here are some of the smells that tests can emit. I'm sure you can think of more, so please drop me a line so I can share your pain...:P

• No statement of intent. If I have a Widget with a getPrice() method, I often see a testGetPrice() test method, and my first thought is "test getPrice() does what?". Prefer names for tests that express the intention of the test, such as testGetPriceReturnsZeroWhenNotInitialisedExplicitly(). There are tools that can turn your test names into human readable documentation, so don't be afraid of full-length sentences as test method names.
• Irrelevant assertions. It is common (particularly in functional tests) for a test that is concerned with proving a small incremental behaviour to make irrelevant assertions about all sorts of other fields, even on other screens. Prefer semantic generalisations over value-specific assertions. For example, if your test is not concerned with the actual price algorithm, don't assertEquals("46.12", widget.getPrice()) when you can say assertNonZeroMonetaryValue(widget.getPrice()) - even though it's a bit more work at first.
• Setup leakage. It is extremely common for developers new to testing to not easily be able to distinguish the concerns of their test from the setup steps required to get them to the point where their test can begin. The newly test-infected developer can thus create maintenance burdens and simply waste time reinventing the testing wheel with every test case. Strive for a clear separation between setup and test, and look for reuse in the setup code via fixtures and scenarios.
• Overtesting. Many developers find it difficult to focus only on what is relevant to the test at hand. It is not only more efficient to assume the rest of the system works when writing a new test, but it also improves maintainability as each test is more isolated and targeted. It is common for developers to turn themselves into knots to get controlled input and output moving between different components when a mock would be faster and more effective. Leave it to the other tests to do their job and assume away responsibilities that are not yours right now for the code under test.
• Multi-layer tests. Unit tests should rearely (if ever) traverse multiple layers in your design. A sure sign that they do is when they run slowly. Unit tests should run in the thousands per minute kind of rate, while functional tests tend to be in the 30-50 per minute range, so prefer unit tests to achieve coverage and functional tests to prove wiring of configured components.
• In-container unit tests. T'ain't no such thang. Don't make sense. If you think you have some, that's a smell. :)
• Fractured functional tests. Adding functionality a small bit at a time leads to functional tests with a lot of overlap and there is no force to encourage the consolidation of these tests other than slow build speed. I'm not sure how to fix this one other than slow slog refactoring. We have a lot of this joy ahead on our current project!

None of this alters my belief that test-driven development is the best method I know for building quality software. But it does mean that (once again) we need to be careful about silver bullet syndrome when it comes to testing.