Technorati code: FMUS579NQBM8
Saturday I went to a high school half an hour north of our home, to watch my 16-year-old daughter compete in a cheerleading competition. And I learned something about software.
I’m not sure how many teams were there–maybe a hundred. The competition started at 9 am and was scheduled to run through 5. Every team consisted of dozens of girls, all dressed in spangles and glitter, with identical ribbons in their hair. They’d march out onto the floor, drop their heads and arms to their sides, and wait for the first blast of music to initiate the routine. Then they’d tumble and dance their hearts out, finishing out of breath with a flourish.
Every hour or so, the performances suspended so judges could announce winners in a particular division that had just fielded its last competitor.
I noticed a pattern. Even though I have no knowledge of competitive cheer scoring, I could tell who had won. It was not the teams that had the most members, the best costumes, the whitest smiles, or the most spectacular acrobatics. It was not even the teams that had the fewest glitches, necessarily.
Winning teams had one thing in common: They were better synchronized.
So how does cheerleading say anything profound about the business of designing and making software?
Judges in cheerleading are looking at a gestalt, not so much at individuals. The lines of the entire team, the volume boost from a simultaneous clap, the way they turn in collective unity to create a visual impression–this is what separates the superb from the average.
I saw several winning teams make small mistakes. One time a girl slipped as her teammates were doing a lift. She was trying to stand on shoulders, but missed; her foot dropped down into the crook of one of the lifter’s elbows instead. But she stayed vertical, and she raised her hand to salute the crowd at the same moment as her twin on the opposite side of the formation.
If I hadn’t been studying carefully, I would have missed the mistake. I suspect most of the crowd did–they were all focused on the symmetry of the overall performance, which didn’t waver.
Cheer is a competition won by harmonious systems, not individual superstars.
So is software.
Geeks Who Flunk
We software pros forget this, sometimes.
We forget that we are optimizing many variables at once.
We accept all feature requests at face value and don’t vett them thoughtfully against our why.
We retreat to our cubes and grumble that people keep getting in the way of us getting work done, but we don’t get serious enough about managing everybody’s interruptions wisely.
Geeks Who Pass With Flying Colors
All of these memory lapses can be viewed as failures in system thinking. The software we create, and the people that surround and permeate it, constitute a system. We will not be successful unless we create harmony in the whole.
Smart geeks think like cheerleaders!
Create a new kind of architecture diagram that shows how all the parts of your system are related–not just the software components, but the people who create requirements, the sales force, the dev team, the executives, support, customers, your CRM or ERP apps… Instead of arrows for “is-a” or “one-to-many”, how about arrows for “provides moral support” and “keeps the lights on” and “frees me to concentrate on the kind of problem I like best”? How is this system compensating for minor imperfections in individual performers? How can you add to its symmetry and synchronization?
- Using Systems Thinking to Increase the Benefits of Innovation Efforts (thinking.net)
- Systems Thinking (ideasresearch on youtube)
- System thinking in the cloud world: the secret to a successful cloud roadmap (HP Blogs)