Is a Singapore Sling at Raffles a cliché?

Singapore Sling at Raffles

I used to consider myself a travel snob. Certainly not a tourist and even back-backing was beneath me. I went for the authentic experience; small holdall with only the bare necessities, travelling and staying with the locals, keeping off the beaten track. So when I was in Singapore recently the question of whether to go to Raffles for a Singapore Sling agonised me. My old self would have shuddered at the idea. What a tourist cliché! I’d find a smoky café in the Arab area and drink thick coffee and puff on a hookah. What is worse, I’d preach against any way but my way- if you’d been to Singapore and stayed at Raffles you hadn’t really been to Singapore. Unless you’d eaten from street stalls and slept under a fan you were just a (spit) tourist.

But I’m in Singapore on business and I’m older and wiser and I hit the Long Bar in Raffles and like almost everyone else, I do the tourist thing and order the Sling. And the experience was appropriate to my circumstances.

Sometimes I wonder if this snobbery rears its head in my professional world. We choose Firefox over IE, Ubuntu over Vista, agile over waterfall. Ruby on Rails is our passion, anything else is just beneath us. Commercial success is to be looked down upon; “selling out.” Bob Dylan sold out when he went electric, right! There’s a thin line between passion, pragmatism and snobbery. The thing is to know the set, setting and circumstances. Who are you working with, what’s the context and why are you there. Keep those questions in mind and the appropriate level of snobbery you may revel in should become clear.

Software Dams and recipient participation

There once was a time that international development was all about big capital projects, building dams and the likes. Times change, now the focus is on eliminating poverty; DFID “focus [their] aid on the poorest countries and those most in need”. There is a realisation that those big projects did very little to address poverty, indeed they kept countries poor forcing them into debt (read Confessions of an Economic Hit Man for a cynical view of this). And besides, dam projects are rarely successful and before you know it they silt up.

A focus on reducing poverty requires a new approach. It requires an understanding of the root problems, it means spending time with the poor to understand their circumstances to be able to create appropriate and sustainable solutions rather than prescribed programmes that develop and maintain a dependency culture.

There are parallels here with the IT industry. Much of the IT game remains focussed upon those big projects. Software dams that can be launched with great fanfare but do little sustainable good to those most in need. The customer.

Before I wound up in IT I worked in international development. My PhD. “Ergonomics tool and methods for use in Industrially Developing Countries” was based on working with farmers in Sub Saharan Africa, looking at how technology is transferred and how it can be made more appropriate, sustainable and usable. Many of the tools and techniques I used in the bush I apply with the corporations I work with today. These came under the umbrella of “Participatory Technology Development” and “Participatory Rural Appraisal”.

Rather than the delivering the white elephants of expensive machinery that you see littered around Africa, Participatory Technology Development is an approach for developing simple low cost innovative solutions that have the ownership of the community who work with researchers to build them. The PTD framework starts with gaining a shared understanding problems and opportunities. This is followed by defining priority problems then experimentation. Experimentation is collaborative with options derived from indigenous knowledge and support from the researchers experience and expertise. The farmers own the experiments and the results. This leads to the next step of the framework; sharing the results with farmer led extension. (Traditionally dissemination of agricultural advice is done by agricultural extension officers – government employees who despite their best intentions preach too the farmers, sharing centrally defined agricultural advice rather than the more appropriate, locally developed technologies that the farming community have developed themselves). The final step to the process is the researchers withdrawing, leaving the community with the capacity to continue the process of change.

(Sounding like agile?)

If PTD is a framework, then PRA is a basket of tools and techniques that can be used to support it. These can be broken down into nine categories:

  • Secondary data reviews – reviewing existing sources of information
  • Workshops – getting key stakeholders round the table (or more appropriately under the banyan tree)
  • Semi-structured interviewing – talking to people with a loose conversation direction
  • Ranking and classification techniques – identifying “things” and ordering them according to different criteria. (Often this will involve moving pebbles around boxes drawn in the sand).
  • Diagramming, illustrations and graphics – pictures to convey ideas and concepts, through “boxes and arrows”, Venn diagrams and charting to cartoons and imagery
  • Mapping – drawings or models that represent the local environment
  • Structured observation – watching people doing
  • Timelines – What happens when, for example seasonal calendars, a line in the sand and people put pebbles down against the time to show when crops are sown, harvested, how the price fluctuates, labour migration etc.
  • Community meetings – meeting the whole community rather than just the immediate stakeholders who participate in stakeholders. Showcases?

Are you building a Software Dam? Or are you focussing your aid on those most in need? PTD and PRA are approaches that have developed to help introduce appropriate, sustainable improvements to the life and wellbeing of subsistence farmers. Much of their content can be transferred to IT projects, helping introduce appropriate, sustainable improvements to the life and wellbeing of customers / users.

The invisible lift

Lift button and fllor indicator with no door

The story goes that when the building was built, the organisation taking the top floor demanded their own lift that would not stop at any other floor. They got their wish. Entrances to the lift shaft were blocked off on every floor except the ground and top floor. End of story? Not quite. The floor indicator and call buttons were installed on every floor.

Do you build invisible lift openings when you build software? Install buttons and indicators in the anticipation that they might one day be needed. (Ignoring the fact these are mere details hiding the bigger picture… doors for example). This is a good example of YAGNI, you ain’t gonna need it. You don’t need a lift floor indicator and call button until you’ve got an opening to the shaft and doors. And when you need those lift technology will probably have moved on and the buttons and indicators will be all but obsolete.

Reflections on QCon

Qcon is a “Conference for the Enterprise Software Development Community;” a pretty hardcore techie bunch then. So it was really refreshing to see a whole days track given over to usability and a keynote by Larry Constantine on “Meeting the Usability Challenge”. Last night Martin Fowler and Dan North gave an excellent keynote titled “The Yawning Crevasse of Doom”. Their central theme was around communication between the customer / end user / consumer / business and the developers / IT. Martin drew a great analogy; do you want your communication between the two “sides” to be like a ferry boat or a bridge. Part of the bridge that Martin and Dan talked about was the use of ethnographic research – observing users in their natural environments and storyboards / wireframes / lo-fi prototypes to visually articulate requirements in a way that written requirements can never do. i.e. championing the stuff that I am passionate about, and what we at ThoughtWorks do deliver successful projects.

A couple of other nuggets that are worth sharing; Jeff Sutherland talked about how at Google they don’t have performance appraisals. Instead everyone has personal “three month objectives” that are posted on their blogs (the first thing that a new recruit at Google does apparently is creates a personal web page). In this way people can share with the broader organisation what they are doing. With google search experts and their knowledge can easily be found. Advertising to the organisation what your goals drives performance far more effectively than a sterile quarterly form distributed by HR…

Jim Webber gave an excellent and entertaining presentation on Geurilla SOA. If you get a chance to see him in full opinionated flow, you should seize it. (And I don’t just say that because of his kind words about my presentation, that I’ll upload soon).

At the conference one of the vendors was JavaBlackBelt. They had a multiple choice test on your knowledge of Java. Some of my esteemed colleagues did not fair so well on it; my programming knowledge goes little beyond

10 print “hello world”
20 goto 10

So I am very proud to announce that I came top of the JavaBlackBelt class and won a t-shirt, scoring 3/5 in a little over 40 seconds, a cool 2 minutes faster than the second placed geek. Don’t you just love multiple choice.

Top of class java black belt programmer

Architect your solution around the customer experience

I was at QCon yesterday, ostensibly to give a presentation on usability, but I attended a few sessions as well.  Not being a techie, I didn’t understand much of what Werner Vogels, the CTO of Amazon was talking about during his presentation on Availability and Consistency, but one thing has stuck in my mind.  “Never, never refuse the customer from putting stuff in the shopping cart”.  The context of this was around how your architectural design; do you go for consistency or availability (or something else which I can’t remember).

I’ve blogged before about siloed organisations, but Werner touched on how even internal IT organisations can be siloed.  Something about how your database team may be soley focussed upon consistency; they are willing to sacrifice availability for valid technical reasons.  But the database needs to be seen in the bigger picture, outside the confines of the IT organisation.  It needs to support the customer experience.  And that means the customer must always be able to put items in the shopping cart.  Period.  The takeaway I suppose is to build your architecture around the customer experience; decompose the experience to do this.  The technical requirements for your shopping cart will be different from your fulfilment mechanism from your “see what others are buying” from your “my details”.  Make technical decisions accordingly, rather than a one-size fits all.

It gets worse…

The other day I wrote about how Surrey County Council had a “problem with their systems” and couldn’t tell us what school our daughter has a place in. We were supposed to be informed last Wednesday. They’d promised to “send the letters out” on Friday, today. Being impatient I rang them up; now the letters have been printed surely the relevent data would be available to give out on the phone to impatient parents.

Well yes and no.

Yes we should be able to give you the information I was told, but sorry we can’t. “Our database has crashed!”

I’m incredulous.

“It’s the EMS” I was told, “I can’t even log in to it. Today of all days”.

Is this Capita’s Extended Management System? Capita, the company whose chairman gave a £1m loan to the labour party? Suddenly, (much to my shock and surprise) the Tories are becoming ever more attractive. Partciularly with the Shadow Chancellor standing up and demanding a greater use of Open Source. As a tax payer this is great news! And as employee of a great company that champions Open Source even better!

I’m exercising my democratic rights next week and talking to my (Tory) MP about the farcical IT “solution” that is operating in his constituency, and will back up what his parties money man is saying.  And maybe my voting intentions may be swinging.

It’s not good enough to blame the computer. Blame the lack of tests

It’s education lottery time. Parents are receiving letters bearing good or bad news from schools telling them if their little lovelies have got places in their chosen schools or not. Choice being the big thing – although there isn’t really such a thing as choice, it’s more a preference. Parents have have three choices, ranked one two or three. Good schools have strict admission criteria, and will usually only accept “first choice” children. Don’t get your child into your first choice school and you are at the mercy of the local education authority – no good school will accept parents who rate their schools as second or third choices. It’s not an ideal system, but at least all the letters go out on the same day so you get to know where your child has been allocated a place.

Sadly we fall into the unfortunate category of parents whose first choice has not been honoured. Our first choice school has rejected us on the grounds of distance from the school. Their classroom quota has been reached and we didn’t fill it. That is not good for us! So will we be exceptionally lucky and our daughter get a place in our second or even third preferred schools? We don’t know. And Surrey Country Council can’t tell us.

We’ve got a week of anxious waiting before they send their letters out. They’ve got a problem with their “systems.” Well that is the message I get told when I rang them up. “We can’t tell you anything more because we don’t even know” I was told.
Frankly it is not good enough to blame the computer. If something so critical happens in the private sector, SLAs dictate a course of action; this is a severity one problem that will be fixed within hours. Not weeks. But this is good enough in the public sector where faceless bureaucrats can hide behind the computer, cosy outsourcing deals with little accountability mean that no-one really needs to take responsibility. Take responsibility for the pain and distress this is causing me and my family!
So I got their press office number from the website and rang the Head of Communications. She knew nothing of any problems with letters going out, but promised to have someone call me back to let me know what the problem was.

A little while later I got a call back and was told that there was indeed a problem with the computer, specifically in resolving offers, and in particular resolving offers where children have other siblings already in the school. I was also told that they’d earlier had problems in importing data into their systems.

Now the deadline for getting completed applications in is the end of October. That was four months ago. Four months to scan several thousand forms and process the data, and get it right. That is not such a hard task is it? OK, so the process changed for this round of admissions so changes would have been required to the systems, but even more reason to make sure you get it right. It begs the question, was there a test strategy in place? Did anybody do any testing? I believe that the system has been outsourced to Capita. Has anybody at Capita heard of test driven development? It strikes me that this sort of project is ripe for an agile approach to delivery; a business critical system that cannot fail, simple business rules… I wonder if my MP is going to listen to this story…

Productvity, creativity, lean and a blockbuster movie

When it tries to reinvent itself, software development takes paradigms from other industries; in many respects traditional waterfall approaches are analogous to the construction industry, and more recently software development is looking to the manufacturing industry with “lean” being in favour. The benefits of lean in the car industry are self evident, look at the daddy of lean, Toyota. Just-in-time is firmly embedded in the manufacturing lexicography and one of its by-products, six-sigma, has overtaken quality and the TQM movement in many areas.

Software is still in the dark-ages of scientific management, it is more Henry Ford’s production line than Toyota’s production system.

When you do a “Value Stream Map” of Waterfall software development, (a lean methodology that essentially takes each step in the process and asks “how long does that take?”) it is evident that Waterfall is an inefficient process with significant bottle necks at every step of the process. Applying agile / lean techniques aims to overcome these bottlenecks and eliminate “waste” in the process can only be a good thing in an industry that is rife with bloat and failiures. All well and good, but I wonder if we need to take the whole lean manufacturing thing as the ideal paradigm for software development. After all, a software product is not a mass produced car, isn’t it is more a work of art. Something creative…

…you should be thinking about the tectonic shift from productivity to creativity – how shifting from work to play is the source of real, durable, economic gains in the post-network economy.

Shift from productivity to creativity. I like this. I wonder that if we focus solely on productivity and turn software delivery into an ultra-efficient production line, where stories (requirements) are little more than inventory, we risk loosing any creativity in the process. Maybe there is another paradigm we can learn from, that of the film industry. Afterall, building a piece of software in many respects is more like creating a film than building a car…

For a start, it is generally a one-off, it is not a production line.

The team who work on the film are brought together based upon their expertise, they are a project team, rather than a production line business a usual work unit.

There is no architecture, rather a script (overarching story) that is visualised in storyboards.

Filming is not linear, it is done in iterations; film all the scenes on a particular location, regardless of the order they fit in the film.

Filming needs to be responsive to change within the boundaries of the overarching vision (business objective); often decisions are made on location; the director sees a particular shot that was not storyboarded and changes are made there and then.

At the end of each iteration you have the rushes (showcase).

Before being launched the film is previewed (usability tested) and depending upon the audience reaction changes may be made.

And then the film is released to critical acclaim. (Or maybe not…)

I’m not suggesting this is a better paradigm than lean – indeed read the wikipedia entry on film making:

An entire big Hollywood-style production cycle typically takes three years. The first year is taken up with development. The second year comprises pre-production and production and the third year comprises post-production and distribution.

…and that sounds distinctly like waterfall.

There is much the software industry can learn from Lean; it’s not an either/ or, rather that I’m sure there are plenty of lessons that can be learned from the film industry. Let’s not loose creativity in our drive to productivity and efficiency.

When do you need to design a UI?

Via Ian Cartwright  an interview with “Lean software gurus” Mary and Tom Poppendieck.  All is going well until  Mary says this:

When do you really need to design a user interface? Oftentimes it drives the whole design, but in fact you don’t really need it until you’re about to do your first alpha test. Before that you can be designing the business layer and you can actually put testing in below the user interface and you can be designing all of the other business logic; you can get that done with any kind of interface and in fact you ca drive testing with a automated interface, and then just before you go to alpha testing you decide what you want for your user interface. Then you take it off and at that point in time you figure it out. But up until that point in time you don’t need that.

This jars with my experience of building compelling customer experiences. There is a good reason why the user interface should drive the whole design because that is how the software is manifest.  To the people whose lives are to be touched by the software, the users, the consumers, the interface is the software.  To leave the UI till last presents a  huge risk of building software that is functionally rich but has a UI modelled around the features; the underlying data and logic rather than how the user wants to work.

Starting with the UI is an excellent way of capturing and communicating requirements.  And bakes in usability into the design.  You want this feature and that feature?  Great.  But will they be coherent and usable to the user?  Drawing out a UI  on paper – paper prototyping- is far more efficient that making assumptions about requirements on a list.  Afterall, isn’t this what the manufacturing industry that the Poppendiecks take thier inspiration from?  Don’t the car manufacturers start with CAD and move onto clay models?  Ergonomists have a hand in the design of car interiors, using anthropometrics to build in comfort and work out lines of sight.  The engineers don’t build the engine and the bodywork and then make decisions about how the car will look.  These things are designed from the start.  And so should it be with software.

When do you really need to design a user interface? It should be the first thing that you do.

6 of 10