Saturday, April 30, 2005

The cost of software

I've recently watched "The Aviator" on DVD. The movie about Howard Hughes. What an interesting personality. After watching the movie I was keen to find out more about the man.

I found an autobiographical link on the web: read it yourself. My conclusion on Howard, is that he was a man caught up with his own self importance, driven by ego. I couldn't help feeling that perhaps he was a victim. Possibly of a over bearing father who expected nothing less than greatness from his only son. Unfortunately the movie and the online autobiography say very little about his childhood. Apart from his affliction with OCD, the sadness of his life for me was that he spent all his time proving himself, and very little time actually living.

After reading about Howard Hughes, I was keen to explore the lives of other very wealthy people to see if I could find a common link. I looked up Bill Gates I expected Bills' autobiography to contain all the signs of an ego centric megalomaniac (Much like Howard Hughes). But it didn't. Pretty dull actually. Bill Gates appears to be your regular nerd. No vision of grandeur. No big I am. It was when I read his open letter to hobbyist programmers written back in 1976 that I got a real insight into the man:

Now Bill Gates is the man we all love to hate (my self included), but reading his letter I realised that he had a point back then. He wanted to produce good software and get it out there to the fledgling personal computer community. What's wrong with that? I found myself asking. To do it he needed good programmers, and good programmers deserve to get paid for what they do. He didn't want people "stealing" his software, especially when they stole and distributed pre-release buggy code - giving him and his software a bad rep.

After reading his letter I now see Bill Gates as the first nerd who cared enough about what he did to elevate software to something valuable, and in common with the producers of other valuable products, he demanded payment.

So how does this sit with the ideals of the open source community? Not sure. I've always seen the common sense in collaboration - working together for the common good. But I always thought that this work should be paid for by the people that benefited from it. For example, a lot of fortune 500 companies could save themselves a lot of money if they worked with each other to generate common software, that they shared (open sourced). They would end up paying the programmers they hired a lot less then they currently pay software vendors like Oracle. The idea of programmers writing code in their spare time for free, and then "donating" it to their employers never made sense to me.

Some people have used open source as a means of bootstrapping a services business, JBoss comes to mind. This is a neat idea, but the few JBoss consultants that actually get paid, are leveraging the work of an whole army of programmers out there that never see a penny. So my question is why do they do it? The programmers I mean. What motivates them?

My guess is that many in the open source community may have more in common with Howard Hughes, then Bill Gates does. The ego boost of having their code used and worshiped by their peers is perhaps payment enough.

Friday, April 08, 2005

Agile Development - Knowledge, Understanding and Skill

As I mentioned in a previous blog, on my current contract I have been performing the role of Agile Coach. I'm not sure that i'm a natural fit for coach, but the project desperately called out for Agile practices, I was the one with agile experience, so I was made coach.

On my previous project, I had the great fortune to be coached by Rachel Davies. Rachel is a very well respected member of the agile community. She is the chair of the extreme Tuesday club in London ( and a director on the board of the agile alliance (you know the people that wrote the agile manifesto:, people like Kent Beck, Martin Fowler, Bob Martin etc). In the Agile community you can't get better credentials than this. Racheal really impressed me in the way she assisted our team in coming to the right answers for ourselves. Never telling, but patiently observing, taking notes, pairing with individual members of the team, and providing input in the most subtle ways. In short Racheal demonstrated a very high level of skill.

In contrast, I'm more of a teller and a doer, not that good at observing and influencing, but inspired by Racheal I resolved to do my best in my new role. Interestingly, my immediate successes where with the Management. Within a short time I was able to demonstrate the power of user stories. The technical management had been having a difficult time in defining the requirements with the users and avoiding scope creep. They where quick to appreciate how stories would help.

Soon we where up and running, boostrapping the XP process by initially writing stories ourselves from the technical specs. We then introduced stories to the testers, who where quick to get on board after months in the dark. The next person on board was the user. He found seeing what he was getting and defining priorities a massive improvement. So much so he cleared space in his diary to be with the team 3 days a week.

The people that proved most difficult to influence was a, the business analyst and b, the developers. The response of the business analysts was somewhat expected. These people have a vested interest in producing paper specs that everyone knew had limited value. We needed to tread careful, coaxing the BAs into realising that stories could be good for them too. Even with the BAs we have had some success, with one or two of them being quite keen to write stories instead of continually revising specs.

The difficulty with the developers came as a great surprise. Some members of the team initially found it extremely difficult being told what to do. I believe the phrase don't teach me how to suck eggs' was quoted more than once. I had to go to great lengths to stress that I was merely identifying an alternative way of working, which in no way invalidated the way they had worked in the past. The experienced developers were quick to see the benefits of XP practices even though the practices were not familiar in themselves. The less experienced developers in the team however, found it more difficult to see past what they already knew. For example, TDD is still seen by some as primarily a unit testing technique (as opposed to a programming and design approach).

NIH (Not Invented Here) and ego centric technical debates soon engulfed the team. Unnecessary complexity was added to the code base, and technical debt began to grow. Worst still I was in danger of becoming the main protagonist in these technical debates. People wanted to prove that I was wrong, and that they knew better. This situation called for swift action. I decided to take a back seat, stopped leading from the front and allowed the team to make decisions for themselves. That iteration no stories were delivered, instead people bussed themselves with technical tasks, making "improvements" to the core architecture.

After the experience of zero velocity, many in the team realised for themselves that Agile development required discipline. My next step was to clarify my role, by suggesting that we needed a technical lead. Fortunately we had a good candidate in the team, who was keen to take on the role. For a couple of iterations velocity soared under our new lead.

Now we are potentially weeks away from our first release. Unfortunately the technical debt incurred during earlier iterations still needs to be paid. It will be interesting to see how things work out.