Zen and the art of Castle maintenance

A prospect call me yesterday. He wanted us to build a system that offered stock quotes, performance, history and whatnot. An ocean of information to investor. So far so good. But he had a deadline “it has to be completed by September”. I said that’s not how I work. He would be able to buy our hours, the system would be build incrementally. Every Friday or Monday he would see what’s been done during the week. He would be able to correct, change priorities, explain more about features. If the time is running out, you could select the main features. “No I want the whole system by September”. Serenity now!

“I had two quotes from companies that guaranteed the system would be done by September”. Great, they can guarantee that? I can guarantee that I will deliver an Island in central pacific with your system, in September, I said. “I can tell you anything in order to have you signing the contract, but that’s not how I work. I just cannot promise that the system can be done by September, we cannot anticipate things in software development, and ought to be surprises in the way”, I said.

And there would be. The system should have an online channel with Bovespa and BM&F. He wanted the system to update the quotes directly on the database, no lag. Imagine thousands of changes per second on several tables, performances being updated and all of this with three thousand users sending their queries. I’m sure we would have to be very creative to prevent timeouts and deadlocks.

I also mentioned that all my team were allocated this month, some of them in more than one project. So I wasn’t sure if I could start the project soon. “You can start the project in August, as long as you deliver it in September”. Ok, my patience doesn’t last forever.

I couldn’t lie to him or promise something that I just don’t know for sure (if the system could in fact be done by September) and he decided to go with one of the others companies, which btw charge more than us. This was a prospect from Brazil, and (un)fortunately I don’t get much of them. I had no problems convincing people from abroad about our approach, but most of them come from a technical camp.

I wonder if selling agile-built-projects is possible at all. At least here in Brazil.

“What’s wrong with setting a goal and a date, and expecting a team to tell you how they are going to meet that goal and that date? Presuming that the goal and the date are both driven by business needs?”

Which was promptly replied:

“What’s wrong with me telling you I expect you to climb mount everest in 3 hours, and expecting you to tell me how you are going to do it?”

Post from the extreme programming mailing list yesterday:

Dakota tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. However, in business we often try other strategies with dead horses, including the following:

• Buying a stronger whip.
• Changing riders.
• Say things like, “This is the way we have always ridden this horse.”
• Appointing a committee to study the horse.
• Arranging to visit other sites to see how they ride dead horses.
• Increasing the standards to ride dead horses.
• Appointing a tiger team to revive the dead horse.
• Creating a training session to increase our riding ability.
• Comparing the state of dead horses in todays environment.
• Change the requirements declaring that “This horse is not dead.”
• Hire contractors to ride the dead horse.
• Harnessing several dead horses together for increased speed.
• Declaring that “No horse is too dead to beat.”
• Providing additional funding to increase the horse’s performance.
• Do a Cost Analysis study to see if contractors can ride it cheaper.
• Purchase a product to make dead horses run faster.
• Declare the horse is “better, faster and cheaper” dead.
• Form a quality circle to find uses for dead horses.
• Revisit the performance requirements for horses.
• Say this horse was procured with cost as an independent variable.
• Promote the dead horse to a supervisory position.