Blood, Sweat and Tiers

First post on Blogger

2009-01-19T02:44:00.000-08:00

I'm moving my blog over to Blogger, so if you're reading this, it means you've found the new location. Well done :)

With a little luck, all the old posts from Moveable Type will get imported in the next few days and I can retire the old site before it gets bulldozed!

Nostradufus

2008-09-24T10:01:00.000-07:00

Our company holds an annual conference where customers from all over the country come to see and hear the latest goings on with our rather large software product. I get up and give a couple of presentations at this event, generally covering our technical evolution and our high level plans for the coming year. Being of the agile persuasion, I have advocated a convention of three releases per year with published guidance on what's likely to be included in each release over the next year. This lets customers into our view of the collective priorities but allows us to remain flexible as we roll along. This guidance gets republished after each release so there is always about a year of product roadmap visibility that customers know is likely to change.

So much for the back story. As I started preparing for this year's conference, I looked back at last year's presentations to remind myself what I'd said. I had one slide for each of the forthcoming three releases, with about four features per release, for a total of 12 feature predictions for 2008. Guess how many have turned out to be true? As I looked at the list I was quite surprised to find that not a single one of my 12 priority features had come to pass. Not one.

I sat back and pondered this for a bit. It's not like we hadn't done our three releases right on time with a slew of very well received initiatives that most customers agree are taking us where they want to go. Our development team has never been so well respected for what it has achieved over the last few years, and the consensus is that the challenge now lies with the customers to keep up with us after a decade of the reverse.

All I can say is that even when you make predictions that you think are safe, even when you give yourself room to move, even when you profess agility and despise those practices in your profession that seem to think the world can bend to the gantt chart rather than the reverse, even when you have the inordinate luxury of making your own deadlines and correctly frame your horizon scans as guidance and not promises, you can still fool yourself into thinking you know something that you don't.

The good news is that taking an agile approach means you talk to customers frequently enough and update them on what's happening and why frequently enough that you have no qualms about having a laugh about this with them because they, too, are focused on this year's progress, not last year's plan. I'm just glad my salary isn't tied to my ability to follow a plan, because I can't even follow one I created myself!

The Truth or a Comforting Lie?

2006-10-08T03:28:00.000-07:00

Long time no blog. I've been distracted in recent months learning about non-geek stuff like investing in the stock market, which I may blog about at some point. But what has inspired me to pick up my virtual pen again is the apparent mainstream rise in popularity of agile development. Bear in mind that I'm in Australia so your time lines may vary, but these days there are very large organisations stating agile development as a key aspiration and sending head hunters around about scrounging for anyone who can spell it correctly to lead them to the promised land. Five years ago we relatively early adopters of eXtreme Programming would band together and tell each other stories of what a wonderful world it would be when major banks and telcos saw the light and changed their evil waterfall ways. Now it seems we may have gotten what we wished for and perhaps we should have been more careful.

Refer to Martin Fowler's recent post on how top-down imposition of agile is pretty un-agile by definition; he's far more calm and articulate then I am. But as someone who has seen agile succeed and fail, I thought I'd throw my opinion into the ring for a bit of perspective for the recently converted. The greatest success with which I have been involved personally was simply awesome. A true agile poster child project: the brochure for it would tell you that we estimated it almost perfectly, delivered it on time and on budget, have had so few bugs in two years of production use that you'd have several fingers left counting them digitally, and the system transformed the business in a truly fundamental way. And we're not talking about a small project here: 20 people all up for 18 months and several million dollars. This is all absolutely true. What the brochure would fail to mention most likely is that we clashed with several internal stakeholders to the point where I was excluded from the building for a week in the middle of the project, that we needed the best team of developers I've ever seen to pull it off, the best project manager I've ever seen, the best iteration manager, customer representative and analysts and we had to fight off any number of die-hard process nazis who did not share our value system of actually delivering something of value (think Vogons). The brochure would also fail to mention that the organisation that witnessed this startling occurrence was quite committed to hiding this anomalous project like an embarrassing relative; you see, we outsiders had been brought in as the third attempt at this project in three years, and were set up to fail. The brochure probably would not mention that either.

Where I've seen agile fail is quite simply when you don't have all of these things working for you. Like having a distracted customer who can't spend the time with the team. Like having developers who really don't care about the craftsmanship of their work. Like having analysts who just type requirements into documents without any actual analysis. Like testers who just do the happy scenarios because the other ones are too hard. Like having a project manager who focuses on avoiding failure rather than achieving success. The problem with agile is that any one of these can severely damage or even kill your project despite the health of the others.

So the good news is that agile can and does work. The bad news is that agile can and does fail. So what are you to do? Looking back on that successful project, what made it work was, unfortunately, probably the same old things that have made any project work in any human endeavour since human endeavours began; highly skilled and committed people who bust a gut, put their necks on the line and get really lucky as well. And guess what? If you took these circumstances and did waterfall, you'd be just fine. What agile is great at is failing fast and eliminating waste. The feedback cycles are there to detect and correct the course of the project almost as soon as it starts. I'm not sure how common this expression is, but when someone asks you a question to which the true answer will be very upsetting for them, the initial response is often, "Do you prefer the truth or a comforting lie?" That successful project had been estimated prior to my team's arrival. When we took a look, our estimate was 3.5 times higher and the duration was twice as long. We had extreme pressure to just hide our estimate and do the typical budget blowout thing later on. Not doing so and being honest nearly killed the project before it started. Agile is for those who can handle the truth; waterfall is for those who prefer the comforting lie. Either one may be right for you and your organisation.

Speed Read With Your Eyes Shut

2006-05-27T17:01:00.000-07:00

Q: What do you get when you cross:

* your Mac
* your ipod
* Project Gutenberg, my favourite source of great literature in goold old single-file ASCII text
* Cepstral William, the sexiest robot text-to-speech voice around, and
* Audio Hijack Pro to capture whatever William says and turn it into bookmarkable mp3 files to put on your ipod...?

A: A supply of the world's best audiobooks that will last longer than you will, that you can take anywhere with you, enjoy with your feet up and your eyes closed (unless you're driving, of course). But not only that, unlike a normal audiobook that you might buy from Audible, you can crank the speed up to whatever your brain can handle! Speed reading with your eyes shut. Cool.

Joining the Rails fashion set

2006-04-25T03:18:00.000-07:00

Last weekend Simon and Stuart The Blogless and I joined the fashion set by putting our first Rails application into production. It's a real estate web site for a beautiful part of Australia called the Southern Highlands (about an hour from Sydney). You can visit Campbell Jones Property for a look if you like.

A few features of the site:
* the constrained box design was chosen by the client so don't blame me!
* funky interactive map on the search page - go Stuart!
* little ajaxy forms to submit feedback without doing page refreshes
* main image on the property listing page changes as you hover over the thumbnails
* client-side scrolling of bio information on the meet the team page

A few 'behind the scenes' things:
* all the images are in a Postgres database but are cached by Rails as they are used
* images are uploaded in hi-res by the client and crunched on the server using ImageMagick to generate the various form factors required for the site - a real time saver for the client
* lots of admin screens for updating listings, team members, etc

A few lessons learned as a J2EE guy working on his first Rails app:
* Rails makes the backend stuff so easy that the pain in the butt becomes all about the HTML and CSS - by far the most painful part on such a pixel-perfect design like this. Normally on a J2EE app you don't notice because everything is that painful!
* Postgres rocks
* Rails caching is very cool. The site warms up nicely
* database migrations are good but you can't sustain writing them using model objects if your model is changing (which it will). So you're basically writing SQL for migrations, but that's ok
* some of the Rails association stuff is a bit weird, but the worst thing is some of the 'silent failures' you get when saving related records. Never a good idea.
* some of the Rails plugins are a bit naive. For example, acts_as_list, which lets a model include positional ordering, doesn't let you put a UNIQUE constraint in the database for the position column as the update code is not transactional. Hope to find some time to fix that one.
* Rails routes rock

So what's the conclusion about Rails? Is it perfect? Hell, no! Is it productive? Hell, yes! Does it beat the J2EE stack for database-backed web apps? By a country mile. I will not choose J2EE over Rails to build such an application, that's for sure. To be honest, it feels a little like the Mac/Windows discussions I find myself having reasonably regularly. To say something is way better than something else does not mean the thing is perfect. It just means it's better. Rails is like that - it's not perfect, it's just way better. I sincerely hope that Rails does not go mainstream or we'll all have to go find something else to be our competitive advantage. May the industry behemoths ignore Rails for many years to come!

The 'Things That S**t Me' List

2006-04-16T10:59:00.000-07:00

As a card-carrying member for several years of the cult of 'Getting Things Done', a way of running one's life that has proven hugely beneficial, I find that every year or so I tweak and extend the system in an effort to make it work better. For example, I've tried several different computerised systems to implement the GTD methodology, from Personal Brain to GTD Tiddlywiiki to Mind Manager. My latest incarnation is some hand-written shell scripts using a command line (bash shell) that runs on both Mac and PC and is super-fast to use. I'll blog about this in more detail some time soon.

But now I have stumbled across an enhancement to the methodology itself. If you're not familiar with it, it's basically a personal workflow system wit major steps: collect, process, organise, review, do. At first it's hard to get your head around how much work you have to do before you do any work! There are also several defined lists that you maintain, such as agendas for each person you interact with regularly, a list of things you're waiting for others to do, a 'someday maybe' list, next actions lists organised by context (such as home, work, online, travelling, out and about) etc, etc. The idea is that you capture everythhing (and I do mean everything), review it regularly and enable yourself to notch forward on many fronts in small increments in a context-optimised way just like a multitasking operating system.

So I offer to the GTD community my personal recommendation to maintain a 'things that shit me' list. Keep it up to date, capture new things into it often, review it every week, and use it as inspiration to make improvements. If you think I'm being flippant, think again. When you're angry, frustrated, stressed,or otherwise unhappy and the solution isn't immediately apparent, it's an effective short circuit just to name it, look at it next to all the other things that drive you nuts, and choose when you have the energy and time to pick some of them to turn into projects in your GTD system for improving your life. There is a very good feeling when you delete something from this list, let me tell you, and that's the real key. It's a smell if all you ever do is add to it, so make sure you pat yourself on the back each week by knocking something off your 'things that shit me' list. You'll be a nicer person to be around and that is probably the biggest benefit of all.

I assume you're interested in an example, so here's an excerpt from my current 'things that shit me' list:

The leaves in the skylight in the kitchen
I don't have enough storage space in the office at home
my house keys don't open the side door
the way my phone only starts telling you the battery is low when it has a minute of life left
I can't use my little dictaphone in bright sunlight 'cos I can't read the screen
the tree that overhangs the carport
I haven't figured out how to do my fortnightly trips with just a backpack
you can't get clip-on sunnies for my glasses
I'm not set up to scan things conveniently at home or at work
the handrail in the bathroom keeps falling off
the laundry door leaked in the last big storm we had
I never have time to play the drums
theres piles of mysterious crap in my book case
i am notsure if priorities in my gtd system should be related to projects or actions
i get so much comment spam on my blog
moving around the screen on the mac when the zoom is on is too slow
i cant print on my home printer when i'm connected to the vpn
the plumbago outt the front is out of control
wikiwords seems to have been turned off in the wiki
ruby barking drives us mad
the hard drive on the mac is just about full
i do not have a functional tickler file at least electronically
i have no way to track how much support work we're doing versus project work
we don't use a single issue tracking system
i can't print from the mac on my home network

A Revised National Anthem for Australia

2006-03-23T13:18:00.000-08:00

To celebrate the 10th anniversary of the most pathetic government in Australia's history (I mean, really, how you can keep a straight face sending troops to Iraq while funding the Iraqi regime via the AWB and locking up those who flee the chaos and seek asylum with no legal recourse is quite beyond me), I hereby present a revised national anthem in Little Johnny's honour. Just in time for the happily frequent renditions at the Commonwealth Games:

"Advance Whose Skin Is Fair"

by James Ross

Australians all let us rejoice
For we are rich and white
With golden soil and lust for oil
We reckon she'll be right
Our land abounds in nature's gifts
We've never learned to share
In history's page let every stage
Advance whose skin is fair

Beneath our radiant southern cross
We'll toil with hearts and hands
To make sure noone different
Sets foot upon our lands
For those who come across the sea
We've prison cells to spare
With courage let us all combine to
advance whose skin is fair
In joyful strains then let us sing
advance whose skin is fair

Copyright © 2006 James Ross. All Rights Reserved. Of course. This machine kills fascists.

We now return you to your regularly scheduled program of agile software development....

Signal to Noise Ratio in Rails

2005-12-24T02:24:00.000-08:00

Like all the other Mac-toting fashion hounds, I've been playing with Ruby on Rails of late. I have the good fortune of having a buddy who has a paying gig building a Rails site and he is kind enough to give me commit rights so I can use it in a meaningful way without giving up my day job as a J2EE guy, and without having to find an excuse to use it at work.

Without getting all hysterical about it, there are many things in Rails that should give pause to the J2EE crowd. When I switched from C++ to Java, the thing I liked most about coding in Java was the much improved signal-to-noise ratio compared with C++. I found I spent much less time thinking about computer stuff and much more time thinking about the problem at hand and the concepts of the problem space, largely ignoring the problems of the implementation space. This was partly the language, partly the libraries, and partly the community around Java at the time, but when you add it all up, the result was better software faster, which is really all I want.

Now, having used the classic J2EE stack for a while (Struts/Tiles/Hibernate, et al), and having watched J2EE vendors bloat their products to the point of collapse, using Rails has given me the same feeling. No struts-config.xml, no tiles-defs.xml, no *.hbm.xml files, and much less time thinking about the machine and its implementation layers. The signal-to-noise ratio is simply better than in the form of J2EE I've learned. Ruby/Rails also appear to have the libraries and the community to make the whole stack work. The whole setup feels more supple and malleable than Java, and, since that feeling was what attracted me to Java, that has to be a concern for those who think Java is some kind of universal maximum, rather than just a local one, as all technologies are.

There are some things in Rails about which I retain mixed feelings. ActiveRecord seems to me to be less of an O/R mapping layer, and more of an O/R unification layer. This caused me severe brain ache for a while, but I'm suspending disbelief for the moment. The unit testing model involves database access (and lots of it), which is a definition of unit testing I've always disliked strongly. The functional testing model (so far as I have looked) doesn't use a model based on parsing and filling out and submitting the HTML forms served by the running application. It appears to be more a controller-testing setup than what I would call a functional testing setup. But I'm only a newbie and might have missed some stuff.

Brain Fade?

2005-11-22T02:31:00.000-08:00

How can the most important application I have be so neglected by its creators? I've been waiting a year and a half for a new version of Personal Brain and this is what I get - half a dozen fixes to bugs I hadn't noticed and not a single new feature. One of the highlights is that they've updated their phone number because they moved offices! I don't know if this company is starved for resources, but if ever there was a company that deserves some, this is it. I hope I don't jinx them and they get snapped up by Microsoft and ruined, but this slow death is possibly worse!

Now we're cooking

2005-10-28T15:40:00.000-07:00

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

2005-10-27T11:05:00.000-07:00

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

2005-10-22T08:14:00.000-07:00

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

Back in the iLife

2005-09-03T15:02:00.000-07:00

When I started my new job a few weeks ago, I had to wait a while before my new laptop arrived from Dell. So I turned up on the first day with my Powerbook and plugged in. I was very pleased to find that Apple Mail knows all about Exchange servers out of the box, so I was up and running with no problems and went on happily for a couple of weeks. When the Dell arrived, I spent a couple of days with both machines on the desk while getting it all set up. It was only after switching the Mac back to home use mode and starting to use the Dell for work that I was struck by an obvious solution to a problem I'd been facing for a long time. One of the reasons I switched jobs was in pursuit of a better work/life balance. To me this means drawing a sharper line between the two something I've struggled with in recent years. And here I was looking at the solution: use one computer for work and another for life. Sounds simple, but I missed it until now. So now the Dell stays off over the weekend (it stays on long enough to check the week's work in to CVS at home), and doesn't get looked at until Monday morning. The Mac, with photos, videos, electronic books, music software and fun geek stuff like Ruby and Objective C stays on all weekend and is nothing but fun. Nice.

It's Mac time now...for my old man

2005-08-18T09:18:00.000-07:00

It's been a while since I blogged at all, having been a little busy switching jobs, having recently also switched computers (to a Mac Powerbook) and having tried to switch programming languages (learning some Objective C, which is lots of fun). But I'm convinced enough by my Mac experience to have convinced my dear old dad to jump as well (to a Mac Mini) on the demise of his old PC. So does that make me an official cult member? I've also started thinking that one of those flat panel iMacs will look pretty good next to the espresso machine for my wife and daughters to use......:P

It (sort of) just works!

2005-06-14T15:41:00.000-07:00

A lot of my geek buddies have been switching to the Mac over the last 18 months or so, and with the new FBT year rolling around, I thought I'd get a half-price PowerBook 15-inch with all the bells and whistles to join in the fun. For those of you not in Australia (shame on you), there is a tax law here that allows anyone to buy a laptop each year with pre-tax dollars. This is a great deal (since our top tax rate is almost 50 percent) and is very popular as you might imagine.

Anyway, I'm showing my age by saying it's 19 years since I last had a Mac, so I knew things would have changed quite a bit in the meantime. I've been reading 'Mac OS X The Missing Manual' while waiting for my machine to arrive so I already had some of the keyboard shortcuts down before I had the box open. Which brings me to the first of my observations about the oft-repeated cries of "It just works" by the MacCult members...don't get me wrong, this little baby is a beautiful thing, but in the interests of full disclosure, I thought I'd jot down my notes on the switching experience...

Getting the machine delivered was something Apple found quite challenging. I ordered the PowerBook, MS Office, iWork, .mac and Logic Express, and they got off to a bad start by shipping the software individually so that a couple of times when the courier's arrival at my house found nobody at home, they went away until we called them and could commit to waiting at home for a full day before they'd deliver. Not so bad for a single delivery, but when the order is part-shipped in four separate trips, this gets a bit old. Of course the software was no use without the machine, which didn't turn up at all. Problem was, the online order status page showed it as having been shipped many days ago. Several calls to the courier and Apple finally led to the discovery that the courier had returned it to Apple because the exterior box was slightly damaged in transit. Still no drama, except that Apple seemed to not have a process to keep it moving. I had to call them multiple times to get multiple people to find the box and ship it to me after testing that the machine was OK. Very annoying.

The machine arrived last Friday and with sweaty palms I fired it up. The warm, welcoming and soothing setup process came to a shuddering halt at the wireless network setup screen. No matter what I did, I could not get it to connect to my network. Now I know my 128-bit WEP key off by heart, so this should not be hard. Eventually I gave up in disgust and told it I didn't have a network at all. When I got into the OS proper, I found I had extra options, including to change its default WEP key size of 40 bits to the 128 I needed. Up and running immediately, but obviously unimpressed with the unnecessary dumbing down of the setup program.

A little later on, I cracked open my iWork 05 disc and stuck it in. Lo and behold, the machine refused to install the software because a later version was already installed on the machine. So I go hunting and find a trial version of iWork, which I start and am annoyed to find there is no 'enter the serial number from your boxed copy you just brought home from the store and I'll start working for you' option. So I drag the application to the trash, since that's what book said was all that was needed to uninstall an application. No dice. A call to a Mac buddy and a little Spotlight magic later and I find a couple of files in the /Library/Receipts folder, which has something to do with the auto-update feature for the software. Killing off the files and now I can install my software. This is software I bought with the machine, you realise. And the machine won't let me install it. This is not what I call 'It just works'

The rest of my installs go pretty much according to plan (after Office downloads the 50Mb of updates needed to actually get it to run properly). The only other disappointment was the Logic Express has not had the latest UI goodness like the rest of the apps that sport the Apple logo. They've done the box up nice, but the app must be one of those 'carbonised' ones they talk about.

Of course, before I could really start using the apps, I had to sort out the accessibility options. Being a visually impaired person, one of the things that tipped me to considering the Mac was the built in accessibility features, particularly the new VoiceOver software that speaks the UI to you as you use the machine. Annoying as all get out to anyone standing nearby, but pretty darn useful for me. In fact, as I type this, it's reading each word as I go. Overall, the software is good, and I can save the money I'd normally have to spend getting set up with specialist software, so I'm happy about that. It's got a few minor issues like jumping around a little crazily when the screen is magnified and the focus shifts, and not reading full paragraphs of text in Safari if they contain a (gasp!) hyperlink, but not too bad at all.

Things really started to crank when I got my head around expose, spotlight and some of the apps that come with it. iMovie is awesome in its elegance and simplicity and speed (I talk as someone who purchased Pinnacle video editing software for Windows) and iPhoto blew me away when I imported my six years worth of photos from its home in a nicely structured directory, and iPhoto turned the directory names into keywords that I can search, so 'Antonia's Wedding' instantly finds all the right pics. Awesome.

I find I'm not as productive when typing and editing text because I don't know all the keyboard shortcuts for selecting a word or a paragraph, but that will come with practice. It is true what they say that it just feels solid, and having a large number of apps open doesn't seem to have the same drag effect as it does in Windows. Now I just have to figure out how to replace all the apps I rely on like The Brain and Microsoft Money. I'm not in a great hurry as I invested in Virtual PC to ease the transition. I haven't actually used it yet, as I'm trying to just feel the vibe for now. And I must say it feels pretty gooood. I look forward to being snobbish and dismissive of my Windows colleagues very soon.

Too busy to blog

2005-05-15T14:41:00.000-07:00

Lately I've been too busy to blog, as I've been helping Simon write his first book. As far as we know, it's the first book on algorithms to use design patterns and TDD, but I could be wrong. Be sure to buy your mum one for christmas...:P

Having finally succumbed to the weight of my geek buddies buying Macs, I've just ordered a new Powerbook, so I reckon I'll be posting a bit about the experience. I've had to buy a copy of Virtual PC to ease the switch, but I'd like to retire all my Windows apps if I can.

A couple of views on coupling

2005-03-06T13:23:00.000-08:00

Having read both Domain Driven Design and Hibernate in Action recently, I found an interesting contradiction between them...here's what Eric Evans has to say about promiscuous coupling between your domain classes:

"It is important to constrain relationships as much as possible. A bidirectional association means that both objects can be understood only together. When application requirements do not call for traversal in both directions, adding a traversal direction reduces interdependence and simplifies the design. Understanding the domain may reveal a natural directional bias."

...and here's what Gavin King and Christian Bauer have to say on the same subject:

"Good uses for unidirectional one-to-many associations are uncommon in practice, and we don�t
have one in our auction application. You may remember that we started with the
Item and Bid mapping in chapter 3, making it first unidirectional, but we quickly
introduced the other side of the mapping."

So I agree with Eric, but I'm using Hibernate. Things that make you go hmmmm....

A new brain for Christmas

2005-01-08T04:06:00.000-08:00

Software isn't the kind of thing your mother buys you for Christmas, at least not in my family (I'm a first-generation geek). So to help with my new year's resolution of being more organised (those who know me might say anal retentive), I picked myself up a christmas present of a copy of Personal Brain.

A colleague showed me the brain a year or so ago, and I used it sporadically, finding it particularly useful when triaging ideas arriving rapidly and randomly, like in requirements gathering workshops. It works really well in this kind of environment, where a little bit of thought association goes a long way. But when I noticed that a new version had come out, I thought I'd get it and this time (gasp!) I actually read the manual. What a difference that makes, I must say. Now I know the hot keys to make navigation and construction easier, and I know how to make 'thoughts' refer to files, folders and web sites, I'll be darned if it isn't a fantastic way to organise your stuff. Within a day or so of mostly input, I started to get some benefit back in rapid access to whatever I was thinking about, and was surprised at how limiting and pervasive the whole hierarchical file structure we're trained in is and how much it affects my productivity.

The brain has a very simple model of parent, child and 'jump' connections between thoughts. You can have any number of each type of link (actually there is an arbitrary limit which is kind of weird, but it's enough for my purposes) and restructuring them is simple. That's really all there is to it, and like most great ideas, that's all there needs to be.

Here's a screenshot of my brain when I'm thinking about joodi. You'll see 'parent' thoughts above the central thought, 'child' thoughts below, 'jump' thoughts to the left and siblings to the right. The funky way the window reorganises itself when you move between thoughts is worth seeing, so go get it and have a play if you're interested.

Taste-Driven Development

2004-12-22T03:13:00.000-08:00

Having used Test-Driven Development for several years now, I am as convinced as I have ever been of its benefits in producing high quality maintainable code. One thing that bothers me, though, is that TDD itself provides no forces to ensure that the small pieces you build are assembled together into the higher-order structures you intended. For example, you can write a clean, concise fully tested set of classes such that your domain model is directly accessing your custom tags for your web app. Of course nobody interested enough in software to read this would ever do such a thing, but the point remains: with the promiscuous coupling encouraged by IDE's that will helpfully import any class from anywhere without requiring you to think whether this violates good taste in the form of layering, abstraction or anything else, we seem to be constantly having to fight against randomly coupled internal workings in good-sized systems.

So I find I'm constantly looking for ways to do what we do at the class level with TDD and do it at the package/component level; that is, allow the good taste desired in the design to be formally expressed and tested with every build. Developers who aren't up to speed yet on the complexities of the system they're working on would be protected from violating its conventions, and the emergent design can be allowed to flourish in a controlled way. On our current project we use a few things to help, such as simian, jdepend, ydoc, lots of checkstyle checks aimed at code quality and the usual test coverage stuff. But a few of us think that what the world really needs is yet another open source java development tool. Oh, no, you say, not another one. Yes, I'm afraid, it's another one. But this one is different - this one uses a business rule engine (drools) to allow you to declare in a text file your idea of good taste and enforce it for your code base. This one even has a user guide. No, seriously. So if design is your bag, have a look at joodi and let me know what you think. It only has a few rules in it at the moment, so it's not overly complicated.

Oh, by the way, if you think the java runtime itself would show good taste, check out what joodi has to say about rt.jar in the sample reports section of the user guide...you might be surprised!

Here's an example rule from the joodi rule file. This one expresses the simple good taste that cyclic package dependence is bad. It's kind of cryptic at first glance, but it basically says that if there exists a namespace (i.e. a java package) that depends on itself (dependence being part of the joodi fact model when your code is analysed), then create a notification including the cause of the problem so that the report provides full traceability for each notification produced. Using joodi is pretty much down to writing rules like this that express what good taste means to you and your project. Welcome to Taste-Driven Development!


<rule name="Cyclic Namespace Dependence Is Bad">
<parameter identifier="namespace">
<java:class>Namespace</java:class>
</parameter>
<java:condition>
namespace.dependsOnNamespace(namespace) != null
</java:condition>
<java:consequence>
drools.assertObject(new CyclicNamespaceUseNotification(namespace.dependsOnNamespace(namespace)));
</java:consequence>
</rule>

Agile Requirements

2004-12-10T04:35:00.000-08:00

I've been doing the odd dog-and-pony show presenting on the topic of agile development recently, which is always a good way to clarify your thoughts and force a few ideas to gel. What's been on my mind is the requirements gathering side of an agile project. Having just delivered a good sized agile project successfully, I'm convinced that the quality of our requirements gathering and the rigour and discipline of our scope management was one of the absolute keys.

Re-routing CVS repositories

2004-11-21T10:33:00.000-08:00

I'm putting this here to save myself the hassle of figuring out how to do it on the rare occasions I need to re-route a CVS sandbox to a different repository without releasing and checking out from the new repository. So if anyone else is wondering how to do it (you'll need cygwin on Windows), run this command from the top of your checkout tree:

find -name Root -exec sed -i.bak -e 's:/old/path:/new/path:' {} \;

. You will also need to be careful if you use a Windows CVS server like CVSNT, since using the ':' as the sed separator will require you to escape the colon in your repository path if you have one. By the way, this will make a backup of each Root file called Root.bak, just in case you don't trust it (and why should you...:P)

Star Wars on the (really) small screen

2004-11-18T17:00:00.000-08:00

I found another reason to dig my Pocket PC. My usual top reasons are talking books from audible.com and reading electronic books (in really big fonts!) with the Acrobat Reader for Pocket PC.

But having picked up a 1Gb SD card for next to nothing, I thought I'd investigate the supposedly forthcoming phenomenon of pocket movies. Microsoft has been making some noise about their new portable devices that play movies, but you don't need one of those. You just need a copy of this software and you're done. In about the time it takes to watch the film, it's converted to a 250Mb AVI at 320x240 resolution. That's 15 frames per second at a resolution that's higher than your TV, so it's pretty darn watchable. There is a slight weirdness to the screen when rotated to watch in landscape mode, probably because the RGB subpixels on the LCD or up/down aligned in this mode, but you get used to it.

So having recently picked up the Star Wars box set to relive my childhood like all the other 30-something males on the planet, but not having time to scratch myself like all the other 30-something males on the planet, I can now squeeze this necessary pastime into my morning commute and leave all the iPod weenies wondering why exactly they think they're so cool. Rock on.

Why I Hate Domain-Driven Design

2004-11-18T10:39:00.000-08:00

I was feeling pretty good about myself I have to admit. Having just delivered a system that took a year of a dozen developer's lives to complete with the full XP experience working like a treat, on time, on budget, happy customer, etc, etc, I thought I'd finally get my life back and start catching up on all the reading I don't do when it's head down, bum up on a project. High on my list was Domain-Driven Design by Eric Evans, as it had been highly recommended by people I respect a lot. So now I'm depressed. It is such a fine book, no, it's a truly mind-expanding, insightful, gee-now-I-feel-stupid kind of book that I now just want to go back and do the whole damn project again. And this time I'd do it properly. Dammit.

If you'd like to share the joy, as usual my recommendation is to get it on the cheap at Safari

Power Pointers

2004-10-07T12:07:00.000-07:00

I often get asked how I go about doing a technical presentation, so I thought I'd put down a few pointers for those who would like to do some presenting but think it's all a bit intimidating.

Have something you want to say. This is generally not a problem for most serious geeks, although it's surprisingly common to find many who have incredible experience and insight but think nobody is interested in what they might say. That is almost never the case, either, since all of us are sponges for good stuff of all kinds.
Care about your audience. It's important to really want to connect with the audience and make them feel important. Even in a stand and deliver situation, I often survey the audience to get a feel for their likes, dislikes and interests. This can help you focus on what they need and want over what you thought they might like.
Don't start in PowerPoint. I never, ever begin my presentations by opening PowerPoint and looking at a blank slide. I always open a Word document instead and switch to Outline View. Then I just start brainstorming, imagining I'm having a one-on-one conversation with someone, explaining the topic at hand. No structure is present yet. It's all about noting down all the things you might want to say first. Then it's a matter of learning to use the outline view's features of indenting, outdenting, dragging and dropping to apply some structure to the thoughts. This is very much like the test, code, refactor cycle in development of code. The test is that you can explain the idea. The code is recording the points you need to do that. The refactoring is cleaning up the structure. And just like coding, it works really well if you treat these as distinct tasks and switch between them cleanly.
Generate the slideshow from the outline. Once you're done in Word, just hit File->Sent to->PowerPoint and voila! All your top level headings become slides, and the subpoints become bullet points underneath them. You can then click Format->Apply Design Template, go looking for a pre-canned slideshow and bingo! your show is just about done without a single tedious minute in PowerPoint itself. If you have time, add some pictures and animation, but remember they're the icing, not the cake.
Less is More. I much prefer slides with fewer words on them. I do not consider a slide to be of any value without me in front of it to turn it into the presentation experience. Resist the temptation to turn a slideshow into a whitepaper. It's just there to remind you what you wanted to say and help the audience to follow; it's not there to say it for you!
Remember that nobody finds it easy. Public speaking is daunting for everyone, and I do mean everyone. I sweat bullets for days before an important presentation, but once it starts it's almost like it's someone else doing it, not me, and in a way it's easy. If you're serious, look into Toastmasters for some training (I did it 20 years ago and am still grateful) or try your hand at a low-risk venue like a user group or other friendly and supportive environment.
Have fun!

Smell the Tests!

2004-09-15T11:54:00.000-07:00

When you are faced with a team that's new to agile development, it's common to spend a lot of time driving home the need to test everything. Along with refactoring, test-driven (or at least test-conscious) development is the most basic skill the aspiring extreme programmer must acquire. We strive to testability in design and the cheapest, most effective quality we can get. So is there such a thing as bad testing? Can tests hinder more than help? Can tests just be a downright pain in the rear?

The answer is a resounding YES! YES! YES!

Just because you code in an object-oriented language does not guarantee that what you write will contain any object-oriented characteristics whatsoever. Similarly, just because you write JUnit test cases does not guarantee that what you produce will display any of the qualities of an effective and adaptable test suite. Naive application of testing frameworks has the same potential for developers to exercise their bad judgement and bad taste as any other technology. Now while I'd certainly rather have a project with lots of less than ideal tests than no tests at all, we need to learn to 'smell the tests' to really get the most out of our (and our customers') investment in testing.

So here are some of the smells that tests can emit. I'm sure you can think of more, so please drop me a line so I can share your pain...:P

No statement of intent. If I have a Widget with a getPrice() method, I often see a testGetPrice() test method, and my first thought is "test getPrice() does what?". Prefer names for tests that express the intention of the test, such as testGetPriceReturnsZeroWhenNotInitialisedExplicitly(). There are tools that can turn your test names into human readable documentation, so don't be afraid of full-length sentences as test method names.
Irrelevant assertions. It is common (particularly in functional tests) for a test that is concerned with proving a small incremental behaviour to make irrelevant assertions about all sorts of other fields, even on other screens. Prefer semantic generalisations over value-specific assertions. For example, if your test is not concerned with the actual price algorithm, don't assertEquals("46.12", widget.getPrice()) when you can say assertNonZeroMonetaryValue(widget.getPrice()) - even though it's a bit more work at first.
Setup leakage. It is extremely common for developers new to testing to not easily be able to distinguish the concerns of their test from the setup steps required to get them to the point where their test can begin. The newly test-infected developer can thus create maintenance burdens and simply waste time reinventing the testing wheel with every test case. Strive for a clear separation between setup and test, and look for reuse in the setup code via fixtures and scenarios.
Overtesting. Many developers find it difficult to focus only on what is relevant to the test at hand. It is not only more efficient to assume the rest of the system works when writing a new test, but it also improves maintainability as each test is more isolated and targeted. It is common for developers to turn themselves into knots to get controlled input and output moving between different components when a mock would be faster and more effective. Leave it to the other tests to do their job and assume away responsibilities that are not yours right now for the code under test.
Multi-layer tests. Unit tests should rearely (if ever) traverse multiple layers in your design. A sure sign that they do is when they run slowly. Unit tests should run in the thousands per minute kind of rate, while functional tests tend to be in the 30-50 per minute range, so prefer unit tests to achieve coverage and functional tests to prove wiring of configured components.
In-container unit tests. T'ain't no such thang. Don't make sense. If you think you have some, that's a smell. :)
Fractured functional tests. Adding functionality a small bit at a time leads to functional tests with a lot of overlap and there is no force to encourage the consolidation of these tests other than slow build speed. I'm not sure how to fix this one other than slow slog refactoring. We have a lot of this joy ahead on our current project!

None of this alters my belief that test-driven development is the best method I know for building quality software. But it does mean that (once again) we need to be careful about silver bullet syndrome when it comes to testing.

Have Hair Dryer, Will Boot

2004-08-08T10:47:00.000-07:00

Having moved house recently, I was dismayed when one of my PC's (the one that's built for music and video editing) refused to boot. The primary hard disk was not being recognised by the BIOS. Dammit. Now yes, I have all the important data backed up, but it's pretty tough to backup full quality video footage at the best of times, and this box has had years of tweaking put into it, so rebuilding it from scratch was a rather sphincter-puckering concept. Having a couple of weeks paternity leave to sort it out, I started ringing around the pro data rescue market, and the prices were all in the $2,000 range. Hell, I could just buy a whole new box for that.

So being a software guy, I rang my buddy the hardware guy and told him my story, of how the box had been running happily for 18 months without being turned off, then it was shut down for a couple of weeks during the house move/new baby transition. "Ah-hah", says he, "just get out the hairdryer and heat that drive up for 20 minutes; it'll boot first go". And bugger me if he wasn't right on the money! A quick plug in of a new drive onto which I ghost-ed the dying one, switcheroo and off we go.

Phew!

Who gives a toss about software anyway?

2004-07-26T00:45:00.000-07:00

I mean, really, I'm as guilty as the next geekblogger of making software and its myriad cultural spawn the centre of the universe, but when you hold your new baby girl in your arms it really does seem all a little silly. So here's to the arrival of Ella Rose....and yes, I did buy her a domain name before she was born!

IntelliJ as.....Writing Tool!

2004-06-28T15:33:00.000-07:00

Trying to collaborate on some technical writing with Simon Harris led us to figure out a way to get the type of collaboration we are used to while coding when we're writing. this means having the content in a textual format so it can be merged, ruling out MS Word and other binary formats. We've been using a wiki a lot for this recently, but reading Martin Fowler's post about writing using XML made us want to give it a try. Now before you say DocBook, let me just say that that's just a little tooooo heavyweight for our needs. But the idea is right. So we knocked up a little DTD that incorporates a hierarchy of sections, with figures, code listing, cross references, external references, etc, and then used IntelliJ IDEA's DTD-driven XML editing to start writing the content. With the code folding and a few live templates, we pretty quickly had a nice intuitive editing experience that allows the separation of the creation of the content from the marking up thereof. With the addition of a little XSLT that automatically numbers the nested sections, voila! IntelliJ as author's workbench! Cool!

When Prevention's Not Better Than Cure

2004-06-10T16:04:00.000-07:00

When doing agile software development, our main challenge is having little enough process to go fast, but enough process to avoid crashing. The desire to go fast is all well and good, but we don't want to have our only feedback mechanism on whether we're going *too* fast to be blunt force trauma.

I have no doubt that application of agile methods such as XP without equal application of both the freedoms and the responsibilities they afford will end in tears. This is often the biggest challenge with developers new to XP. They love the freedom to refactor and design on the fly, but their enthusiasm sometimes wanes when confronted with the discipline of maintaining test coverage under schedule pressure.

So how do we know when we're going too fast? One problem with perceiving the team's speed (as opposed to velocity :P) is that different members of the team will have different comfort levels with the shared rate of progress. Several times recently I've found myself responding to feedback from team members that would like a little more process to avoid some issue or another, be it screen rework or the presence of defects during QA. I try to be careful to get enough feedback to find out if what we have is just turbulence or the swelling sound of a wing shearing off the fuselage. Most times it's the former, and in these cases I find there's a recurring theme to my response: prevention isn't always better than cure.

For example, in our current system we have 500+ story cards. If about 10% of these result in a defect (which looks about right at the moment) and each of these cost a day for a pair to fix (no metrics but I think that's more than the reality), that's 50x2 days of rework. If we were to put in place a process to prevent all these defects, it would probably cost the team at least two hours per story (that's only two people talking for an hour) to do the extra analysis and testing for EVERY story card. That's 1,000 hours extra work, or comfortably more than the 100 days of rework we have to do to cover off the defects. That's also on the unrealistic assumption that you do actually prevent all the defects! It's just a numbers game in which you win if the quality is sufficient that the amount of rework on the defects is less than the amount of effort to prevent all those defects plus the extra effort you put in to the majority of cards that would never have had defects in the first place.

So I find I'm spending a bit of time reassuring the passengers that a little turbulence is normal, and preventing it is not only unnecessary, it's counter-productive. At the same time I try to maintain a healthy paranoia about the process. Of course, the danger lies in not being able to tell turbulence from a tailspin, so if anyone has ideas on how to do this, bring it on!

Conversation Is Not Understanding Either!

2004-05-13T15:47:00.000-07:00

I have been as guilty as the next geek of rationalising my distaste at the tedium of documentation. Many of my agile friends and colleagues are fond of saying that 'Documentation is Not Understanding' when promoting the 'people over process' bit of the Agile Manifesto. Now while I do indeed hold this truth to be self-evident, a few recent experiences find me not so dismissive of the value of documentation as once I was.

Circumstances led me to leave my role in a nice fun agile project for a few months. When I returned, I struggled to get back up to speed for a couple of weeks - these agile folks will just go and change things while you're not looking :) When trying to reconstruct my mental model of the project, I found the pieces I had to put together out of conversations with analysts, customers and developers didn't always fit together snugly, and I found myself needing some sort of point of reference that was indeed shared understanding to work forward from. Anyway, I haven't really worked out what this means, but I have to conclude that while documentation is not understanding, neither is conversation. Another assumption bites the dust!

The Need for Speed

2004-04-12T14:42:00.000-07:00

At the Melbourne eXtreme Programming Enthusiasts Group the other night we had a big rantorama about TDD. One of the points in my presentation was that Kent had said that unit tests had to be fast, and he cited one project in which there were 4,000 tests that ran in about 20 minutes. A few guys from my team were there and guffawed out loud. Our current project (4 months old) has 1,300 unit tests that run in about 10 seconds, so they weren't impressed with Kent's numbers at all. Even allowing for Moore's law over a few years, we'd run about 4,000 tests in 30 seconds, which two speed-doublings ago would take 2 minutes. That's still an order of magnitude faster...so what's the deal?

This led to lots of enthusiastic debate about what the hell a unit test actually is. For what it's worth, here's my simplistic test categorization model:

1. A unit test is a test that requires only the class under test and its immediate dependencies (or mocks thereof). This means no deployment, no packaging, nothing. That's why they're fast.

2. A functional test is a test you can't run until the app is packaged and deployed in some way. So you "in-container unit test" fans aren't doing unit tests by this model. I'm hard on this stuff because anything requiring deployment puts you in a different order of magnitude speed wise; this doesn't mean these tests aren't valuable, just that I don't count them as _unit_ tests, even if they only test a single unit of functionality.

3. An integration test is a test of your external dependencies, not necessarily requiring your app to be deployed at all, but requiring your external dependencies to be available. This is where databases come in, or other services provided by EJB's or anything else. These tests are also usually way too slow for me to want too many of them, and I want to isolate them from my app as much as possible. This means a separate test harness for the external stuff and leave my app just unit testing against the assumptions proven by the integration test suite.

The point is that I want to push unit tests as far as I can because they just provide so much more performance than the other types of tests. That's the only reason. I want as few of the others as possible because I spend enough of my life waiting for computers to get done with stuff as it is. Yes, you _can_ unit test custom tags to within an inch of 100% coverage!

So what's everyone else getting speed-wise???

Become what you despise

2004-03-20T10:44:00.000-08:00

A lot of agile/TDD/XP folks like me enjoy flouting a very public disdain for "whiteboard architects" and their ilk. These are the ones who haven't written a line of code in ten years or more, serve out voluntary life sentences in financial institutions and impose design decisions from on high while ignoring development teams entirely. They never ask for feedback on their architecture from anyone who sits beneath them on the org chart, as what feedback of value could a lowly code-cutter have? They are far too busy seeking feedback from those _above_ them on the org chart to make sure their career ambitions are on track, and that's a full time job.

So how happy was I when Jon broke his arm and I was pulled off my nice little agile dev lead role and into a six week whiteboard wonderland? Hmmm. In a nutshell, this gig involves designing a technical solution to coordinate half a dozen systems on four different platforms written in four different languages, integrating .NET with J2EE, a rules engine, messaging systems, mainframe yuk galore, blah, blah, snore. The system will be used by thousands of people every day and carry billions of dollars of business every year Textbook whitebook architect turf. Oh, and you've got three weeks to get your head around it and come up with a solution and another couple of weeks to write it up and get it approved by the Big Guys Upstairs. No coding for you! Well, it's been an interesting and enlightening experience - always a good thing. I hope I haven't become what I despise, but perhaps I despise them a little less by understanding them a little more.

Lesson: Same shit, different abstraction

So why is it that we who prefer to spend our time at the implementation coalface smirk at the whiteboard architects? I have noticed during this brief out-of-body experience that one reason is the same as why we smirk at some of our less-than-breathtaking code-cutting colleagues. They can't design to save themselves. Just as many developers solve the wrong problem and can't distinguish between an implementation abstraction and a design abstraction (Dude, don't call it a SQLDataSource if it's role is a DomainStore!), it seems the same mistakes happen at the higher level of abstraction where enterprise architects play. Some of them seem compelled to define the implementations of the solution to the problem instead of just defining the problem, assigning responsibilities to well-nhamed abstractions (SOA, anyone?) and admitting that in the time available they don't have a hope in hell of telling a development team how they should actually build the thing. I can forgive them their transgressions against developers because it's not just them. We do it too. And so do business people. How often have you been given a so called 'requirement' that is not a statement of a problem at all but a statement of a dumbass solution? It has surprised me how well design concepts I'm used to using at the class/interface/component level map to the system/service level.

On this gig I've met one particularly outstanding guy who's an enterprise architect on a parallel project, and I just know he would be a kickass code cutter as well; he must just prefer to get paid properly. So take heart, you too might get lucky and find a whiteboard architect whose pictures deserve to make it off the drawing board!

Getting into the Swing of TDD

2004-03-07T12:54:00.000-08:00

Just came off a tough late night/early morning pairing session with Simon Harris. We're working on a Swing app that will let you wander around the duplication in your code base by reading a Simian log file and referring to the original code tree. We're also trying an experiment where we use TDD and blog the experience so that we can publish the gory details of the construction of the app, on the presumption that anyone cares, of course...:P

Last night's session will make for interesting reading, mainly because we're both pretty clueless about Swing. In keeping with Jon Eaves ideas on spiking and TDD, we mucked around for a while trying to figure out how to use the java.awt.Robot to drive our panels, but we got there in the end. What we are trying to explore is how far we can push TDD, and I, for one, am so sick of web apps that this seemed like a cool idea.

I don't know enough about Swing to understand why a lot of folks seem to hate it these days, but it's always appealed to me as having the potential to facilitate real unit testing. By this I mean that a UI area composed of multiple JPanels should be able to have independently designed and tested each of those panels before assembling the UI and running functional tests over it.

The theory goes something like this:

you don't have to write tests for one line delegation methods in my book. So if the UI was a veneer so thin over a fully tested set of non-Swing stuff, I'm happy to just glue the UI onto the layer below with trivial delegation. This is the interesting part - how thin can the UI layer be? So thin that no testing is required?
you use a Mediator to coordinate the interaction between panels (which you of course make an interface so you can easymock it for testing), and each panel implements a Colleague interface (again facilitates testing). This means that although there is 2-way comms between the mediator and the colleagues, either end of this pipe can be mocked, allowing testing of each bit independently.
you then assemble your UI like any other swing UI and the bits play nice.

We had previously gotten our mediator TDD-ed into existence and were happy with it. We then came to creating the JPanel that contains a list of files that share some duplicated code. This panel was also TDD-ed into existence but with all its behaviour in non-Swing methods. All good. Then it came time to (we thought) just add the JList and off we go. Turns out the amount of code required, with event listeners and a private inner ListModel class left us facing the dreaded NullPointerException at run time. If there is a more glaring signal that your code is crap, I don't know it.

So we came to the conclusion that we would have to actually unit test the UI with events somehow, you know, mouse and keyboard stuff. Yuk. We mucked around for a while trying to figure out how to do this while keeping the test 'headless', but failed dismally. In the end we came to grips with the pixel coordinate stuff required by Robot and plonked our little panel into a JFrame of its own in the unit test and just displayed it and started the Robot clicking on stuff.

So the upshot was that a single panel pops up on the screen and dances about a bit being unit tested against a mock Mediator that catches and verifies the panel's interactions with the rest of the dialog that isn't even there yet. Long story, I know, but I thought it was kinda fun and my blog's been a bit quiet lately.

Just what the world needs

2004-02-11T03:56:00.000-08:00

Just what the world needs - another ThoughtWorker bleating on about test-driven development. Sheesh!