Fast, Good And Cheap

Fast, Good and Cheap represent three aspects of a project - the timeline, the quality and the budget. Depending on the situation they are sometimes fall into requirements or even constraints. The fact is that usually these three are combined by the “Tyranny of OR”. One can choose either

• fast and good OR
• good and cheap OR
• fast and cheap

The option of all three is not considered to be practical.

The Triangle

I have been able to represent this the best by setting them at three different points of a triangle. You can choose any one side of the triangle. These three points can also be considered to be different costs of the project. You can ignore the one that you can afford to. In reality, no one can afford any cost, it is either a compromise or an investment, depending on how you look at it.

But this triangle is an important one to consider if you are trying to set priorities for the project. The priorities can help you choose the side.

I do agree that all three together is not always practical, somewhere someone has to absorb the cost. In some cases it has become possible, because of open source. Let us take a simple example for our purpose of understanding. If I want to setup a good blog, I can do that today, literally in 5 minutes, or maybe in half an hour by using tools like Wordpress, and using of the many themes available with it. The ones who has absorbed the cost here are the Wordpress developers and the theme designers.

However, this is limited to just that, simple cases. The moment you introduce your own requirements, like branding or functionalities, you will have to absorb the cost for that somewhere. And experience has taught me that a software project is hardly only about software. It is more about the business and the user. It is about their ROI. Software too, is hardly about development, it is about usage. Every single business and every single project is unique. So, even if there is a shelf of ready-made software available, chances are that someone is going to have to spend time and effort in working out why, what and how the software has to be developed.

Solutions?

I have realized that almost all the thinking that I do about improvements in software development finally boils down to converging these three points, or at least minimizing the effect of the OR. I personally would not like to do poor quality work or for that matter sacrifice any of the three. We can make sure through our process that we optimize our efforts, but is there anything to bring these points closer? I cannot say that I am anywhere near it, but I have found that using iterations gives a chance to work with manageable pieces, giving us time to prepare for the impact. More thoughts on this later. What do you think?