can put a hefty price tag on them, which attracts wealthier customers. Why not follow the car manufacturer's model and build high-quality software? Is it possible to create brand loyalty in software development?
Software can be used and copied as often as we like, if we do not consider the legal implications, of course. Software does not need regular maintenance, but does occasionally require updates that are packaged in service packs and patches. Tightening screws every 50,000 miles and dealing with rust in cars is expected, yet those additional software releases are often seen as fixes to "errors" in the original product.
Maintenance of old software became obvious during the Y2K change, when organizations needed to make changes to software that had operated for the past thirty years without any modification. Some of those programs were so reliable that people forgot they even existed. Some items actually increase in value over time, like old cars and other vintage items. But who would be proud to run MS DOS on Intel 80286?
A good example of things that increase in value over time is the Internet. Basically free of charge, we can browse very well and very poorly designed Web pages. One scripting error or wrongly rendered page and an entire company's mission statement, "We produce quality software," could be a joke.
Marketing and product management constantly face the challenge of promoting a "value" with the message, but the competitor is just a mouse-click away. Picture a gourmet high-priced food store that wants to expand and sell groceries via the Internet. Customers visiting the actual store can smell the fresh products, touch and experience the inventory, and meet and chat with neighbors. It would take superior design skills to broadcast a similar experience over the Internet. Even with excellent products and services, the gourmet food store might lose business against discount supermarkets on the Internet, and a template approach would fail.
Conclusion: Innovation is value.
Managing Good Software Projects
If you ask an author how long it will take to write a new bestseller, he most likely will say, "How do I know?" If you had asked me as a programmer how long it would take me to solve the programming issue described in the beginning of this article, I would have answered in the same way. How would I know that the solution would hit me after three days? IT project managers ask questions like the one above and expect an honest answer. We realize the difficult scope of this question if we ponder our own undefined question, "How much time will it take you to plan and manage this project?"
When assembling a car, we can ask an engineer, "How long will it take you to add the wheels to the car?" "Four-and-a-half minutes," he might respond. But then ask, "How long does it take you to engineer a brand new car from scratch?" and see what kind of response you get.
For example, the weather forecasters never guarantee any weather development. They predict and estimate the likeliness by watching weather patterns. The more local the source of the weather forecast, the better the predictions. In software engineering we ask for a guarantee because estimations and likeliness do not match the standard for "hard" numbers taught in business schools. And software projects are often run or sponsored by business units.
Good software is made by good teams, including the project manager. Often times, project managers are external to the team environment rather than part of it. Running a project by forecasts and interviewing project members is less predictable than