My son just conducted the Melbourne Symphony Orchestra!

This morning our family went to a Classic Kids concert given by the Melbourne Symphony Orchestra. Lots of fun music and dancing and learning about the instruments and sections of the orchestra. The different sections were dressed in different colored tops to aid identification, a la the Wiggles, and the conductor had a multi-colored top on.

The MSO, in more formal attire

A boy and girl were selected to conduct The Liberty Bell, and my kids, who were seated at the front were predictably disappointed not to be picked. But wait ...

After kicking off the finale, The William Tell Overture ("Hi ho Silver - away!"), one of the most thrilling showpieces in the orchestral repertoire, the conductor, Ben -- Benjamin Northey, bless him, may he have a long life and outstanding career -- dashed into the audience, asked Jake's Mum if he'd like to conduct (swift affirmative response), and led Jake to the podium where he handed Jake the baton. Jake proceeded to perform with verve, enthusiasm and undisguised joy for about 3 minutes, all the way to the end of the finale, followed by wild applause from the audience.

Benjamin Northey, my favorite conductor

It was awesome. I was in tears, Andi (Jake's mum was in tears), and Ella no doubt expects to get to conduct the orchestra next time round. It was awesome and inspiring. A child came up to Jake afterwards and said that he was better than the real conductor; that kid will not grow up to be a music critic, but bless him too!

On questioning Jake said that the fast bits were more challenging to conduct than the slow bits, and that even though conducting was fun, he would prefer to be an inventor of new musical instruments when he grows up than an orchestra conductor.

Jake played Moses at kindergarten (with stick), and conducted the MSO at age 5 in the William Tell Overture with baton. What a little legend!

Andi's post on the same incident.

Update: Andi wrote to Benjamin Northey to thank him. Here's his reply:

From: Benjamin Northey
Sent: Sunday, 22 November 2009 11:32 AM
To: Andi Herman
Subject: Re: Thank you

Hi Andi,

So kind of you to share this with me. Jake was pretty much the highlight of the week for us! The orchestra loved him and as you say, to see such pure joy was very special indeed - very moving. Loved reading the blogs also.

I hope that this is something Jake will remember for a long time. Please say hi to BOTH of your children from me!

all best, Ben

We hope so too. Thanks again, Ben.

So he writes books about movies?

From the "Overheard" section in mX:

Girl: I'm going to see Taming of the Shrew.

Friend: Is that like the book that's based on the movie Ten Things I Hate About You?

Girl: Not quite. It's by William Shakespeare.

Friend: Didn't he do Romeo and Juliet?

Girl: That's the one.

Friend: So he writes books about movies?

Girl: Have you ever been to English class?

Classic.

Opposite rhymes

My daughter Ella, who is not yet four, has invented a new word game called "opposite rhymes".

You know how the word game "opposite pairs" works: Name pairs of words that are opposites. For example:

• Big - little
• Black - white
• Hot - cold

And "rhyming pairs":

• Fiddle - middle
• Hot - cot
• Head - said

But in opposite rhymes (also known as rhyming opposites) you have to do both at once, making it considerably harder:

1. Ella: Tall - small
2. Andi: Happy - crappy
3. Andi: Sad - glad
4. Dan: Familiar - unfamiliar (deemed unacceptable)

So I'm pretty impressed with my little girl for inventing this new form of wordplay and finding the first one.

Can you find of any others? It ain't easy.

Which religion should I follow?

Gone are the days when one simply followed the religion of one's forefathers and foremothers. For those who find themselves confused by all the different choices on the market, here's a handy visual guide:

Click for a larger and clearer version

Hopefully people of all faiths and non-faiths are equally offended and amused.

Promoted - again!

It seems to be the season. Around this time last year I was promoted to CTO, and this time round, my boss has decided to move on, and I have stepped up to the hot seat of CEO-dom.

All of this has been bad for my Kibitz blogging, although I have been contributing to a new blog all about our emerging visual collaboration product: bCisive Online:

A diagram quickly knocked up in bCisive Online - click to enlarge

Divide and conquer meets visual thinking meets true real-time collaboration. Interested? Check it out, and get in touch.

That said, I'll try and post the occasional kibitz or update here too.

bSelling from the Top Down (and bottom up)

When we first developed bSelling Opportunity Management Software we had a choice: Focus on bottom-up or top-down issues.

We chose bottom-up first: Make the software easy and fun to use, and useful to the individual sales rep.

Almost immediately, our early adopters made us very aware that as much as they loved what we already had, there were burning top-down issues that needed to be addressed asap:

1. How can the sales manager get an effective overview of all open opportunities?  And then drill down.
   
2. Similarly, how can an individual salesperson get perspective of all his opportunities in order to better gauge where and how to focus effort?
3. How can a sales manager customize the qualification process to fit her team's needs?
4. How can a sales person or manager share insights with other team members, or present a pitch to clients?

We listened and have carefully crafted some exciting new features, again blending visual flair with smart functionality:

Better overviews: The bSelling Opportunity Explorer

The bSelling Opportunity Explorer is a new dashboard that shows every open Opportunity and positions it graphically based on its qualification percentage -- the likelihood of success as determined through the bSelling flip-card based Qualify tool -- and the expected Amount in $ from a successful close:

Click to view a larger image

The size of the bubble shows how much effort the rep. has been devoting to the opportunity.  Hovering on an opportunity identifies it and gives precise numbers.  Clicking opens up bSelling for that opportunity.

Overview

Looking at the overall distribution gives an at-a-glance overview of where all opportunities are at, and where the effort is going.  The four quadrants are labelled to assist interpretation:

1. Excellent: The upper right contains the best-qualified, highest amount opportunities
2. Safe bets: The lower right are well qualified, lower amount opps
3. Pie in the sky: The upper left contain the high amount, not yet well qualified opps
4. Poor: The lower left contains poorly qualified, low yield opps

Reading the patterns

With very little practice, certain patterns should start to leap out as meaningful:

• In the image above the line of small circles on the vertical axis are unqualified opportunities.  Why haven't they been qualified yet?
  
• Large circles in the left quadrants reflect opportunities where a lot of effort is going in without much progress.  Some of the "pies in the sky" may be worth persisting with (for a while), but the "poor" opps need to be quickly qualified across or dropped.

For the individual salesperson this overview can be a powerful tool to help manage his pipeline.  For the manager, it allows her to see how the team as a whole is performing, and focus action where needed.

Customization: Tailoring the process

The bSelling Qualify Tool adds rigor and guidance to qualification by asking the salesperson to flip through virtual card-decks that rate all the important factors associated with an opportunity.

It is now possible with bSelling premium to customize this standardized tool across a team or organization to meet a preferred methodology or to cater to specialized needs:

And here's an in-depth overview.

Sharing: Exporting to PowerPoint

Sales and account managers often need to report on key opportunities to executives and other non-sales colleagues.  To illustrate their understanding of an opportunity and to help their audience understand the client contacts' perspectives, bSelling premium now includes a convenient "export to PowerPoint" facility in the Diagnose Pain tool.

When pitching to a customer, diagrams prepared in Present & Sell can be turned into a sequence of PowerPoint slides in the same way.

Conclusion

bSelling remains fun and friendly, but has grown more power-packed.  

It blends bottom-up advantages (usefulness, simplicity, fun) with top-down virtues (overview, customizability) and communication (visualization, PowerPoint export).

We'll keep refining it, and can also further customize to meet more specialized needs.

Fartlek development

The amusingly named Fartlek training is a form of athletic training in which high intensity work and low intensity work are alternated in the course of each training session. The two forms of work are complimentary in that they stress the you in different ways (anaerobic and aerobically) and allow you a chance to recover.

I think that this is a good model for software development in software start-ups.

Priority one: Build something that people want, fast

The main risk in a software start-up is making something that people don't want. So you want to find out whether your initial idea has merit, fast. So -- if at all possible -- you build a small prototype, and test it out in the marketplace, fast.

In order to satisfy the need for speed, you cut a few corners, and because it's small (and your team is good) you can get away with this approach (for now).

If no-one wants your prototype, you scrap it, and you haven't wasted time on lots of process that was supposed to pay off in the long-run (because there is no long-run).

On the other hand, if it the prototype is promising, you will learn from the market feedback how to make it better, and it will start to grow. This is where it is critical to switch gears and slow down (at least for a while). Because if you do not, you will find yourself in the realm of cowboy development, the bugs will start to bite, and the pace of development will drop as your team gradually spends more and more time debugging, less time developing, resulting in a drop of confidence -- "I don't want to quickly make this change because it might break something" -- and loss of tempo.

Priority two: Restore quality (and sanity)

The alternative is to switch modes. Fred Brooks said "build one to throw away", but at a minimum you should review what has been done to date and investigate and prioritize the very real risks of continuing with a prototype. These might well include:

1. Customer or prospective customer loses data or has it corrupted
2. Customer or prospective customer experiences bugs, crashes, or loss of service
3. A crash or a bug during a demo
4. The software does not scale, so performance degrades over time
5. Development slows so that critical new features can not be delivered in a timely fashion

Improving the quality of the software process is what is needed for most of these, and many of the kinds of measures that help have largely been formalized in the Agile development processes:

• Pair programming: Two heads are better than one, plus it offers real time code reviews, mentoring, camaraderie and friendly competition, less web-surfing
• Test-driven development: Writing automated tests clarifies the design and as they build up offer an early warning system when a change breaks something unexpectedly (Design by Contract gives similar benefits)
  
• Continuous integration: Frequently "checking-in" and automatically running the automated test-suite identifies incompatible changes made by different programmers or pairs sooner rather than later; saves you from merge hell
• Refactoring: By reviewing code, eliminating duplication, reducing coupling, and improving the use of abstraction, your software base will become more concise, readable and maintainable
  
• Short iterations / planning game: By maintaining a list of feature requests and bug-fixes that the developers estimate and the internal customer prioritizes (within a budget based on the amount of work accomplished in the previous iteration), a sustainable rhythm is established, and healthy prioritization is forced
  
• Sustainable pace: Working more than an eight hour day / forty-hour week leads rapidly to damaging the code base, loss of morale, and bull sessions as people are present in body, but not in spirit -- avoid the "Death march" scenario
  

Additionally, a design review will be needed to knock the existing architecture and code into shape, and tests will needed to be added retrospectively if you didn't practice test-driven development in the initial prototype phase.

For a web-based service additional infrastructural elements and diagnostics should be reviewed and added.

All of this is manageable as long as the prototype is small, but the longer these steps are delayed, the greater the costs that must be paid. It's a lot like going into debt. You not only have to repay the loan, but also the accumulated interest. Some people call this design debt. (And the interest rates on design debt tend to be high.)

And then the cycle turns

While making incremental changes continued agile iterations is probably the way to go, slow and steady (but not slowing down). When the time comes to make a leap forward, knocking up a quick prototype is a great way to vary the routine, and makes business sense.

Conclusion
Almost everyone who learns to program first experiences the joys of "cowboy development" on small personal projects, but when they "turn pro" or start working on larger projects they soon learn that it doesn't scale beyond what you can easily hold in your head.

Some people think that up-front design and analysis will save the day, but this leads to waterfall with its 1/3 design, 1/3 development, 1/3 testing rule-of-thumb when done well. But then you discover that the requirements were wrong (they always are), and another long iteration is required.

Smart people rediscover short iterations, and lately these have been articulated as Agile Methods, and also include other ways to make the computer (e.g. automated tests) and human nature (e.g. pair programming) work effectively and more satisfactorily. The cost is a bit of deferred gratification by having to do some things up front (e.g. writing tests, refactoring) that pay off over time.

However, it would be wrong to say that an Agile approach is the best for everything, at every scale. In particular, in knocking up a quick prototype one may well be justified in reverting to some of the cowboy practices for a short period. Note that it is not compulsory to drop all the agile practices when doing so -- do what suits the situation.

The tricky bits are:

1. Not leaving it too long
2. Paying off the accumulated technical debt
3. Getting back into the discipline of following the practices
4. Combating the likely organizational pressure to continue at the previous pace!

So good luck with the fartlek development*, and let me know what you think.


*My esteemed colleague -- and former Olympian -- Ben Loft points out that interval training may offer a better analogy, but the name isn't as memorable.