Toy Story 3. Release date: June 18, 2010. 323 days from now. Does not that amaze you? No? Most likely you are not a Project Manager. And certainly not a software Project Manager.

In software world we know how hard estimation is. And to date I have not met a Project Manager, who would commit to a delivery date a year from today. Well. one can commit, but what about keeping this commitment. Recently Boeing postponed first flight test for its Boeing 787 Dreamliner till early fall. This might not sound bad, but what if originally this aircraft was scheduled to take off in 2007?

Surprisingly, in entertainment industry they know how to give promises and keep commitments (at the very least with release dates). How do they do that? I do not know for sure, but my take is that the "secret sauce" should be in very effective scope management. And, of course, expectations management.

When film is announced not more than title, broad story topic, and, probably, some of cast is told out. More details are given out to feed public's interest, but I bet they never tell us about something that can not be done by release date with high degree of confidence.

There is certainly something to learn from this approach.

Last weekend we kind of explored the field of software estimation, so it is about time to see, why it is not an easy task. Complexity is what makes estimating hard.

Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the project

-- Jerry Weinberg, Quality Software Management Vol 1, Chapter 9

And here are some more links to explore the topic:

• The Rising Costs of Software Complexity 2001 Dr.Dobb's article.

What's the most important problem in computer science? Languages, tools, programmers? Well, according to a growing number of researchers and computer users, it's software complexity.

• No Silver Bullet: Essence and Accidents of Software Engineering by Fred Brooks.

Software entities are more complex for their size than perhaps any other human construct because no two parts are alike (at least above the statement level).

• Recent NASA Study on Flight Software Complexity (via Glen Alleman).
• Code's worst enemy by Steve Yegge. A practical view on software size as main contributor to complexity.
• The Fourth Law of Software Design: Complexity vs. Ease of Maintenance. Another practical report, which discusses how "an average-sized computer program is so complex that no human being could comprehend it all at once in their mind" and what effect it has on software engineering practice.

Did not I told you that multitasking is evil? Gauge your distraction to see it yourself! Multitasking is like using "all seasons" tires: they drive equally bad in summer and in winter. When you multitask, all of your activities end with equally bad result.

Here are some links to interesting stuff on software estimation and projects planning for weekend reading and watching.

• Your Will Suffer From Power Laws. There are some things, which are the way the are, and you can not change them, even if you want. You can not spit upwind (at least, not with desirable result); you can not make an apple fall up, when you release it. So with our projects there are some things, which we simply have to learn to live with.
• 10 Deadly Sins of Software Estimation webinar by Steve McConnell. Interesting presentation about art and science of software estimation. A lot of references to statistical studies, which give good food for thought.
• Software estimation considered harmful? Alternative point of view on software estimation as presented by Steve McConnell. DeMarco and Lister refer to study, which suggest highest productivity on projects, which were not estimated at all. Does this mean we should not estimate our projects?
• Evidence Based Scheduling. Practical approach to software estimation developed at Fog Creek.
• Agile Management for Software Engineering: Dealing with Uncertainty. A chapter from great book by David Anderson. Something always goes wrong. The problem is that we do not know what and when, yet we have to plan and execute our projects. This chapter of David's book can help you.

Finally, a tip from Leo Babauta of ZenHabits to a project manager, who needs clear mind, when  project is derailed, for finding peace of mind.

These days there is many buzz around recent announcement of Google Chrome OS. This is, probably, first loud announcement of development of new desktop OS since 2000 when Apple announced its Mac OS X. Of course, if we do not take mobile OSes into account. There are many discussions around what this means to computing. And, in my mind, this is important event, because it manifests end of desktop OS. 10 years ago you used your OS to run applications, now you use OS to access the Internet. As soon as computer became a means of accessing Internet, OS become irrelevant, because the Web-browser is the new laptop:

At this point, who cares what operating system you run? Choice of web browser will have a far more profound impact on most people's daily lives.

We've seen this in cell phone world for years: phones are not a platform for running applications, they are means of accessing cellular network. It does not matter which software is used to operate the phone. Nobody gives a crap about phone software, as long as it allows to place and receive calls with some level of convenience.

The same thing happens to computers now. It is now time, when you can actually create an OS, which will be used by audience larger than its development team. As long as it will be capable of establishing a Wi-Fi connection and executing a web-browser with JavaScript and XHTML support, all the rest will be less important.

"Time to Web" (time from the moment user powers up a computer till Google is loaded in the browser) for a computer+OS tandem will be defining a winner in today's and tomorrow's market of computing. The same way as time to repeat last call was once important for cell phones.

Today "time to Web" determines how fast you can access your e-mail, your text editor, your spreadsheet, you video and TV, your newspaper, your everything. Yes, Web-apps are usually less functional than their desktop counterparts, but as Leo Babauta says:

We don’t need feature-bloated Microsoft Word anymore. Nor Excel, with its 2 million features, nor PowerPoint (who likes to watch slides?). Sure, there are still some great desktop apps that people use, for photo and video editing and much more … but the majority of us don’t need those. We need to communicate simply and quickly, without hassle.

Web apps don’t match up with desktop apps … but that’s a good thing for most of us who use the new computing model.

Now, that we have for quite a time in-kernel Web-servers, I wonder how long it will take to create in-kernel web-browser.

I love the definition of solution from old good MSF 3.0:

Solution is the coordinated delivery of the elements needed (such as technologies, documentation, training, and support) to successfully respond to a unique customer’s business problem.

There several things in this definition that appeal to me:

• It clearly separates solution, developed with specific customer in mind, from product targeted at market, as also outlined in MSF Process Model.
• Customer's business is in the center of attention. And if the best way to address this problem is not development  of new software, so be it - it can be as simple as re-engineering existing system and providing adequate documentation or training; or instead of throwing development effort at scaling problem, one can just add more hardware capacity. Again, in case this is the best approach.
• There is no place for technology bells and whistles. If a mere VBScript can solve the issue, why waste precious time and resources on ultra-modern super-cool JavaFX (no offense here) development, if it does not add anything valuable for business?
• At last, technology is not a sole focus of solution development: delivery, documentation, training, etc. are equally as important.

Be sure to deliver your customers solutions and not just software pieces. "Software installed" is not a goal here, "problem solved" is.

There is a very interesting passage by Jurgen Appelo of NOOP.NL, which is almost completely unrelated to the idea of the post about book reading hack:

I don't want to read chapter 20, which is about platform interoperability, which I find completely uninteresting. (Let's face it: wanting to be platform-independent so that you can easily switch platforms, is just as useful as wanting to be bisexual, because it easily enables you to switch genders. Not many people think that's very important.)

While I agree with such a bright comparison of platform independence, platform interoperability is another beast. While you can kill yourself trying to have one product working equally good on different platforms, you not only may need to, but in our fast moving world have to, interoperate with other applications. And sometimes only God knows, which platform they run on.

Really nice comics blog about day-to-day weirdnessadventures of software and IT people: Geek and Poke. I just love this - Simply Explained: Checked Exceptions.

(discovered via Slava Pankratov)

If your business is in any way supported by IT, vision is an invaluable tool for you to succeed with implementation any enterprise-level project, be it a major enterprise transformation undertaking or deployment of new version of operating system on office computers. [caption id="attachment_288" align="alignright" width="141" caption="Cheshire Cat"][/caption]

Whatever you do, there will always be a question: "What's next?" If you can not answer this question, then how you can be sure that what you are doing is for good? That it advances you towards the goal?

Do you remember this dialog between Alice and Cheshire Cat?

`Cheshire Puss,' [Alice] began, rather timidly, as she did not at all know whether it would like the name: however, it only grinned a little wider. `Come, it's pleased so far,' thought Alice, and she went on. `Would you tell me, please, which way I ought to go from here?' `That depends a good deal on where you want to get to,' said the Cat. `I don't much care where--' said Alice. `Then it doesn't matter which way you go,' said the Cat. `--so long as I get SOMEWHERE,' Alice added as an explanation. `Oh, you're sure to do that,' said the Cat, `if you only walk long enough.'

The same thing with products and projects: if you do not care, what you build, then it, of course, does not matter how you do that. But when you know what is your goal, you can then build strategies, roadmaps and plans to answer the question of "how".

The product roadmap should describe the path from where you are now, to realizing the vision you have spelled out in your product strategy. You do have a product strategy, right? If not, your product roadmap has no real context, and that's a serious problem.

Marty Cagan in Product Roadmaps

Vision enables you to talk about the future and create it in the end of the day.

Vision ties your team together and enables individual contributors to achieve and overachieve.

Vision builds trust between you and your partners and allows you to focus on what you do best.

[caption id="" align="alignright" width="180" caption="New roof at Wimbledon"][/caption] For years I've been using Wimbledon tournament as an example of really good uncertainty management: with all those games taking very different amounts of time, unpredictable rains (in 2008 man's final was interrupted twice) - it is a scheduling nightmare. Yet, man's final always happens on the 2nd Sunday of tournament (except for 2001 when it was raining on Sunday and final was delayed till Monday).

Wimbledon is scheduled for 13 days, beginning on a Monday and ending on a Sunday with the middle Sunday a designated rest day. The five main events span both weeks, but the youth and invitational events are held mainly during the second week. Traditionally, there is no play on the "Middle Sunday", which is considered a rest day. However, rain has forced play on the Middle Sunday three times in the Championship's history: in 1991, 1997, and 2004. On each of these occasions, Wimbledon has staged a "People's Sunday", with unreserved seating and readily available, inexpensive tickets, allowing those with more limited means to sit on the show courts. Additionally, if the tournament is not completed by the end of the second Sunday, all remaining matches are postponed until "People's Monday".

Wimbledon on Wikipedia

Tight rules, uncertain conditions - great execution!

Now the problem with rains is fixed at its roots: roof at Wimbledon's Centre Court. This does not fix the problem complete, as other courts are still under open skies, but weather area on Wimbledon's home page gradually becomes less relevant.