Software Project Planning Class on 7/15 in Bellevue

2010/06/12

I am holding a project planning class on 7/15 in Bellevue, Washington.  This is the second class in the Taming the Software Dragon series, specifically focusing on creating great plans that help guide your software project to success (The first class was about software management fundamentals, which was held back in May.  Although the class is not published on this site, I will eventually bring its content here).

The seatings are limited – sign up at the link below.

Taming the Software Dragon – Software Project Planning I

Have you stare into the software dragon's eyes lately?


Management Lessons from Titanic

2010/04/30

When Jack Dawson won two tickets to aboard RMS Titanic in a poker game, little did he know that he would meet the love of his life, Rose, and that he would never live to see the land again.

Titanic stands as one of the most famous maritime disasters in human history, and there are plenty of project management lessons that we shall heed from this tragedy:

1. Even the unsinkable can sink

Although Titanic claimed to be “unsinkable” and Captain Smith and the crew had deep experiences with transatlantic voyages, she still perished. [1]

There are risks associated with every project.  Nothing is 100% certain, and assuming otherwise can have dire consequences.

2. Always be realistic and prepare for the worst

Titanic only carried 20 lifeboats, which only accounted for 33% of the passengers.  Although it was above the regulation requirement at the time, it obviously was not enough.

Whether it’s because they were trying to save room to sell more tickets, or that they were superstitious about carrying more lifeboats, or that they really believed Titanic being unsinkable, it shows that when one is not being realistic and prepared for the worst, disasters can ensue.

Anything can happen on a project, and preparing for the worst is only the prudent choice.

3. Being overly ambitious increases risk

When J. Bruce Ismay asked Captain Smith to speed up the ship for early arrival to generate publicity, he sped her up toward her doom that arguably might have been avoided all together if she had not increased the speed. [2] Read the rest of this entry »


The Limits of Any Process and Methodology

2010/04/26

The father of computers, Charles Baggage, once remarked the following

On two occasions I have been asked, – “Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” … I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

The modern paraphrasing of his sentiment is short and memorable: “Garbage in, garbage out“, a.k.a. GIGO.  No matter how intricate the computer/program is – it is not magical and cannot overcome erroneous inputs.  This is one of the things computers cannot do.

Although principle borders on stating the obvious, in the real world it is anything but.  I can recall many times this principle is invoked on my projects, and GIGO is a well known phrase means others have been doing so as well.

This discrepancy of understanding also puzzles me to no end, until one day I re-read Arthur C. Clarke’s 3rd Law:

Any sufficiently advanced technology is indistinguishable from magic.

And voila, all the pieces suddenly fit in my head.

See, Clarke’s 3rd Law applies not only toward a prehistoric caveman accidentally peeping through a wormhole to observe today’s routine surgical procedures and believe them as magic, but also to us modern humans with today’s technologies.

Although today we believe in science instead of magic, any existing technology that we do not understand well qualifies as “sufficiently advanced”; and when we do not understand how it works, we will not be able to correctly judge its capability and limitations.

This leads me to my corollary of Clarke’s 3rd Law:

Lack of knowledge on any sufficiently complex technology will lead to misjudging its capability and limitations.

Those who lack the necessary understanding have little basis to judge what computers can and cannot do, and in that case, it is not surprising that they might over estimate computer’s power, in this case, missing the GIGO principle.

But wait – there is more.

GIGO and Clarke’s 3rd Law (or my corollary if you will) apply not just to hardcore technologies such as computers or software, but also “soft” technologies such as processes and methodologies.

No matter how sophisticated or advanced a process is, it is just a series of steps, an algorithm, not magic.  It will not magically transform erroneous requirements, designs, or decisions into correct project outcomes.  It is still subjected to GIGO.

And without sufficient understanding on processes and methodologies, we are subjected to Clarke’s 3rd Law and that lead us to the belief that just because we have switched from waterfall to XP or Scrum and everything will now be fine.

Does this mean that process and methodologies are not important?  No, but this puts things in proper perspective according to their impacts.  Utilizing an agile methodology instead of waterfall might allow us to recover from the impact of a bad requirement or architecture decision more quickly, but it won’t come up with the right answers for us – we still have to find them ourselves.

And we place our trusts in methodologies when we do not sufficiently understand their capability and limitations.

So next time when you run into a process buff telling you that his favorite methodology is the silver bullet to all your project woes, send him the link to this post ;)


Follow

Get every new post delivered to your Inbox.