Now we're cooking

I've only recently started using a laptop all day every day, so I thought it was time to put to use a trick shown to me by some buddies for making the all-day laptop experience a lot more ergonomic. So a quick trip to the homewares store for a cook book stand, and bingo! You've got the screen at eye level. Check out the picture for an idea of how it works. You need to invest in an external keyboard and mouse, of course, but it's the poor man's docking station. Start a fashion trend in your cube farm today!

Flat Out in First

Imagine you're driving from one side of the city to the other with a friend and you're in a big hurry. You're running really late and you're desperate to get where you're going. To your amazement, your friend sets off down the road and puts the pedal to the metal in first gear. He's gripping the wheel, concentrating fiercely, the engine is screaming, and you're being overtaken by every car on the road, doing about 30kph.

You say to your friend, "Hey, don't you want to go into second gear?"

But your friend says, "Don't interrupt me, man, I'm going as fast as I can and I really need to concentrate here"

You try again. "But we'll get there faster if you change gears!"

But your friend says, "No we won't! I tried that before and putting in the clutch __definitely__ slows you down, silly! And the last thing I can do now is slow down when we're running so late!"

The problem with development teams is that you can't actually hear the engine screaming and see the car shaking and feel the lack of speed. But it seems to me a lot of development teams are flat out in first gear. Agile development has a lot of practices that are all about changing gears.

An Agile Requirements Parable

In my current role I'm trying to introduce agile development into a team of about 30 people. One of the challenges is the approach to requirements. The incumbent process is pretty standard waterfall with requirements documents that are both too big to read and too short to be used as the only input for development, as well as being written from an implementation perspective rather than a user perspective. As well as being written up front in their entirety before coding begins. So no news here.

But the biggest issue is (as usual) not a technical one but a human one, in this case the implicit belief that requirements can be 'captured' if you just think hard enough (and long enough) as opposed to the agile view that requirements need to be trawled for constantly, starting at a high level and increasing the resolution as implementation approaches, leaving the resolution lower for far-off things.

I unwittingly stumbled on a requirements parable the other day when, of all things, I attempted to buy a new pen. I succeeded in purchasing a pen, but I failed to get one that met all my requirements. I'm serious; I couldn't even buy a pen for myself that satisfied all my requirements. Read on if you are still on your chair.

So, why did I need this pen? I carry around a pocket notebook and a pen wherever I go, having learned from experience that freeing my brain from minutiae leaves it free to dream and create. I've tried other tools, PDA's, dictaphones, etc, but the good old pen and notebook just works. The definition of 'works' here is that the time and effort between being confronted with something that I need to remember but that I don't want to deal with emmediately must be minimised. I even have a kind of code for the notes I take to speed it up, and recently spent half an hour in a stationery shop buying just the right notebook (with high end features like one of those built in straps to mark your page). So I'm pretty serious about this pen. It has to be able to be connected to the notebook firmly so they can't be separated accidentally, and it has to have a broad enough point that my dim eyes can see what I've written.

So how did I go wrong? Well, the pen I've used for a long time started to become unreliable, so I had to replace it. It literally did not occur to me that the fact it was one of those ones that you press the top to extend the ballpoint was important. I was thinking maybe I'd try a felt tip pen rather than a ballpoint as the nibs come in wider formats. So I looked at the mountains of pens in the store and picked a broad-nib felt tip number with a clip that attached snugly to my notebook. So how long did it take to realise my error? The first thought I had that I wanted to write down, I pulled the unit out of my pocket, separated the pen and instinctively went to push the button to extend the ballpoint with one hand while flipping to the current page with the other. Only there was no button. There was a cap! That requires two hands (or one hand far more dextrous than mine) to pull off and put somewhere else, probably on the butt of the body of the pen. I was stupefied. I was now thinking about the damned pen and not the brilliant idea I'd just had.. If there is something you just want to stay out of your way, it's the thing between you and your great ideas.

So what's the moral of the story? I guess it's something like this: Assuming you are capable of defining requirements up front without exposing users to the solution is bogus. Even if the system is well established. Even if it's as simple as a pen. Even if you're so clever that you can read the customer's mind. :P