
I’m turning into a PBS junkie. Last night I saw a really good documentary on the making of a 100+ pound glass object - which glass artist Josh Simpson calls a mega planet.
The first portion of the documentary details much of the intense planning, research, and testing which occurred before the actual project began.
Then the artist takes his team through a detailed walk through of exactly what would happen at each stage - and each member rehearsed their part in concert with others multiple times just to be sure everyone knew what their role in the big picture was.

Going live:
Invariably, like any project of any considerable complexity, things start to go wrong.
The first live attempt to create a mega planet reveals some serious flaws in the team’s working and planning. In other areas, the team learn that despite great amounts of fore thought, planning, and tool construction, some things simply weren’t considered.

One of my favorite examples:
The team, knowing that the purpose of the entire project was to make a beautiful glass object that weighed > 100 pounds and would measure at least 13.5″ in diameter, had somehow neglected to acurately consider how to keep the massive weighted item ( remember - it’s 1500+degrees ) on their spit without actually having to hold the other end of the blow tube down.
A simple hook was devised after the near failure of the first run, which adequately held the back (light) end of the blow tube down on the spit - which meant that the team would be free to keep the glob of glass turning at a steady, consistant speed without worrying about trying to keep the thing from falling off at the same time.
The real analogy of this to software design:
The fix - that simple hook - which hadn’t been planned for or implemented in the planning stages - ended up being thrown together in a quick rig manner which was less than professional - and the hasty design ( which left two bar bell weights loosely dangling over the workers’ busy toes ) could have been made safer.
But by that time the project was in full swing. The team had been hired. The furnaces and kilns were on. The glass was hot. And worst of all, there were many other un-planned for problems which had to be fixed.
The team, almost from the beginning ( despite great pains and planning ) were suddenly in a mad scramble.
Lesson:
Eventually they work out enough of the kinks to manage success - but it makes for a great cautionary tale.
I’m not sure if it’s all that optimistic. Does this mean that, despite great planning, fore thought, and effort, projects might fail simply because too many unforeseen elements encourage confusion and mad scrambling down the line?
I know that for me, I’m always trying to get more planning time - but as the life cycle of a project ages, the amount of time alloted by management for proper planning decreases. As a result, the problems ( mostly bugs in our world ) quickly multiply. A project that seemed managed at first, can quickly feel boundless in the problems which need to be addressed before moving on.
On a small team, when the pressure to constantly develop new features without taking enough time to correct old problems (and worse) without having time to correctly implement the new features that are being added –
… well, –
… I suppose that the idea is to always keep the glass glob spinning at a steady rate.
Happy planning!