How many times last month did you use Power Point? Most would have used it at least a couple of times. Power Point is one of those products that seem so natural and effortless to use. And when you think about it, Power Point acquires its muscle from its core ability to dumb down a variety of thinking processes. What were its creators — Dennis Austin and Thomas Rudkin – thinking when they were writing Power Point? Could they imagine that within 25 years their creation would be installed on over a billion computers worldwide?
Ironically, Power Point was designed for the Macintosh and was the first venture capital investment that Apple ever made. Forethought, the company which created it, was bought by Microsoft in 1987. With such a rich history and possibly the only company to have the two software behemoths in its DNA, we may well ask, “What have Dennis Austin and Thomas Rudkin done after Power Point?” Austin created some average-to-middling clip art (Screen Beans) and Rudkin worked for Microsoft in Silicon Valley, turning Power Point into a product with $100 million in sales. Why could Austin and Rudkin not create another great product?
That’s because creating software products is not like building a home or a work desk. The problems that software solves are not the same as those which apartments and office cubicles solve. Software solves newer problems (hopefully!) each time. That’s why there are more failures in creating software products than in making homes and offices. Every time a software engineer sits down to write code, the end goal is different – and often the end goal doesn’t stay the same through the lifecycle of the product’s development (surely you are familiar with scope creep and change requirements?).
It doesn’t matter that the profession has its own set of guidelines and best practices to follow. There are languages and project management techniques. There are tools and quality processes. Yet, practically any software project you come across has seen time and cost over runs, has versions lying on shelves that have been discarded, and has bugs that cannot be eliminated before release (these are passed off as “known issues”).
Why is it that creating software products is such a random process? Why can’t success be replicated even though the team has experience and ability? In other words, if there is a lesson in the creators of Power Point, it is this: building software products is not like constructing a home or a table with raw material that is pretty much standard. Software products have to be built from the ground upwards. From the framework to the data types and structures, from how the data will be
managed and manipulated to the protocols and networks that will come into play and finally how human beings will view it, store it, share it and deploy it. Creating software products is an intensely unpredictable process. The industry may try to provide examples of how great products were created, the role of engineering and innovation, of time and funding, of requirements and usability, market studies and prototypes and a whole list of other imponderables. None of them hold fully true when you get down to solving a new problem with fresh code.
The point is this: if you are trying to create a software product, the top most problem you have is not your skills or resources, but the expectations that industry has about you getting it right first time. You can’t will that expectation away. The trick is to not let it weigh you down – or even dictate the course you are charting for yourself.