From Job recruitment spam

Please note it is essential that applicants have worked in a structured development environment ideally utilising the Agile (SCRUM, XP) methodology or any other similar methods such as Waterfall, RAD or RUP.

Sunday, May 04, 2008 | Permalink | 0 Comments

Scotland on Rails

It’s over two weeks since the Scotland on Rails conference. All the feedback, and the general feel of the event, convinces us that it was a huge success. Conferences, like parties, are complex beasts: there’s not a straightforward relationship between cause and effect, and even the success criteria cannot predicted in advance. All us organisers can do is control the starting conditions, lay down some boundaries (start-stop times, meal breaks), scatter some attractors (presentations, talks, beer and pizza), and hope something good emerges.

Nether-the-less we humans are hard-wired to see causal relationships and despite myself I can’t help believing some of the following helped:

• Having one and a half tracks. There’s much to be said for having a good proportion of shared experience amongst the attendees, while the extra half track enabled us to use more of the (excellent) submissions and achieve a good balance of local, international, new, and experienced speakers.
• A superb venue (by and large), with lots of room and natural light between sessions. The Edinburgh First staff were amazingly helpful; I strongly recommend them for other events.
• A great T-shirt design (thanks Bruce Williams). T-shirts are important for techie conferences, establishing identity amongst the attendees. You wear the t-shirt; you reaffirm having been there.
• The Crags pub opposite the venue served as a good focal point for evening meetups. It was easy to find, spacious, served food, and most people were there. Ok, it’s not a fantastic pub, and it was a pity that many of the US visitors didn’t get much further afield, but having one place to meet in the evening added to the feeling of community
• Big-name, international, and up-and-coming speakers. I don’t know for certain, but it feels like our decision to invite Koz early on changed the nature of the event from a small local affair to an international conference. It certainly helped give us the confidence to go after other speakers and sponsors.
• Edinburgh is a lovely city, and a world-tourist destination. I wonder how much that influenced our US peakers and delegates.

There were a lot of other factors, and we’ve learnt lessons we’ll apply to next year: particularly on the marketing side. Maybe Scotland on Rails 2009 will be even better.

Labels: scotlandonrails

Tuesday, April 22, 2008 | Permalink | 0 Comments

Thought for the day

Agile projects have no real defensive walls; all they can do is deliver return on investment and hope the business values it. But we all know that ROI is only a part of what moves businesses. Those in the Agile world all know of resistance to Agile from those middle managers who see it as a threat to their power to command and control. Telling such a person that her sabotage endangers the company's ROI is like an abbot standing in the path of Christian raiders and threatening them with loss of their immortal souls: sometimes it works, but nowhere near often enough. And it never works with the worshippers of Odin.

Brian Marick

Thursday, March 13, 2008 | Permalink | 0 Comments

Acceptance testing with FIT

Last month Brian Swan and I gave a pretty damned good talk for Agile Scotland on Acceptance Testing with FIT. The feedback was great, anyway. The slides are here.

If you missed it, don't worry. We could be giving the talk again at Developer Day, Scotland. If you want to hear the talk, you need to register and vote for us here.

Tuesday, February 19, 2008 | Permalink | 0 Comments

Scotland on Rails Registration now Open

At last, Scotland on Rails (4 – 5 April 2008) registration is now open, and we’ve managed to keep the price low: it’s £180 for two days. We’ve keynotes from Michael Koziarski and David Black, not to mention a strong line-up of sessions (includes Jim Weirich for God’s sake!) from Europe and the USA.

Register here. Oh and don’t forget the charity tutorial on Thursday April 3rd. We’re firming up the details, but that’s going to be well-worth the £75 (minimum) donation to the Children’s Hospice Association Scotland.

Sunday, February 17, 2008 | Permalink | 0 Comments

Scotland on Rails Speaker list

The full Scotland on Rails speaker list is now available here. It's an impressive line-up, with a good mix of "names" and local talent.

The conference will 4/5 April 2008, at University of Edinburgh's Pollock Halls. We'll be opening registration soon.

Thursday, February 07, 2008 | Permalink | 0 Comments

Unit tests are best

Last year I was reading Eric Raymond’s The Art of Unix Programming and was struck by the statement that “debugging often occupies three-quarters or more of development time”. Yes, I thought, I remember when that was normal. In the old days I used to spend a few hours coding something, then the rest of the day working out how I’d done it wrong.

These days any time spent regularly debugging is a sign of something wrong. That’s a significant, and short-term, productivity gain of Test Driven Development that’s often forgotten. Done properly TDD means when you’re done, you’re pretty confident that you’re done. You can go on and do something else.

TDD is mostly about unit-testing, and the trouble with unit-testing is that it’s only the units that get tested. The interactions between the units can be left out, and that’s where the errors creep in.

Let’s say you have a class that represents a spreadsheet; another class is responsible for populating the spreadsheet. They are both thoroughly unit tested, but one assumes the row index is zero based and the other that the row index is one-based. You may have a bit of debugging ahead.

Functional tests are commonly used to plug this gap.

Functional tests are great. They are worth having to boost confidence in the general correctness of the code; but they are a safety net. They are not a good place to be catching problems: they run on a slower feedback loop than the unit-tests and when they highlight problems, and because they cover bigger chunks of code it can be tricky to find the source of a problem: they bring you back into debugging land. They also tend to take longer to run, and complicate the build. And they can be a pain to set up, especially if you need lots of supporting data.

You can reduce your reliance on functional tests by minimising the assumptions made about the rest of the code in your unit-tests. One way to do this is to steer clear of the Mock Object fetishism that is sweeping the nation(s).

Use the real objects when you can. Sometimes, though you do need to fake things.

Let’s say you’ve some Java code that produces Json to be consumed by an Ajax request from a browser and processed by Javascript. You can unit test the Java with Junit; you can even unit test the Javascript with Jsunit. But are you confident that it all works together? Selenium or Watir tests would do the trick, but bring us back into functional testing land.

How about for each of the Json states you test in the Javascript, you make sure you have a Java test that covers producing that Json. Save off the Json and use it in both tests. Now you have pretty much all of that functionality covered in Unit Tests.

Keeping the bulk of your tests is best for rapid feedback cycles and increased productivity. You may need some functional tests, but maybe not as much as you think.

This post is a rehashing of the talk I gave on the January 19 Naked Agilist podcast. I fluffed it, I’m afraid but I would still recommend listening because the other speakers were great.

Labels: functional tests, Jsunit, Junit, TDD, unit tests

Wednesday, January 23, 2008 | Permalink | 1 Comments