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.