Sunday, April 26, 2009

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.

Friday, April 24, 2009

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 Here's what I remember:

  • 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:

Saturday, April 18, 2009

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).

Wednesday, April 15, 2009

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."


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.

Sunday, April 12, 2009

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.)