TDD vs Architecture

Someone recently asked me on the OT mailing list about my experience with test-driven development (TDD). They were concerned that it seemed to advocate throwing away all the careful architectural design work we've been taught is a good thing, in favor of just attacking the problem piecemeal. Here was my response:

Disclaimer: I'm not an XP expert. I haven't read the XP literature. My only qualification to say anything about it is that I've been using it for a few months, and have noticed a difference in my satisfaction with the code I produce.

First of all, you have to ask yourself if you've been successful with your architecture-driven approach. If the answer is "yes", then why are you considering changing things? I find that XP's main feature seems to be "ruthless practicality", so if you've already got something that works, go with it.

Second, architecture is basically a set of pictures (and a lot of thinking) that you draw for guidance before you start coding. Nothing about that is incompatible with TDD. Get an idea of how you want to do something, then write the tests that assert that your design does it, then write the code that makes the tests pass.

One of the ways I've started to think about tests is as a way of expressing requirements. What I particularly like about that is that I'm expressing them in a highly precise, machine-readable, unambiguous language with which I am already familiar...C#.

Another thing to consider: designs done in the abstract are typically at a higher level than the API level. Or if they are at the API level, they rarely express pre- and post-conditions. Tests do both, so they really magnify your design documentation, bringing it to a lower level.

Now, it's true that traditional architecture and TDD tend to emphasize different things. Most people wind up doing architectures that attempt to abstract all the functionality you *might* need. TDD takes a more just-in-time approach, focusing on only writing the functionality you

*actually* need, *right now*. Of course, test-first can be done even for highly abstract requirements, and designs can be written to a set of practical requirements - so those facets are orthogonal. It's just that they tend not to be.

Both approaches have their place. I just find that I so rarely know exactly what my requirements before I start, that it's difficult to start with an abstract vision. A set of tests is also a set of use cases, and expressing them so formally (i.e. as C# code) allows me to work out details at the level I care about: the API design.

Clemens on Open Source

Clemens has a nice post on Open Source here. I completely agree with what he says, and the only qualification that I would make, I suspect he would agree with. I would add that, if you want to make free software as a hobby, there is nothing wrong with that. Many programmers enjoy what they do so much that doing it on evenings and weekends is actually appealing. It's no way to make a living, but speaking for myself, I know it makes me feel good for a bunch of reasons:

• I use a lot of open source stuff, and giving back to the community seems like a conscientious thing to do.
  
• I get a tool that works just the way I want it to, and other people get use of it too.
  
• For stuff I was going to write anyway, the potential benefit of having other people improve is nice.
  
• Putting your work out there where other people can see it is scary the way getting on stage to sing is scary: if you screw up, people know it. But it's also a good thing for the same reasons.

Also, for consultants like me, writing stuff that a bunch of people use can be a reasonable way of getting your name out in the community, and that can lead to business. No direct benefit, of course, but it's not a zero-output effort, either.

I think it's safe to say that Clemens understands all that. After all, his name is closely associated with the open source project DasBlog, and there are probably a few people that know him only through that product. So, Aiden, wherever you are, don't give up on open source - Clemens was just saying it's not a good career path. It's still a ton of fun. :)

Ten Songs I Didn't Choose

Following Brad's example, here are ten songs pulled at random from my collection:

1. Allegro giocosco, ma non troppo vivace, Johannes Brahms, Festival Overture-Tragic Overture


2. The Forces of Nature, Artension, Forces of Nature


3. Speak To Me - Breathe, Pink Floyd, The Dark Side of the Moon


4. More of Nothing, Lemur Voice, Insights


5. At Fates Hands, Fates Warning, Perfect Symmetry


6. Gotterdammerung, Act I, Wagner, The Ring Without Words


7. Not Quite Sonic, I Mother Earth, Dig


8. I Didn't Want to Need You, Heart, Brigade


9. Laetatus sum - Gradual (Modo VII), The Benedictine MOnks of Santo Domingo de Silos, Chant


10. Anna Lee, Dream Theater, Los Angeles Disc 1

I'd say this is pretty indicative of my collection: mostly progressive rock, with an emphasis on progressive metal (and a significant portion of that being Dream Theater), with a fair smattering of classical music thrown in haphazardly. Oh, and the rare cheesy band that I like for no reason I can explain (Heart).

COM Threading Bites Me Right in the Ass

Professionally speaking, I left COM behind years ago, when I decided to focus on .NET full-time. I've been lucky enough to have that career option. Of course, it doesn't mean that I've forgotten what I know about COM, and sometimes that knowledge comes in handy. Other times, I'm reminded of how confusing that stuff has always been, and I'm even more grateful I could move on.

Take tonight. I was coding along, working on my implementation of FlexWikiPad. I wanted to pop up a dialog box so the user could choose a folder to store the wiki in. “No problem,” I thought, “I'll just use the built-in folder browser dialog.” Imagine my surprise when I ran the code and got a blank dialog. Oh, it had an OK and a Cancel button, but there was nothing but grey background where the folders on my computer should have been shown.

I did what any good debugger would do, and started stripping down the application, looking for the line of code that was causing the problem. But the application kept getting smaller, and soon it was just an empty form with a button on it. Clicking the button did nothing but open the dialog, and it still had the same problem. I was mystified.

I had a suspicion that something might have gone screwy in the project settings somewhere, so I fired up the project wizard, and I created a second project from scratch, with the intention of using WinMerge to diff the two project files. Only, when I was perusing the generated source code, I saw something that gave me pause. After thinking about it for a second, I went back and made a one-line change in my original program, and sure enough, it started working.

The problem in this case springs from the fact that I tend not to rely on the VS.NET wizards. Rather, I either write my source files from scratch, or I generate them with CodeSmith templates. So I had failed to mark my Main method with that little [STAThread] attribute, which, in the type of .NET programs that I usually write, is actually a good idea. But when you're dealing with controls that interop via COM - as is apparently the case with the folder browsing stuff - it just causes things to go kerbluey in odd ways.

Ah, COM.

Managed DirectSound Drum Machine

There's an interesting article here by Ianier Munoz that talks about how to build a simple drum machine with Managed DirectSound. I've used a commercial tool called FLStudio to write music before, and it has a very similar interface to what's in the article, although obviously FLStudio is more sophisticated.

Anyway, I suspect that it wouldn't take much to turn what Ianier has written into something that you could actually compose little techno songs on.

What Has Craig Been Up To?

It's been relatively quiet of late on this blog, so I thought I would explain why. Basically, I've been writing a ton of code. Now that I've started at MSDN, my time during working hours is completely consumed. But outside of that, I have several projects that I'm working on, most notably my ExplosionMan game and a whole bunch of stuff on the FlexWiki project. My FlexWiki efforts include, among other things, FwSync and FlexWikiPad, which - if I ever get them done - should allow me to do all my wiki authoring and editing offline, synchronizing with the webserver only when I feel like it. This would be an enormous boon to the way I use wikis, as it often includes taking notes at a very rapid pace, something that a web browser interface pretty much sucks at because of all the extra mouse use required to navigate around.

Anyway, the end result is that I'm coding morning, noon, and night. Pretty much any time I'm not out running or home watching TV, I'm hacking on actual production code. That's a major difference from the days when I made most of my money teaching for DevelopMentor. Back then I'd still write a lot of code, but most of it was of the “Let's see how this particular feature works“ variety.

One of the most interesting things to come out of the shift in the type of software I write has been my personal discovery of test-driven development. As an experiment, I started writing ExplosionMan that way, and soon found that I absolutely loved it. Like many others, the main thing that I discovered was that making changes to the code was no longer such a crapshoot: I could muck around with restructuring a piece of code, and the suite of tests I developed would give me a fair degree of confidence that I'd be able to quickly tell if I broke something. Of course, I'm still early in my experience with TDD.

All in all, I've been loving the experience of writing “real“ software. I also expect - my attention span being what it is - that at some point I will feel the need to go back to a more researchy mode. What with all the Longhorn technologies coming up in the distant-but-not-too-distant future, I doubt there will be any shortage of cool stuff to learn when I get there.

 

The Craftsman Series

I've been reading The Craftsman Series that are posted here. They're pretty interesting, especially for someone like me who has recently become a big-time convert to test-driven development.

Xen - Wow

It's not often I say “Wow” out loud while reading a white paper, but that's exactly what I did while reading the Xen whitepaper. I particularly drooled over the constructs towards the end of the paper that allow you to - in one easy-to-read line of code - perform an operation on a stream of XML elements, returning a new stream of different elements.

I've been doing a bunch of emacs hacking lately, and although my LISP was never good, it has become slightly less rusty. Xen reminds me a lot of LISP, only with a syntax that's a lot closer to what I'm used to, and that has better support for objects.

I've only just read the paper, so I haven't quite absorbed it yet, but this looks like an extremely interesting piece of software. We probably won't see it for years, if ever, but that doesn't mean I'm not interested.

Hoop Has One Too

It looks like it's my day to “out” people: Hoop Somuah has a blog too. Hoop is a former student of mine - I taught a short course at Stanford University, and it was one of the best groups of students I've run into in a long time. More recently, I've run into him while working on FlexWiki. Now he's working on the Indigo team, so hopefully he'll have some interesting things to say.

Subscribed!

Jon Flanderses's Blog

Jon Flanders has a blog. As another Minnesotan expatriate DevelopMentor instructor, he must be worth listening to. :)

Now the only question is, do I describe his blog as “Jon Flanders' blog”? Or as “Jon Flanders's blog”? Or even “Jon Flanderses's blog”? Whichever it is...subscribed!

Direct3D Fonts Tutorial Available

As is my custom, I spent my plane ride to/from Redmond writing another Direct3D tutorial. This one is about how to work with Fonts. I cover both 2D and 3D rendering of text. Enjoy!

Here's Your Chance

Tom Miller is seeking feedback about Managed DirectX. They're starting to enter a planning cycle for the product, so giving him a brain-full now is good timing for influencing the product!

MDX Dinner

David Weller invited me to dinner last night with Tom Miller and Scott Haynie. These guys are all heavy-hitters in the Managed DirectX space (Dave's book is now complete and should be published soon, and Tom is the guy that wrote all of the Managed DirectX libraries), so it was fun to sit down with them for a bit to chat.

I had some time to kill after dinner before I had to be somewhere else, so I wandered over to Borders. While I was there, I picked up Tom's book and started reading it. I haven't finished it yet, but so far, it's great. In fact, if I'd read this book before starting my Managed DirectX tutorials, I'm not sure I would have bothered - it does a great job of getting the reader up to speed quickly. Not that I'm going to stop now, mind you, but I still recommend that anyone interested in Managed DirectX check out Tom's book...and keep an eye out for his next one.

Off to Seattle Again

I head for Microsoft in Redmond tomorrow to start up my part of the next phase of the MSDN project. I'll be there until the following Tuesday. If you're going to be in the area and want to get together, shoot me an email. No promises - we worked 11 hour days last time I was there - but hopefully I can find time to see a few people.

The House Construction Fallacy

Brian talks some more about the evolution of MVC and compares it to building a house... My $0.02, eventually computer programming will be as mature as physical construction, but we have a while... [simplegeek]

I often see this analogy made: writing software should be more like building a house. You make a plan, you hand off the plan, someone else implements the plan…and voila! There are, however, a number of problems with this argument.

1)      It’s an analogy. It’s a common fallacy that analogies prove anything. A being like B in one respect (writing software is a constructive act) does not imply that A is like B in any other respect (separating duties between architects and contractors in software development is a good model). As humans, though, we love to pattern-match even when it’s completely inappropriate, therefore, analogies are one of our favorite tools.

2)      If you’ve been to my house, you know that quality does not necessarily arise from this particular arrangement. Crappy work is par for the course in many home construction jobs. And watch TLC for an hour or two and you're likely to see some home improvement show where the carpenter misunderstands the designer, and puts a window where a door should be. Or gets a blueprint that positions a hot tub over an unreinforced floor.

3)      Writing software is not like building a house. It’s more like building a house factory: the program you write is actually a blueprint itself. The blueprint is executed by a computer to produce the artifact itself, i.e. the running instance of the program. This is unlike just about any other industry.

4)      Materials in software change on a more frequent basis than they do in construction. I don’t know what the Moore’s Law is for home construction, but I bet it’s not exponential on an 18 month basis.

Now all this is not to say that discipline is not needed. Obviously, it is. I’m just tired of seeing this particular, overdone analogy. No offense to Chris or Brian - this post is targeted at the industry as a whole.