Failure means distrust. Distrust to you about delivering on your promises; distrust in your ability to make a difference; distrust in you taking care. Basically, it is as simple as:

1. Drawing attention to a problem without communication of causes and planned corrective actions.
2. Repeating the same error again (when you do not change anything after step 1).
3. Making problem a habit, when it happens for the 3rd time. Now it is clear for everyone that you do not give a heck about what's going on.

After step 3 there is almost no way to recover.

At the resort I stayed with my family for a vacation, we had breakfast served at 8:00 am. The first time a crowd of about hundred people had to wait for extra 10 minutes till they started serving, I remember my thought "Can happen. Probably, they wanted to please us with something special and underestimated the time."

Waiting in the crowd the next day I thought "Something went terribly wrong here. There must be a serious challenge involved at serving at 8 am."

After the third time nothing could make me come to breakfast at 8 am. I knew they did not care that we all had to wait for 10 extra minutes in a crowded room. I had to find a solution for myself and I did! Thereafter we came to breakfast 10 minutes late. In other situations, when your customers have more flexibility, they will simply quit your service. They will not do that because  there are issues, but because you do not care.

Take care to fix issues your customers face.

I was amazed when I saw this video. Object removal is especially impressive.

And it seems that you already can use similar technology in graphics and imaging products. Check out this Photoshop CS 4 tutorial and Liquid Rescale GIMP plugin.

For this weekend we'll get some reading on the topic of requirements in Agile:

• Writing Good User Stories. Nice concept of INVESTing in user stories.
• Latest description of FDD process. Pay attention to step 2 'Building a Features List'. Apart from precise definition of what a feature is, it introduces an interesting idea of time-boxing for features: a feature should not take more than 2 weeks to implement; if that's not the case - break it down.
• Why I still use use cases. Alistair Cockburn on what can be wrong with user stories.
• Writing Complete User Stories. Nice guide on how to address often perceived problems with user stories.

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.