A Year Of London Developer Events

Today marks a year since I moved to London from Chicago. So far, my favourite thing about being here is the trains run like clockwork the vibrant software developer community.

Here is a list of events I've attended, all of which I highly recommend:

• AltNetBeers and AltNetWorkshops organised by Sebastien Lambla
• London .NET User Group organised by Ian Cooper and Zi Makki
• Open Source .NET, Architecture & DDD, Agile PM & Scrum, and Agile Testing & BDD events at Skills Matter . Several of the ones I've been to were organised by Gojko Adzic
• Open Space Coding Days organised by Alan Dean
• The Alt.Net UK Conference organised by Alan Dean, Ian Cooper, Ben Hall , and Sebastien Lambla
• DDD Meetups organised by Adam Shimali
• ThoughtWorks London Geek Nights organised by Robert Rees
• eXtreme Tuesday Club
• #DevBookClub organised by Toby Henderson and Chris Browne

Misadventures in DDD With Not-So-Ubiquitous Language

Lots of people have been talking about DDD (Domain-Driven Design) lately, and my friend Tom just discussed it over on his blog in the article Refactoring Toward Deeper Insight. So, I thought I'd share one way not to do DDD.

Once upon a time, shortly after the big blue book was published, I saw it in the store and thought it looked interesting. I bought it and read through the first section about knowledge crunching and ubiquitous language. And it all made so much sense—where I worked, the business analysts and software developers already worked together to crunch knowledge into a domain model they both understood (or so I thought). The trouble was, even though when they talked together, they used that language, when the developers actually wrote the code, they used their own. Why? Well, I didn't know—mostly just because we usually thought our names for things were better, I supposed. Trying to keep the language the same just wasn't something we'd thought about much.

So, I decided that on the project I was working on, we'd start doing DDD by using the names from the business language for the classes in our code. I didn't discuss it with the business people, since I didn't think it involved them much—they didn't need to change their language, we developers just needed to use it.

Everything went fine for most of the project. Then, a couple days before release, the business decided that they wanted to rename one of our core domain concepts—and that was okay, right, because it was just changing a few labels on a few screens?

And that's when I learned that if you want to do DDD, it helps to get buy-in from the business.

So, happy DDD-ing everybody—because I do think lots of the ideas are great and worth exploring—just make sure you let the business know what you're up to and you'll avoid my rookie mistake.

Estimating is Like Measuring the Coast of Great Britain

Earlier today, Liz Keogh tweeted this, which I couldn't agree with more, as long as she's saying what I think she's saying:

Thinking about fractal estimation—estimates grow as scale shrinks—and wondering what dimension current projects have.

A while back, every time I started doing technical estimates for a release, I began to think more and more of the illustrations along the side of this Wikipedia article: How Long Is the Coast of Britain? Statistical Self-Similarity and Fractional Dimension.

The situation was, that as a developer in a waterfall process, when I was trying to estimate how long it would take to code something, even with the requirements supposedly "fixed," unless I examined the code I was proposing to change in so much detail that I was basically writing it—and that's not estimating anymore—I'd always miss things that would make coding take longer than I'd estimated. In essence, there were always craggy little details that upon actually writing the code, became significant or added up with others to become significant.

Now, I know that if your architecture and code are clean, this should happen less. But I still think it's generally true that until you actually write the code, you really don't know how long it will take, and the amount of time will usually be longer than you think when analyzing it at higher levels.

Then, I thought of this problem again when I attended a talk on Scope Budgeting. There, the general issue is that in Agile, if you write a user story, estimate it, put it in your backlog, and only elaborate it when you pull it back out to implement it, you may find that the size of the story grows at elaboration-time.

According to Liz's fractal estimation rule, that makes complete sense and should be expected. I agree. Whenever I have worked with user proxies to move from general functional requirements to specifics, the estimate has always increased. The amount of work needed to address all the details we discover always grows beyond the original estimate. If we made commitments based on that estimate, the only way to keep them is to prioritize and remove some of the details.

I can think of a few ways to address this problem, if we want to consider it to be a problem:

1. Just be aware of it and deal with it as needed, which is a lot better than not being aware of it at all.
2. Start measuring it, so you can factor it into your future estimates. This might be taken care of by comparing estimates to actuals and factoring that into future estimates. You'll need to decide whether the time it takes to do this is worth the return, though.
3. Move toward techniques like Kanban that de-emphasize estimation. Whether or not this works for you will depend on your current situation, but it's always worth questioning whether you're estimating because you truly need to or just because that's what you're used to.

---

Update Sept, 2010:

• Liz also wrote about the fractal nature of estimation as part of Estimation anti-patterns.
• Dan North mentioned it in The perils of estimation.
• Dan also has referenced it more recently in Introducing Deliberate Discovery.

Pair Programming for Flow

A while ago, I attended the workshop Debugging Pair Programming by Matt Wynne .

Matt gave the same workshop at Agile 2009. That website has a good write-up of how it worked.

After the first part, where we discussed how to convince different developer personas why they should cooperate with pair programming, we moved on to the second part, where we paired up and interviewed each other about good experiences pair programming or collaborating in other ways.

I was paired with Tom ten Thij , who said something really interesting about pair programming.

He said that pairing can make it easier to get into flow.

This was completely the opposite of what I'd heard before about pair programming. Before, I'd heard it can be difficult to achieve flow while pairing—that you might even have to give up on flow, but that the increased code quality is probably worth the trade-off.

But Tom's point was that while pairing, you're less likely to procrastinate getting into your coding task. In other words, having a partner helps force the "activation energy" that flow activities can require.

So, as long as your pair works well together, and you keep everyone engaged by doing something like ping-pong programming, you might be able to achieve flow after all.

Misadventures In BDD With NBehave

From my previous post, you might have picked up that I like the idea of BDD's given-when-then construct for describing scenarios.

For a while, I've been wanting to use this syntax in unit/integration tests to make them clearer. But I've been hoping to do that without switching languages or unit-testing frameworks. Toward that end, I tried out NBehave.

Here's some test code that demonstrates my worst fears about why NBehave might not be right for me:

public void Execute()
{
    var story = new Story("Search Contacts by Relationship Strength")
        .AsA("User")
        .IWant("To search on the Strength field")
        .SoThat("I can find Contacts who have a given Strength");

    Scenario scenario = story
        .WithScenario("Find Contacts with Strength of 50");

    scenario.Given("The database contains a Contact with a Strength of 50")
        .And("a search results view", GivenResultsInfo)
        .And("a query for Contacts with Strength of 50",
            GivenQueryForContactsWithStrengthOf50)
        .When("The search is run", WhenRunSearch)
        .Then("The results contain Contacts with Strength of 50",
            ThenShouldContainResultsWithStrengthOf50);
}

private void GivenResultsInfo()
{
    var resultsView = new ReadOnlyResultsView(
        ExtendableEntity.Person, SortType.Ascending, 
        new[] { Column }, Column);
    ResultsInfo = new ResultsInfo(resultsView);
}
private void GivenQueryForContactsWithStrengthOf50()
{
    var condition = 
        new DecimalCondition(Column, ComparisonOperation.EqualTo);
    condition.DataField.Value = 5;

    _query = TypeHelper.GetAdvancedQuery(_entityType);
    _listManager.AddListToAdvancedQuery(_query);
    _query.MainConditionGroup.AddCondition(condition);
}
private void WhenRunSearch()
{
    ISearchService service = TypeHelper.GetSearchService(_entityType);
    ISearchResults results = service.GetResults(_query, ResultsInfo);
    _resultsData = results.Results;
}
private void ThenShouldContainResultsWithStrengthOf50()
{
    Assert.Greater(_resultsData.Rows.Count, 0);

    foreach (DataRow row in _resultsData.Rows)
        Assert.AreEqual(5, (decimal)row[Column.Name]);
}

But for me, creating reports of the text descriptions wasn't the main point. The main point was just to better organize the test. When I started writing the code, I thought maybe I'd just skip the text, but then I thought, "Oh well, I might as well do it."

And that was fine, but when the requirements changed, I had trouble keeping the text synchronized with the code.

After I wrote the initial code, the team decided that instead of having strength on a scale from 0-60, we'd have it on a scale from 0.0-6.0. And when I changed the code, I was in a hurry, since that change hadn't been part of the original estimate, and consequently threatened our timeline.

So I ended up with text that said 50 and code that said 5.

Open Space Coding Day: TDD As If You Meant It and Cucumber With IronRuby

Saturday I was at the Open Space Coding Day that was part of the Alt.Net UK Conference 2009.

In the morning, I was in the session on TDD As If You Meant It. Gojko Adzic already did a pretty good write up, so I'll point you there to learn more about it: TDD as if you meant it – revisited.

In the afternoon, I was in the session about using Cucumber and RSpec with IronRuby. Mostly, I was interested in this because I keep hearing really good things about Cucumber, but as a non-ruby person, I have never quite discovered what those good things actually look like.

I was also a bit psyched, because I was pretty sure I'd heard that IronRuby was going 1.0 on my birthday. But alas, it seems that article subtly changed since I last looked at it, from saying "IronRuby is 1.0!" to now saying "IronRuby is almost at 1.0!" A slight let-down, but that's okay. We still had a good session, and I'm the first person to understand that software doesn't always magically appear on a certain date just because we want it to.

To install IronRuby, Cucumber, and RSpec, I mostly used these instructions:

• BDD with RSpec\Cucumber\IronRuby
• IronRuby and .NET

The process for me went something like this:

1. Install Ruby.
   
   
2. Install IronRuby. (The day I was doing this, 0.6 was being billed as the current release. It looks like things have moved on.)
   
   
3. From IronRuby and .NET, do:
1. Installing required gems
2. Creating a Cucumber wrapper script for IronRuby
3. Running the examples
   
   
4. Now the examples ran, but there was some weird escape-character output. I didn't find the answer to how to fix this, but another person in the session, Lorenzo Stoakes , did. Here's how that looked on Twitter.
   
   For convenience, though, I guess I'll compile that into the single sentence: In your file that corresponds to C:/Ruby/lib/ruby/gems/1.8/gems/cucumber-0.3.92/lib/cucumber/formatter/ansicolor.rb, replace Term::AnsiColor.coloring = false if... with Term::AnsiColor.coloring = false.

At that point, the examples seemed to sort-of run okay for me. I think Lorenzo and Garry Shutler got past some warnings that were getting output, but I didn't. I'm also pretty sure Garry also got RSpec to work.

What was the whole point? Well, since I didn't get past the examples, I'll sum it up with one of them.

Say you're developing a calculator. Your business person can specify the addition behaviour in text, like this:

Feature: Addition
  In order to avoid silly mistakes
  As a math idiot 
  I want to be told the sum of two numbers

  Scenario Outline: Add two numbers
    Given I have entered  into the calculator
    And I have entered  into the calculator
    When I press add
    Then the result should be 
 on the screen

  Examples:
    | input_1 | input_2 | output |
    | 20      | 30      | 50     |
    | 2       | 5       | 7      |
    | 0       | 40      | 40     |

And you can make that executable by adding some code in a related code file like this, where you're testing a .NET assembly Calculator.dll that contains a Calculator class in the namespace Demo, and the Calculator class has push and Add methods:

require 'spec/expectations'
$:.unshift(File.dirname(__FILE__) + '/../../lib') # This line is not needed in your own project
require 'Calculator' # Calculator.dll

Before do
  @calc = Demo::Calculator.new # A .NET class in Calculator.dll
end

Given "I have entered $n into the calculator" do |n|
  @calc.push n.to_i
end

When /I press add/ do
  @result = @calc.Add
end

Then /the result should be (.*) on the screen/ do |result|
  @result.should == result.to_i
end

That does look pretty sweet.

Scope Budgeting

A while back, I attended the talk Scope Is Not A Dirty Word given by business analyst Angela Ashworth and delivery manager Mark Coster from ThoughtWorks.

The centre of the discussion was "scope budgeting," which basically boils down to having the developer work with the user to manage scope within an iteration.

In many flavours of agile, the user writes a story, the developer estimates it, and then it goes into the backlog. It's only when the story gets pulled from the backlog and put into an iteration that the user and developer fully flesh out the implementation details. But at that point, they may find they have scope creep—that the implementation will take longer than the original estimate.

At this point, the developer has two options:

1. Implement the story, even though it will take longer than originally estimated, pushing out the other stories, potentially dropping some off the end of the release.
2. Talk to the user more. Let him know that the estimate has changed and why. See if together they can come up with a way to reduce the scope of the story to get it back down to the estimate.

Option 2 is scope budgeting.

I have to admit that I was actually very disappointed to hear this from ThoughtWorks.

I have never been part of an agile project, I've only read about it. My agile daydreams included how nice it would be to have the user prioritise stories from the beginning, understanding that not everything would necessarily make it into a release, thus avoiding one of the activities I've come to think of as churn—the developer and user constantly having to re-prioritise and re-think functionality as scope creep happens in order to try to fit everything in or to figure out what is best to leave out.

I suppose I can understand why scope budgeting is a good idea. And I can understand that having all the stories in an unchanging ordered list from the beginning of the project isn't really very agile at all.

But it's still tough to see my daydreams shattered.

The up side is that it highlights that both the developer and the user are in the same boat, working together toward the same goal. In waterfall, each is under pressure to "be perfect." The user should write down every single implementation detail at the beginning of the project and the developer should estimate every one of them down to the minute. Later, when they discover that a requirement was missed, the developer blames the user for blowing the project. When they discover that an estimate wasn't quite right, the user blames the developer for blowing the project.

At least with agile and scope budgeting, the focus changes from blaming to recognising that neither the user nor the developer can make a perfect plan at the beginning of the project—that they need to work together throughout to figure out how to create the most value.

My Favorite Technical Books

It's been half a year since I moved from Chicago to London, and there is still an awful lot of stuff that isn't unpacked and is sitting in boxes, including many, many books.

But last weekend, the DH and I added yet another bookcase to the flat, and it's time to take care of the box sitting at my feet, labeled "Amy's favorite computer books."

But wait, I hear you say, if those are your favorite computer books, how can they possibly still be packed away in a box? Don't you need them at your desk every day?

Not so much anymore. A few years ago, I bought a subscription to Safari Books Online, which I can't say enough good things about. Yes, it can be expensive, but if you can scrape together the cash and you love technical books, it's great. Almost all of the books in my box are on there, so I don't need them at my desk.

The other aspect of having these books at my desk was that they were available for my teammates to easily grab and use. But now that I'm in London and those teammates are in Chicago, that doesn't happen anymore.

So, my favorite books have been sitting in their box until now. Now, I have a bookcase with glass doors available, so they won't get dusty. Here they come out of the box:

Head First Design Patterns by Freeman & Freeman I can't say enough good things about this book. It was the book that made the light go on for me for understanding what design patterns are and why they are useful. I own two copies—one was for work and one for home—plus the poster.

Working Effectively with Legacy Code by Michael Feathers For when you have to deal with ugly code, old code, code written by someone else long gone from your company, scary code, code without unit tests, or code you wrote last year and now hate.

Refactoring to Patterns by Joshua Kerievsky A bridge between patterns and refactoring.

Software Estimation: Demystifying the Black Art by Steve McConnell Sometimes I curse that I read this, because it made my BDUF estimates more accurate. Don't worry, there's lots of other good stuff in there, though.

Patterns of Enterprise Application Architecture by Martin Fowler This was the most-borrowed book in my library before I moved.

Pro C# 2008 and the .NET 3.5 Platform by Andrew Troelsen When I can't remember how something .NET 3.5 works, and I have trouble finding it online, this is where I end up.

VB & VBA In a Nutshell by Paul Lomax Because unfortunately, sometimes VBA still happens.

There are two more that I need to mention, even though they aren't in the box. The first, I have on CD, and the second I used to borrow from a work-mate until I got Safari books:

Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson and Vlissides

Refactoring: Improving the Design of Existing Code by Martin Fowler

But wait? Where is The Mythical Man-Month by Fred Brooks? Good question. Darn thing is too skinny. It's always getting itself lost.

Programmer.Grrl: The Prequel

As I mentioned before, back in high school, I was pre-med. The interesting thing is, when I was about 15, I actually did take a programming class and really enjoyed it. It was BASIC on Apple IIe computers. I remember one of the projects being to code a dice game. What could be more fun that that? Not just playing a computer game—but creating one?

It didn't feel like school, it felt like play. And because it felt like play, and because I didn't know that programming was a real profession, when it came time to sign up for the next semester of classes, I decided I didn't have space in my schedule for Programming II. I needed to take more biology or chemistry or some such thing.

The problem was, where and when I grew up, in a small town out in the country and before the Internet, I didn't have any concept that what I'd done in the programming class was at all useful. I didn't make any connection between it and the software my family bought for our own PC clone—things like WordPerfect and Lotus 1-2-3.

I don't know that it's true, but I hope so, that the Internet has opened childrens' horizons, so that when they think about what they want to be when they grow up, they understand there is more available than the professions they see in their everyday lives. Because when I think about that programming class I took when I was 15, I always wonder what a better programmer I might be if I'd kept with it from way back then.

It also makes me think more about how people end up as programmers in general. One of the original joys of programming when I was 15 was that I was making something. Most of my life, especially my school life, didn't produce anything remotely tangible or useful. It was about completing assignments or studying for tests, where once the assignment was done or the test taken, it was over, and the graded paper or test wasn't useful in any way.

But programming was different. You could tinker around and write some code and have something useful when you were done. Making something—something that other people might even really like—it's a rush. I'm sure there are other programmers out there who got interested in programming because of that. And for us, that's one of the frustrations with Big Design Up Front or with other processes where it's difficult to link end-user value back to our own work. Even if the process works for the organization, it can be tough for the individual.

Companies are Addicted to Profit Like Smokers are Addicted to Nicotine?

What I believe and what I'm discussing are two very different things. I absolutely can't agree more with pretty much everything Jim says in Define success....

My worry is that if an organization views its projects as successful, the argument that the success isn't sustainable may not be compelling. If so far, using its current methods, the organization has been making money, and as far as its managers can see, will continue to do so in the near future, how do you convince those managers that it needs to change?

It's even more difficult than convincing a smoker that smoking will kill him eventually, and that he should stop—at least in a logical sense. An organization isn't an individual, whose best interests are intrinsically aligned with the longevity of his body. An organization is a collection of individuals, who can leave at nearly any time. If the organization's methods aren't sustainable—if it won't make it through the next 50 years—how many employees really care, as long as they are currently able to cash their paychecks?

It reminds me of Alan Greenspan's testimony about the economic meltdown: "Those of us who have looked to the self-interest of lending institutions to protect shareholder's equity—myself especially—are in a state of shocked disbelief."

Yes, it's a shocker. It turns out that not everyone in an organization cares about its longevity, as long as they get their cash and escape before it implodes.

But let's assume better of employees of software companies, especially since most I've encountered really do seem to care a lot more than that.

It's still hard to convince people to change when the current model is "succeeding."

In organizations where meeting yearly financial targets takes higher priority than continuous improvement, the continuous-improvement conversation can end up working like this variation of being too busy sawing to sharpen the blade:

Lumberjack: Say boss, this blade is getting dull. It's getting slower for me to cut down the trees. I don't think we're going to make our quota.

Supervisor: You have a point. How long do you think it will take for you to sharpen the blade?

Lumberjack: I'm not sure. Since I've been working here, we've never sharpened the blades, so it's difficult to estimate how long it would take, because I'm out of practice. Plus, the blades are pretty dull, so it probably would take longer than usual anyway.

Supervisor: Hmmm. I'm not sure we'll be able to make our quota if we don't know how long it will take. We can't risk that. At our current rate of cutting, we can still make the quota if we hire in a few contractor lumberjacks. We'll do that.

It's not necessarily that the members of the organization don't want to improve—they may just think they don't have time given their current constraints.

And as far as the greater organization is concerned, they still made their quota. As far as it's concerned, everything is hunky-dory.

So, I'm back to the question. If the organization thinks the project was a success, but some people do not—some people think that success will be unsustainable in the long run—how do those people convince the rest of the organization that change is needed now?

What If Your Unsuccessful Project Wasn't?

In Large-Scale Project Doesn't Equal Large-Scale Development, Jim Fiorato concludes that "The concept of parallelizing development with a large team to deliver a large amount of code for a large project all at once, is in my opinion, well... broke."

The only successful large projects I've been a part of have consisted of small development releases.

and

With the "large scale development" mind set, the odds are stacked against you. You'll find that you've fallen short on what you've envisioned, fallen short on your timeline, and probably done some irreparable damage to your talented team.

My concern is, so what? Just because a project fell short of what was envisioned, blew the timeline, or damaged the team, does that mean it wasn't successful?

Did the software release? Did customers pay for it? Is the organization still in business?

And if so, do you think the organization viewed the project as a success or a failure?

FireFox 3.5: How To Bring Back "Close Last Tab"

First, in about:config, set browser.tabs.closeWindowWithLastTab to false.

Then, add the following to userChrome.css (via comment on Veera Sundar's blog):

.tabbrowser-tabs[closebuttons="alltabs"] 
    > .tabbrowser-tab > .tab-close-button 
{
    display: -moz-box !important;
}
.tabbrowser-tabs:not([closebuttons="noclose"]):not([closebuttons="closeatend"]) 
    > .tabbrowser-tab[selected="true"] > .tab-close-button 
{
    display: -moz-box !important;
}

IronRuby & rake-dotnet

I'm back from attending a talk on IronRuby and rake-dotnet.

I haven't had much any time to play with Ruby, so a lot of what I took away is pretty basic:

• You don't need to use parentheses when calling methods. That contributes to the magic you see when it's used for writing business-facing tests and DSLs.
• IronRuby is much closer to 1.0 than I thought, only about a month away.
• Theoretically, you can use it to do Cucumber and RSpec, though that wasn't quite working in this particular demo at the moment.

Anyway, it was interesting. Thanks to Gojko Adzic for organizing it, and Michael Delaney and Peter Mounce for presenting.

Happy Anniversary to Me

Today marks 10 years since I got my first real job in technology, so I thought I'd share how I ended up where I did.

Once upon a time, I was a high school student and I wanted to grow up to have a well-respected, dependable, well-paying job. So, I started at university on the pre-med track.

I pretty much hated it. But I'm not a quitter, so I only admitted that I wanted a change once I was 3 years into my degree, when I'd completed all of my pre-med requirements.

So, I was ready to switch to something else. But I had no idea what. What was I good at? I wasn't really sure. Maybe I'd try writing.

As luck would have it, a nearby medical technology company was looking for a technical writing intern.

Being a technical writing intern meant helping write user manuals. I didn't like that much. Among other things, it wasn't much fun because you spent a long time laying things out in a desktop publishing program, not really quite exactly sure how they would look in the finished product. You had to wait for every single page of the manual to be done, send things to the print shop, wait a while, and only then finally get to see the real deal.

But the other thing going on at that medical technology company, back in 1997, was that they were starting to provide online access to those user manuals on their website. And that duty fell to the tech writers.

So my boss sat me down with a Laura Lemay book and told me to learn HTML.

And I was amazed. I'd seen all sorts of totally awesome stuff on the World Wide Web. I had no idea it was this incredibly easy to make that stuff.

And quick, too. You could write your HTML and put it up where the whole world could see it immediately—none of that waiting for your manuscript to get printed and distributed.

...

Well, it's getting late, and I realize I don't have time right now to bore everyone with my life's story over the 2 years between when I first discovered HTML and when I graduated from university and got my first job as a Production Assistant, a.k.a. HTML-writer.

Or about how I went from writing HTML to coding in ASP 2.0, to coding in VB6, to coding in .NET C#.

But one of the ironies I reflect on occasionally, is how one of my initial attractions to the web was instant publishing.

And how these days, the projects I work on often take months to go from idea to being live.

Just like those user manuals I wanted to escape back in 1997.

Notes from Gojko Adzic's "What is FitNesse and Should I Use It?"

Last week, I went to What is FitNesse and Should I Use It? by Gojko Adzic.

I was struck by the difference between two of his slides:

And a slide from a different talk about FitNesse that I'd attended a week earlier:

To be fair, Gojko said that it's very easy to hook lots of different kinds of testing into FitNesse, and he had been as guilty of it as anyone else.

Here are a couple other good things I picked up from Gojko's presentation that I hope to put to use:

• Focus on "what" and not "how". Don't try to translate test scripts into FitNesse—that's "how" and can lead to having a lot of similar or duplicated setup code. In fact, if you find yourself writing many similar tests, you're probably focusing too much on "how".
  
  
• To keep your tests as living documentation, separate them into to main categories: tests for the current release and tests for previous releases organized by feature. At the end of each release, move the tests from that release into the other category.

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.