Learning, helping and making a little money

"We need to make our software development economically more valuable by spending money more slowly, earning revenue more quickly, and increasing the probable productive lifespan of our project. But most of all, we need to increase the options for business decisions." K. Beck. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.

It seems to me that the economics of investment in IT continues to drift more and more towards the general principle of "Earn early, spend late" -- many short releases, delivering highest value features earliest, traversing the value gradient until further feature delivery offers no further return.

There are many economic benefits to this approach: early value delivered to the market can generate revenue sooner; spending less up front to achieve a business outcome is desirable; and prioritizing features against this business outcome is a very effective means of eliminating unnecessary work.

However, the real benefit to this approach is the opportunity to lead the market. Short queues of features for delivery means less waiting and greater responsiveness to change. The true value of a feature may not be clear until the feature successfully helps someone to do something valuable. The faster we receive this feedback the better we can serve our customers, the more we can lead the market.

It's not cheap to achieve low cost monthly production software releases. Substantial testing and integration automation is essential for speed and to keep costs down. But. Can you put a price on market leadership and responsiveness to market changes?

Disobedience, in the eyes of anyone who has read history, is man's original virtue. It is through disobedience and rebellion that progress has been made.
- Oscar Wilde

Labels: Progress

The gang were snorkelling at Selly Beach in Manly this Sunday. It's a fantastic spot for snorkelling and diving. There's a lovely reef that runs out from point (far side of photo) with lot's to see at around 3 to 5 meters depth. This dive site is often used for training on diving courses. The reef is mainly composed of large rocks like those shown in the second photo.

For any of you trucking this way for the summer, I thought I would put a couple of pictures up for viewing: Bondi Beach, and Manly Beach...

Could Karma be applied to technology? Do one's actions with respect to software creation count towards your Karma? For example, if you wrote a badly-tested-crappy-app that made users miserable, would that create a Karmic debt?

Before I joined ThoughtWorks I worked on a lot of different projects and wrote a lot of code. Some of this code was really good but some of it was really, really bad. I always tried to improve the code, the practices and so on but I am certain that there are crappy software systems out there, that I have contributed to. I know that these systems must be driving their user’s crazy.

So, as I stare at my frozen "groupware" client, waiting for the current batch of gremlins to be exorcised, I wonder “Have I brought this upon myself?”.

It's been about six months since I’ve blogged but now I'm back, with less useful information, more silly ideas and an overall reduction in quality. Those of you in the vicinity of Australia will have witnessed the transition first hand, those of you "abroad" will have to make do with eye witness reports.

And so you ask, what has happened to Daragh? Well, to cut a very, long story short, I've sold my soul to the devil and moved into a sales role. I'm still sorting through what it all means but I think I am finally ready to start blogging about it.

At this point in my first blog entry about my recent transition, I thought about introducing an insightful metaphor – something about a caterpillar, a chrysalis and a butterfly. Then I couldn’t stop thinking moths and how they eat through your clothes, so I thought it best to avoid it.

More soon.

If so send your CV to dfarrell@thoughtworks.com

We are always looking for people who are passionate about building excellent software.

Always.

I'm just back from 3 weeks holiday in New Zealand. It's a fantastic place; wild, beautiful and completely covered in ferns. I've never see so many ferns in my life, they're everywhere.

Myself and Louise tramped (NZ word for hiked) across the Routeburn Track, one of the "Great Walks". We kayaked around Doubted Sound, socialising with the local pod of dolphins. We trundled about the country in a brightly painted campervan.

I would highly recommend New Zealand. Not just for the amazing scenery, the plethora of adventure activities, or the delicious food and wine. The New Zealanders are a warm and friendly people, and they hold their country and especially their environment in very high regard.

"The project is a great success but the system is still not being fully used. It's really hard to convince people to use all of the features."

-- anonymous person standing in a lift

I thought I would frame this thought as a law, just for fun, and because it sounds like one. Viveks blog entry got me thinking about why useability is often left behind. This is based on observation, experience, and too much wasted breath trying to convince people to spend money on user experience. I don't particularly like the reality it depicts but I do believe it to be true. Test your project with this logic and let me know if it holds.

If a company does not need to compete for business through external use of a particular software system, and if the users of the system are from different companies that will profit from the use of the system, then no more than a minimum amount will be spent on the user interface and useability. The users of this system are 'captive' users and will generally have to choose between using the system and not accepting business.

This situation commonly occurs where a large corporation has outsourced a non-core component of their business. A smaller company services this large corporation, and the large corporation builds the software used in their business interaction. Essentially the customer is building a system for the service provider, so the customer will build what they like. After all they are always right.

The converse to this law also holds, as with any respectable law :-)

If a company competes by attracting business through user interaction with a software system, then money will be spent on the user interface and useability. The amount spent will be the amount required to surpass competition.

Why is this? Well, from a financial perspective, only invest in something that will generate a return. If the captive users want a better UI, then let them build their own, integrate B2B and assume the cost of ownership for the user interface system. The people who commission us to build their software, will always use the ROI yard stick to measure the value of an activity. So before you try to change their perception of how the user should interact with the system, take a careful look the underlying financial drivers behind the development of the system. It will save you some breath, and maybe reduce your user experience evangelist status a little :-)

tintinnabulation   \tin-tuh-nab-yuh-LAY-shun\   noun
    1 : the ringing or sounding of bells
   *2 : a jingling or tinkling sound as if of bells

What a wonderful word, I've been holding on to it for ages :-)

It surprised me the difference a retrospective made. I didn't feel comfortable that we were skipping them, even thought the project was happily adapting on the fly. Retrospectives had been tried on a previous project and had not gone well. So, after 4 months of development we finally did our first retrospective. The project was in excellent shape, so it was a good opportunity. I was really amazed at the positive effect it had. What was most interesting to me was the effect the event had on the group -- we really started to gel as a team.

From 5 Stages of Group Development:

forming -> storming: risk conflict. 'To grow from this stage to the next, each member must relinquish the comfort of non-threatening topics and risk the possibility of conflict.'

storming -> norming: listen. 'The most important trait in helping groups to move on to the next stage seems to be the ability to listen.'

norming -> performing...'The Performing stage is not reached by all groups. If group members are able to evolve to stage four, their capacity, range, and depth of personal relations expand to true interdependence.'

Three thoughts keep circling in my mind lately, interweaving like a Celtic design: Stuck in the middle; "If it's not deployed, it's just a toy."; Everything is done in a sprint.

I generally find the middle part of any project really boring. I naturally love initiation. I have really learned to love completion. But the middle always sucks. Agile goes a long way to eliminating this nasty middleness. I think an ideal agile project would be completely devoid of this evil plateau of boredom.

For me, completion means software deployed in production being 'used' by users (maybe not in anger but worked with from a meaningful perspective). No toys. Initiation involves reviewing, planning, discussing. Not looking too far into the future and not predictive. Put these together and there's no need for middle.

I like the idea of absolutely everything being completed in a sprint. This seems like the right way to do things. Maybe 30 days is too long but if *everything* has to be completed then maybe not. It's a really long time to wait for feedback, but a nice tangible duration for project governance, planning (not predictive) and reporting. The people who think about money and value, love monthly reports. It's how they run their business. It's how they measure their success, and how they extrapolate their likely annual performance.

Updated: Ok,I've created a character on Stormrage called 'Darz' can you invite me to the guild? Thanks.

I hear there's a TW guild. Which server is it on? Sign me up :-)

From World Health Organisation (WHO) and WHO Avian influenza:

"No Human-to-human transmission is confirmed to have occured, but the continuing presence of infection in poultry may create opportunities for the emergence of a new influenza virus strain with the capacity to spread easily among humans. This could mark the start of an influenza pandemic. Should this rare event occur (three pandemics occurred during the 20th century), it would have serious consequences for human health throughout the world."

From Mouse Studies of Oseltamivir [Tamiflu] Show Promise Against H5N1 Influenza Virus:

"Of 80 mice infected with H5N1 virus, 20 received a placebo, 30 were given oseltamivir at one of three dosage levels for five days, and 30 received the drug at one of three dosage levels for eight days. None of the mice receiving a placebo survived. Only five of 10 mice given the highest daily dose of oseltamivir for five days survived. Although oseltamivir suppressed the virus in the mice, the virus continued to grow if the drug was stopped after five days.

Mice given the drug for eight days fared better. Survivors included one of 10 mice given the lowest daily dose, six of 10 given the middle-range daily dose, and eight of 10 given the highest daily dose. The eight-day dose of oseltamivir allowed more time for virus levels to fall and less chance for avian flu to rebound after the drug was stopped."

Working with filters is fun, mingling streams, twisting responses. But it's also kind of dirty. A bit like making mud pies, great fun but you get covered in mud. Thankfully filters wash off even easier than mud.

So I have to use a filter (struts no WebWork interceptors). And I've written tests for every thing *except* the filter. I can't write a meaningful Selenium test, and I am getting a null pointer when I deploy. A sure sign I'm missing a test. Hmmm...

So I bite the bullet and use the Spring mocks for the HTTP stuff. Yum Yum. It doesn't get any taster than this. I'm a bit sceptical about dynamic mocks (dunno why, they just don't do it from me - clearly I don't really get them yet). But these mocks really make me smile, they're just so handy.

nex·us 
   1. A means of connection; a link or tie.
   2. A connected series or group.
   3. The core or centre.

Imagine you were a part of a large fun group of people, say 800. The group has a minimum of structure. People simply do a good job. Nobody chases anybody. Everyone gets along.

You all worked together every day but at different locations and times. Your work is similar but not the same. Some of the group you see all the time, some very infrequently. Things happen. News travels. Rumours spread. Sometimes it's hard to discern fact from fiction.

It's easy to see how complex it is for quality information to propagate quickly. To improve the situation you might gather everyone together. This works fine but has the obvious overhead. You might consider introducing a hierarchy. This would not work at all.

So what can we do? How can we possibly solve this complex spaghetti communication problem? Well, we could do the same thing we always do for this type of anti-pattern. We could decentralise control.

Imagine a culture where people take responsibility for their own communication and quality of information. Every member of the group takes responsibility for regularly seeking out and exchanging quality information. Feedback. News. Gossip. Responsibility and control are disseminated. Quality information flows quickly and freely.

Awesome. What can I say. I was a little nervous beforehand. SyXPAC is generally a very technical forum. However I was delighted by positive response to the Apprenticeship Patterns.

We talked, we shared, we explored.

This was one of the best experiences I have had, discussing the very fabric of our industry. Not the technology that we all love so dearly, but the stuff that holds it all together. Our motivation, our passion, our craft.

The group was amazing. I gave an overview of the Dave and Ades’ work, and then we got stuck in. I introduced each pattern, shared my own experiences, then we discussed. The response was fantastic. Everyone had something to offer. We spent and hour working our way through the patterns of Walking The Long Road, only finishing because we ran out of video to record the event.

It’s clear to me how significant this Apprenticeship Patterns work is. When I first discovered it I soaked it up, nourishing my need for direction and definition in an industry almost barren of structure. It gives me an great sense of satisfaction to help disseminate this message, and to see the positive effect that it has on my peers.

We'll be having another session in a few weeks. Check out the SyXPAC site for details.

It sounds like Dave and Ade are having a great time at PLoP

We're going to take a look at their work so far, at SyxPAC next Monday 19/9/2005. So if you're in Sydney and you'd like to learn more, please come along to James Squire Brew House on King St Wharf for 6.30 pm.

Dave and Ade are developing a pattern language to help guide aspiring software craftsmen (-women, -people) from Apprentice to Journeyman. Personally I find the material very enlightening and insightful.

My plan is to do a quick 10 – 20 minute overview of the patterns, and then to workshop in detail the patterns most interesting to the group (we’ll use some voting system to select these).

"IF WE stop thinking of the poor as victims or as a burden and start recognising them as resilient and creative entrepreneurs and value-conscious consumers, a whole new world of opportunity will open up."

I recently read this article. It has an amazing resonance for me.

I don’t know a lot about economics, but I think I can recognise something exceptional when I see it. With his unique perspective, C.K. Prahalad is really on to something. I might be a little naïve in saying this, but it seems to me, that this is the future of economics. Now everywhere I look I see pyramids. In particular I see the resilience, diversity and ingenuity that lies at the bottom of each one.

Darren and I were charmed with this wonderful UI interaction during our recent upgrade...

The Yipster's got me thinking about this with his post on project culture. I immediately thought of Level 5 leadership.

I think Jason’s blog entry follows on from a comment and a discussion, on the fact that managers do better than developers at the XP game. This came from Mike Lee who has recently run about 10 XP games for one of our clients, as a part of a company wide introduction to agile.

Why? Maybe because managers are better at self-organisation. The crux here I think, is that good managers are also good team members. This draws me back to Jim Collins’s research, that truly great leaders have the ability to work at all 5 of levels of his pyramid, and that skipping levels is something that needs to be made up later.

We got talking about this at lunch today. Unfortunately I have not done an agile project that didn't suffer from this... from Michael Feathers IterationSlop:

"The worst form of iteration slop is what I call trailer-hitched QA. When your team does trailer-hitched QA the developers work until the last possible moment within the iteration and when the iteration ends, they hand off to the QA team. The QA team gets the "final" build and they work with it for a while, running more automated and manual tests. Often this takes close to the length of an iteration. At the end of the process, QA gives their approval and the development team looks back at them, in the distance, and says 'Great! We really did finish that work!'"

How common is this? Post me some numbers if you have a chance, % projects that you have been on where trailer-hitched QA was standard. At the moment I am 100% for two agile projects -- both were trailer-hitched (one successfully completed, the other looks good at the moment, although the QA is well behind).

Working on agile projects feels really good. Delivering regularly, writing lots of tests, integrating hourly, interacting with the customer. These are all truly gratifying activities from both professional and personal perspectives. But there's something more to this. Just standing in a agile project space, looking at the walls feels really good. Why? After think about this for a while I have finally formed a theory. To be honest my subconscious has been throwing me plenty of clues, I just haven't known what to make of them.

At school from age four to twelve, everything we did went up on the wall. The pictures we drew, projects we took part in, the words we need to learn. Everything important got stuck up one way or another. Regularly we refreshed the walls with new, important information. The wall was a source of learning, activity and history.

For weeks now, my mind has been flooded with images of childhood information radiators. I can clearly see the birds nest on the nature table, my paintings over the door, the index cards of "big words" on the wall. These images remind me of happy, productive times where learning was spontaneous - you just looked at the wall for information.

Further than happy childhood memories though, people have been drawing on walls since the dawn of time. Agile project spaces "feel" good because this is how we have presented, communicated and retained crucial information for eons. If it's important draw it on the wall and share it with other people.

(You can also send it "straight to the pool room" if it’s truly significant: The Castle :-)

I've just started working on an agile project with Darren Cotterill, in Sydney. Ben Hogan and Jason Yip have already blogged about it, so I thought I would chip in with my two cents.

The project is really quite agile but "officially" it's a waterfall project. We're considering hanging up a picture of a waterfall, just so we can point and say "look, there's the waterfall". Really there isn’t a splash of waterfall in the vicinity.

We're a small team: 3 devs, a BA, a PM, and a tester. We have an enviable collection of whiteboards and wall space. Everything we’re doing is represented on a wall or a board. The PM is open and creates some awesome burn charts. The BA is ex-techy and writes exceptional stories. The customer is relaxed and good fun. We just write tests, write code and crack silly techy jokes.

It’s clear to me that there is something special about this team. We have only been together a few weeks, and already we’re already working very well together. Some teams I have been apart of, never achieved this level of cooperation and collaboration, even after months together.

The key element within this team is flow. The flow of requirements through development into test is smooth and quicker than expected. The flow of verbal communication is instantaneous and creates an informative environment. The flow of good humour keeps us all amused. All of this creates a well functioning team but the real key is the true flow that emanates from each individual. Each member of the team is truly enjoying their work. Everyone is contributing, and every contribution is highly valued. This creates an exceptional flow of positive energy that propagates continuously. This energy motivates us to go faster, and to reach for that almost impossible end date. Well, that and the promise of “all you can drink” beer when we make over to the finish line :-)

It’s important to me to have goals. They help me figure my life out. They act as a filter for my choices.

Jason Yip recently read The Goal. Talking to him about this book really got me thinking. Thinking about a single overriding goal for me and for the company I work for, ThoughtWorks. What is our goal, what single purpose unites us?

One reader of The Goal reflected: “I just had a thought about this inspired by NonviolentCommunication: the purpose of business is to serve life, the strategy is to make money. Thinking of it this way really clears it up for me”. --JasonFelice

I thought this perspective was a bit too commercial. If business really served life then we would already live in a utopia, long beyond the point of needing a primitive concept such as currency to make our system work. I think our goal should only be altruistic: "To serve our society without exception". This didn’t quite fit thought, so I reformed my goal to:

“To create sustainable economic value in pursuit of intellectual value to the benefit of all people.”

Jason rightly pointed out that this sucked. It sound like too many concocted corporate mission statements. “Wording is too unnatural though. From the gut, how would you say it?”. So I had another go:

“To further humanity through commerce while remaining economically viable.”

Again not quite hitting the spot. So I thought for a while. I analysed the basic concepts. I looked for the simplest way to express each thought. This is what I arrived at as my goal:

“Learn some stuff, help some people, and make some money”