Writing Unit Tests Should Be Fun

I picked up on "writing unit tests can be fun" vs "writing unit tests is boring" over at Mark Needham's blog.

Besides excellent points that Mark makes about the pair-programming game and that Uri Lavi makes about unit-testing code posing many of the same challenges as production code, there's another reason unit testing should be fun: flow.

I think a lot of developers know what it's like to experience flow while coding and know that it's a good thing.

It turns out that two factors that help produce flow are clear goals and direct and immediate feedback.

Writing tests first absolutely helps you clarify goals and receive quick feedback when you're coding.

Interestingly, flow activities can also require "activation energy" to get into them. (See Chapter 5 in Finding Flow by Mihaly Csikszentmihalyi.)

This is one reason why you might find yourself being a couch potato in your free time instead of working on your favorite hobby, even though you know if you got your butt off the couch and did that hobby, you'd actually enjoy yourself more.

Similarly, sometimes when I'm at work and I need to code something, I find it hard to pull together that activation energy needed to write both the tests and the code.

But I can say that when I do, it's almost always totally worth it.

Notes from ThoughtWorks London Geek Night: Startups That Innovate

Last night I went to the ThoughtWorks London Geek Night "Startups That Innovate". I know there are some people who wanted to go who couldn't because there wasn't enough space, so I'm going to share what I remember. And I aplogise for everything I remember wrong.

The first two speakers were Giles Thomas and Jonathan Hartley from Resolver Systems, who talked about founding Resolver and the technologies they use. Here's what I remember:

• To get your startup going, you need people who can fill three essential roles: (1) Technologist/Developer (2) Rainmaker (3) User Advocate.
• They use IronPython and it works well for them. At first, they picked it because it looked like a good language for rapid prototyping. When it came time to switch over to a "real" programming language, they decided that they liked IronPython so much that they wanted to keep using it.
• They use PyUnit for unit testing. Some people in the audience thought PyUnit might not be mature enough, but Giles and Jonathan said they were able to make it work.
• They use an internal Python-based DSL to automate acceptance tests.
• They are an XP shop.
• Developers really do pair program pretty much all the time, except for spikes.
• With pair programming, it's true that you don't get as much of a flow experience as you would programming alone, but it still seems to work pretty well.
• As an XP shop, they try to keep their working hours sustainable. That might be different from what you see in other startups.
• One lesson they learned was: Don't go into stealth mode—it would have been useful to get user and community feedback earlier.
• Another lesson they learned: Release earlier. It took them around 2 years to release v1.0, and again, it would have been useful to get user and community feedback earlier
• Interns are a great resource for startups.
• (Jonathan used vi instead of PowerPoint to present his talk, which was cool.)

The last speaker was Martin Dittus from Last.fm. Here's what I remember:

• Last.fm started to having trouble scaling all of the updating of data that results from scrobbling. They realized that they didn't need to do it in real time and switched to batch mode.
• They are using Hadoop to do this.
• One of their interns, Klaas Bosteels, wrote Dumbo to help make working with Hadoop easier.
• As a startup, they had trouble affording Business Intelligence tools, so they built them themselves.

I'm not very good at tweeting events, but some other people did better: London Geek Night tweets.

Also, I saw a list of upcoming ThoughtWorks Geek Nights while I was there. I think there were three in May and one in June. Here are links to the ones I could find links to:

• Java in the Google Cloud
• Erlang in Your Infrastructure
• Web Unconventions

Links: Agile Practices and Rebuilding Legacy Codebases

Over on Code rant, Mike Hadlow recently put out an article I liked: Agile practices are not just about management.

Besides being good reading, it also reunited me with an article that I've been wanting to re-find for a while now, but couldn't quite remember the source: Uncle Bob's The Big Redesign In The Sky. There are so many good points there about rebuilding—or rather not rebuilding—legacy codebases that you should go read it right now if you haven't. And if you have, you should go read it again, just because it's that good (even though it gratuitously uses the number 42).

Quitting Isn't a Way to Effect Organizational Change

Today I heard someone discussing why they were leaving a company, and that discussion involved them saying something like, "This job has been a bit crazy, and hopefully this will be a bit of a wake-up call for the company that something needs to change."

Baloney.

If you're unhappy with your job and you have a better position available somewhere else, then by all means, you owe it to yourself to switch.

But don't kid yourself that your leaving will make the organization realize they need to fix what was wrong with your position, department, or team.

As someone who has been working long enough to watch more than one person quit under circumstances like these, I can say that I have never seen the organization "fix what's broken" due to a single person leaving.

Maybe—just maybe—if an entire department or team left, the organization would experience enough pain to realize that something must have been very, very wrong and try to fix it. I think I may have seen this happen once.

But when a single person on a team quits, it just leaves a hole that the rest of the team scrambles to cover. They are so busy doing so, that the last thing they have time for is organizational change. And after a while, the organization sees that the person who quit really could be done without, and that no change is needed after all.

Recently, over on codesqueeze, I read Companies Aren’t Progressive (But People Are…). I don't agree with everything in the article, but at least it has a point—if you want change to happen, it's up to you to try to bring it about.

Once you're blue in the face from trying, and sick to death of it, feel free to quit with a clear conscience and go work someplace where people (might) better appreciate your efforts. As I said, if you have the opportunity to do so, you owe it to yourself to take it.

But don't delude yourself that your departure will be the tipping point that makes your organization wake up to how badly it needs change.

Sometimes It's Easier to Stick With What You Already Use

For the upcoming London Open Space Coding Day, we're thinking about working with messaging in enterprise applications.

That reminds me of the lesson I learned the last time I tried using MSMQ: Sometimes, it's easier to stick with what you already use.

The scenario was that we were going to import some record updates from an external system. Once we grabbed them from the external web service, we wanted to queue them up and bring them into our system.

"Aha!" I thought. "We need a queue. This is what MSMQ is for. We'll use that."

Unfortunately, this import is a very, very small piece of an application that otherwise is very, very largely database-driven. Ever since implementing the import, every time someone needs to test it, there's baloney about the MSMQ queues not getting set up right or not having permissions or some other junk. And that's ignoring that when we first coded it, we found out that lots of our developers didn't even have MSMQ installed, and they all had to install it.

On the other hand, if we'd set up the queues to be stored in the database, there would have been no problem. In our application, if you can't access the database, you're not going anywhere. In fact, in the next release, another developer needed a queue. He stored it in the database and never had any of the problems I did.

Now, this isn't a story about how you shouldn't use MSMQ. Instead, it's a story about how if your application is largely based on one technology, and to implement a single feature, you have a choice between using that technology and another one—where both will work pretty much equally well—you might want to seriously think about sticking with the one the rest of the application is based on.

On a related note, a few months ago, when I was at the February meeting of the London .NET User Group, Gojko Adzic and David de Floriner gave a talk on NServiceBus. It looked like an interesting way I might have been able to interface the message queuing so that I could have swapped out MSMQ with our SQL Server database without needing to change code.

Egoless Programming: Admitting When You Should Be Shot

Mark Needham brought up Egoless Programming on Twitter the other day, reminding me of one of my favorite times I got to admit "I did this, including the mistakes."

It looks much funnier as an xkcd-style cartoon than it did in real life:

(Disclaimer: All of the drawing above was copied directly from xkcd, because I can't draw at all. But the words are mine—well, mine and those of the co-worker who wanted to shoot me.)

Looking Forward to Alt.Net London Beers Tonight

I'm looking forward to attending Alt.Net London Beers tonight to see what social gaffe I can commit next. My favorite from last time was when someone asked me if I "was you-switch" and I looked at them blankly, wondering what they could possibly mean. In retrospect, I knew that there were several developers there from uSwitch, and I was just being asked if I was one of them. But at the time, I completely forgot, and the best my mind could turn the question into was something like... "Do you use switch statements? Because you know, in the OO-world, that's not cool." My secret is that I probably have used switch statements in the past year. But I didn't like it. Really.

Seriously, though. It's a good event. I made it to the last two, where we discussed Robert C. "Uncle Bob" Martin's SOLID Principles and "avoiding the big rewrite," including ideas from Michael Feathers' book Working Effectively With Legacy Code.

Jeff and Joel Say Quality Really Doesn't Matter That Much. Uncle Bob Disagrees

Joel Spolsky has a transcript of part of a podcast with Jeff Atwood where they say various odd things about software development, including:

• "And I find, sadly, to be completely honest with everybody listening, quality really doesn't matter that much, in the big scheme of things."
• Robert C. Martin's SOLID principles sound like "extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly."
• And, "The longer I think about this, the less I care about code hygiene issues."

Robert C. "Uncle Bob" Martin gives them a much-deserved ass-reaming in his response.

Debugging Deadlocks in SQL Server Sucks Less These Days

I'm debugging deadlocks in SQL Server 2005. I hate debugging deadlocks.

The good news is that debugging deadlocks in SQL Server 2005 sucks a lot less than it did in SQL Server 2000.

Bart Duncan expresses the difference well:

Turn on trace flag 1222 with "DBCC TRACEON (1222, -1)" or by adding "-T1222" as a SQL startup parameter. This trace flag is a new trace flag in SQL 2005, a much improved version of the tried-and-true -T1204. If you’re running SQL 2005, you should be using 1222 instead of 1204 unless you have deep-seated masochistic tendencies. Alternatives to 1222:

• If you are using SQL 2000 or SQL 7.0, you’ll have no choice but to fall back on the older -T1204.
• There’s a "Deadlock graph" Profiler trace event that provides the same info as -T1222. Feel free to use this instead of -T1222 if you’re on SQL 2005. But don’t waste your time with the "Lock:Deadlock" and "Lock:Deadlock Chain" trace events that are in SQL 2000, as they provide an unacceptably incomplete picture of the deadlock.

Hooray!

That quote is taken from the first part in an excellent three-part series on debugging deadlocks in SQL Server 2005:

• Deadlock Troubleshooting, Part 1
• Deadlock Troubleshooting, Part 2
• Deadlock Troubleshooting, Part 3

Also, there's Basic SQL Server Deadlock Debugging over on Tog's Blom.

I also like the Troubleshooting Deadlocking section in Inside Microsoft SQL Server 2005: Query Tuning and Optimization by Kalen Delaney.

JavaScript: The Return [no LineTerminator here] Statement

I was just reading JavaScript: The Good Parts by Douglas Crockford, and came across this statement:

I always use the K&R style, putting the { at the end of a line instead of the front, because it avoids a horrible design blunder in JavaScript's return statement.

A while back, I was introduced to using closure to help get rid of unnecessary global variables in JavaScript by a friend at work, along with the book Pro JavaScript Design Patterns. Instead of something like this:

var myString = 'hi';

function doStuff() {
    alert(myString);
}

You write something like this:

var myNamespace = function() {
    var myString = 'hi';

    return {
        doStuff: function() {
            alert(myString);
        }
    }
}();

But, because I like BSD style, I did this, with line breaks before the opening braces:

var myNamespace = function() 
{
    var myString = 'hi';

    return 
    {
        doStuff: function() 
        {
            alert(myString);
        }
    }
}();

When I tried to call doStuff, I promptly got the JavaScript error "myNamespace is null or not an object."

After much head-scratching and debugging, I learned the hard way that ECMAScript defines the return statement like this:

return [no LineTerminator here] Expression_opt ;

Let me put that a slightly different way:

return [!!!NO LINE_TERMINATOR HERE!!!] Expression_opt ;

And that's the story of how I became a convert to using K&R style when coding JavaScript.