Punjabi By Nature

Project vs Product

Many people question me, that other than the business models, which Cusumano has already written about, what is the difference between a project and a product.

I like to answer this question by giving an analogy. In the phrases below you can safely replace the word "book" by "product" and "newspaper" by "project".

A book is something that takes a long time to create. It has a deadline to be done, but that deadline is not very hard and fast, and can be move around a little. A bookwriter spends a lot of time in thinking upfront about how the book will be written. All the elements of the book must come together as a unified whole, rather than a juxtaposition of various elements. A book is used by many people across organizations, over long periods of time.

Contrast this with a newspaper article: A newspaper article has a very hard deadline. Either you ship it tomorrow morning, or else its stale food and no one wants it. The pressure in a newspaper is to get the job done and a lot of time cannot be spent on upfront planning. Sometimes newspaper articles look like a random collection. A newspaper is used once and thrown away. Very soon a new newspaper will be created, and used.

This is the difference: A Product has a long term in mind and has to be carefully designed and relevant to a lot of people across organizations. A project typically has a shorter term, hard business requirements, and needs to be done quickly else business will pass it on for some other (maybe newer) approach.

Project vs Product

In the software industry, two models are basically followed.

(1) One that is of building products at one end of the spectruem.

(2) Projects or bespoke implementation of a particular customer's business process, is at the other end of the spectrum.

There is a third model of "hybrid solutions" which I believe is a mix of the two, so I will not discuss it here. These two "business" models are described very well in a book called "The Business of Software" by Michael Cusumano.

Cusumano builds on dozens of personal experiences and case studies to show how issues of strategy and organization are irrevocably linked with those of managing the technology and demonstrates that a thorough understanding of these issues is vital to success. At the heart of the book Cusumano poses seven questions that underpin a three-pronged management framework. He argues that companies must adopt one of three basic business models: become a products company at one end of the strategic spectrum, a services company at the other end, or a hybrid solutions company in between. The author describes the characteristics of the different models, evaluates their strengths and weaknesses, and shows how each is more or less appropriate for different stages in the evolution of a business as well as in good versus bad economic times. Readers will also find invaluable Cusumano's treatment of software development issues ranging from architecture and teams to project management and testing, as well as two chapters devoted to what it takes to create a successful software start-up. Highlights include eight fundamental guidelines for evaluating potential software winners and Cusumano's probing analysis, based on firsthand knowledge, of ten start-ups that have met with varying degrees of success.

Introduction

When I relocated to India a few years back, one of the things that struck me was that whilst there are lots of talented people in the country, the emphasis on excellence was lacking. At first blush, it appeared to me that this was specific to India. However, I found that as I traveled around the globe meeting developers and other programmers, I found this issue is endemic to the software industry.

Of course, my tunneled vision was because I had worked at Redmond, where Microsoft has hired a lot of smart people. I extrapolated that to believe that the entire industry (including India) was full of talented engineers committed to excellence. Whilst this may be true of many companies like Google, and some startups which can attact talent because they are working on the next "big thing" its not true in general.

At the same time, I started looking at how difficult is it to be committed to excellence. I started researching my old emails, my work from previous years and also what I learnt over the years from my peers, and mentors. It turns out that by following some very simple practices, one can make excellence a habit. Something, without which your professional life is incomplete. Your better professional half!

I hope you will find this series of articles useful and will share your thoughts to improve it. Happy Engineering!

Engineering Excellence

The software industry is littered with companies, big and small, who exist solely because they produce and sell "software". If there was a way that they could make all this money without writing software, they would! However, it is quite surprising that very little attention is paid to writing quality code. The process of delivering projects at times has taken overwhelming precedence to quality or the art of programming.

I have always believed that writing software is a creative and artistic profession. Many years ago, when I first saw the code that Dave Cutler wrote for NT, I was so mesmerized that I did not want to touch it, lest I spoil it :-)

With this brief background (there is a lot more to say here) I embark upon these series to share with the developer fraternity some of my experiences and what I have learnt over the years from my mentors and the gurus of programming.

Please let me know your feedback about the series in general or a particular topic specifically.

The purpose of this series is to:
•Help you get up to speed as an effective developer
•Prepare you for long-term success in your career

You will understand how to:
(1) Use Product Cycle Model for success
(2) Schedule projects
(3) Design great software
(4) Document your designs
(5) Make hard design decisions
(6) Achieve performance and reliability in your product
(7) Work successfully with other disciplines
(8) Reduce bugs by testing your code thoroughly
(9) Avoid legal and geo-political issues
(10) Design and write world-ready products
(11) Write production quality code
(12) Design and write secure code
(13) Speak so people listen
(14) Have productive spec, design, and code reviews
(15) Debug your code effectively
(16) Write effectively
(17) Develop your career