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!
Monday, January 19, 2009
First post on Blogger
I'm moving my blog over to Blogger, so if you're reading this, it means you've found the new location. Well done :)
Wednesday, September 24, 2008
Nostradufus
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!
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!
Sunday, October 8, 2006
The Truth or a Comforting Lie?
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.
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.
Saturday, May 27, 2006
Speed Read With Your Eyes Shut
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.
* 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.
Tuesday, April 25, 2006
Joining the Rails fashion set
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!
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!
Sunday, April 16, 2006
The 'Things That S**t Me' List
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
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
Thursday, March 23, 2006
A Revised National Anthem for Australia
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:
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....
"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....
Subscribe to:
Comments (Atom)