From ScrumDevelopment Yahoo Group:

Someone who is
all into architecture, especially if they mostly don’t get to code
it, are probably already worried that their ideas may be too little,
too late, or may be screwed up in the implementation.

Now, everyone is being asked to believe that architecture can be
grown. That’s hard to take in, without experience. And the
experience of doing architecture up front is already pretty poor …
things never seem to turn out as well as the architect imagined. He
imagines that he needs to do more architecture next time, not less.

And he’s right. The thing is, architecture needs to be done throughout
the project, not just at the beginning. It needs to be done in view
of what the code is, not just what it will someday maybe be.

Did we all get that? It needs to be done in view of what the code is, not just what it will someday mabye be.

Kathy Sierra’s keynote at RailsConf set the tone; DHH passionately attacked the
Vendoritus, exposed by the incident. And boy was Dave Thomas passionate about ignoring FUD.

Sorry about the handwriting.

Links:

• Why the lucky stiff


• Why’s (Poignant) Guide to Ruby.


• More on splat. Note that the foxes are wrong about it being just 1.9 stuff. Never put your complete faith in a fox. Look what happened to the crow with the cheese.


• More cartoon foxes

Talking of pretty damned good RailsConf presentations, the one I’m most glad that I attended is Dan Webb’s unobtrusive Ajax. Dan’s approach feels so right: make it work the simple way first, then unobtrusively add Ajax later.

The key difference between Dan’s approach and the standard Rails form_remote_for, is that Dan’s approach does not break the non-ajax method. Apart from the obvious accessibility advantages, it is a much more incremental way of coding your application; you don’t need to break it to add the Ajax, so the tests for the non-ajax code will still pass.

Dan’s presentation is available here; his example applicaton is here; his UJS plugin his here.

Jerry’Weinberg’s consulting target is to be able to answer no to this question:

After I leave, is the client less likely to hire a consultant than they were before?

I am not less likely to book on RailsConf 2007. I suppose that sounds a bit of a left-handed compliment, but it’s not. It makes me a (probable) repeat customer. And it’s a good enough target for Jerry Weinberg.

The plenary speakers were excellent; the Q&A session with the core team was fascinating; some of the sessions I attended were pretty good too. I’ve come back with a lot of stuff to think over. There was something missing, though. There wasn’t the buzz that I expected; perhaps not a universal feeling, but from the conversations I had it wasn’t just me.

What was missing? It’s hard to pin down. I suspect that it was more us (the delegates) than them (organisers / speakers) though.

Tentative, is how I’d describe the atmosphere. It felt like a large gathering of outsiders. Maybe the (European Rails) community just needs to grow; maybe an on-campus location, sit-down meals together, and a few workshop sessions in the mix would have helped; maybe not.

Next year, Berlin.

One of the chapters that really grabbed me from Chad Fowler’s My job went to India, was “Making the hang”:

…the short story is this: the really good people won’t mind if you want to know them. People like to be appreciated….. The fact that they are the professional, or the guru, or the leader or the renowned author doesn’t change that they’re human and like to interact with the other humans.

Well just back from European RailsConf 2006, and didn’t make no big name hang. Thought of, but too shy – nothing to say. I was very impressed with the way Alan Francis had just got chatting with Marcel Molina and Jim Weirich, though. Then I read his blog.

Update: I really ought to close the circle by linking back to Alan and Chad again.

Gaping Void:

FIT is Ward Cunningham’s increasingly popular framework for writing acceptance tests. I’m a huge fan, but when I first encountered FIT it took me a while to figure out the point. I originally misunderstood FIT to be a framework for functional tests. It isn’t. A lot of people make that mistake.

Watir drives tests through your browser. JWebunit plugs HTTP and HTML into Junit. Watir and JWebunit are functional testing frameworks. FIT just helps you realise tests that you’ve written as HTML tables using Java (or other) code. While many FIT tests also end up being functional, it is quite acceptable for them to cover only a small unit of code.

The point of FIT is to describe the behaviour of the application using tests in such a way that a non-programmer can easily understand. You write a functional specification that has been tightly bound to the code.

It’s December 1998 and I’ve been working in the Software business for little over a year. Through a mixture of arrogance, ignorance, and gonzo(2) project management our small team is on client-site fighting a desperate rearguard action to maintain a massive software release that has no back-out plan. We are facing massive performance issues with our client-server application. Each of the several hundred users has at least one connection open on the Sybase 11.x server; prone as it was to blocking and deadlock problems, the users are experiencing many blocking and deadlock issues which are aggravated by a flaky and slow LAN.

One particular blotter(3) is contentious: the browse all trades view. At any time it seems a score of the users are searching (and locking) all the trades. We don’t think this view is needed; the BAs tell us that the users insist on keeping it. Bloody users, eh? Eventually, breaking the unwritten rules, a BA forces me to see a user.

“Can you show us how you use the All Trades Blotter?”, says the BA.

“Ok. I need to find this trade for ‘XXX’, I’ll load the blotter and order by fund. Now it’s in Swedish Krona so I’ll order by currency. Scroll down…… Ah there it is.”

Bang! It’s immediately obvious that they need a search function. I wrote one. They loved it. They stopped using the All Trades Blotter.

Lessons:

• The users were not being obstructive. They genuinely needed the functionality from All Trades. Everyone’s just trying to do their job.
• It’s true that often users/customers don’t know what they really want. If you don’t talk to them, though, neither will you.