aussie coder . com

A funny topic came up today at work that I thought I’d share.

We’ve been working on a project for the better part of the year and been really optimistic with it, even though there’s been false starts on it previously, and the users have only been interested in it from the point of view of “it’d be nice to have but it’s creating work for me”.

We’ve gotten it deployed to a couple of users for testing and they’ve been slow to get interested in actually doing that, but we went ahead with one today and it’s making us second guess a decision.

We have certain events that something can perform on a product, such as adding elements – now we decided from the start that we were going with an optimistic view, so that you could only add events to the queue.

So, lets say we create a product, and then we do an addition to it – but we accidentally add to the wrong product – what would you do?  Well, we made it so that you could adjust that product, so that you could take it back to the original state.

But in the history of that product it would record that, and we can report on the adjustments made.

The first time the user struck that, day 1 of testing, and he was horrified – he didn’t want to adjust and took that as the wrong way to progress – because his adjustment would be seen by one of the bean-counters in accounting and that would be seen as a very negative thing to him.

So we’re back to the drawing board on having to redo all our objects, or rather the events, to undo and wind back changes – which means a minor re-architecture.

And this guy was in all the architecture meetings, made the decisions with the others, and we had discussed the way things were going to be adjusted.

I don’t know what we take away from this, but I still think we went down the right path because we ended up with a fairly beautiful and efficient user story, for the interface and the processes – we were just a tad too optimistic about what they would accept on the perception of when things went the wrong way!