Wednesday, 14 November 2012

Faster, Better, Cheaper

Software Architecture or Project Management or anything in general in life is all about making trade-offs. We always need to choose from the available options. We have to compromise on something to gain on other things. Which one to loose and which to gain is the process of making trade-offs.

In the software development out of the three options faster-better-cheaper we can only choose any two. If we want our product to be ready immediately with better quality less bugs we need to spend more money on it. In this case we gained speed and quality, however we loose on price. At the same time, if we do not have much budget we needed to settle for either slow development time or on quality.

In the architecture, if my software wants to serve with fast response I need to scale the system. I can scale either horizentally or vertically. This involves cost. Ofcourse, code refactoring or tuning can improve the system's performance upto some extent but to really improve performance the system has to be architected with load balancing or caching mechanisms. In order to provide quality of service (QoS) like 24x7 availability, we need to plan for failover strategy. There are various options to choose (active/passive, load balancing, caching etc) depends on budget.

At one point we cannot get all of three choices. Correct balance is important when making trade offs. The most important thing is to involve stakeholders of the project during deciding the trade offs. Their involment is critical because they are the people who actually use the system in future.

For example, if we are dealing with marketing department, they needed the software faster in order to go to market asap. For them it is time to market scenario. If they have budget, more people can be involved in the project and can be completed faster with better quality. If the project is internal for few staff, company may not provide super budget, in this scenario we can compromise on speed. We can deliver software in reasonable timeframe with limited resources.

In the architecture or project artifacts, either architect or project manager should document the gains and trade offs he/she considered and the reasons behind these decisions. The architect or PM should also take stakeholders approval of these artifacts. Anything in document can save us later point of time in projects when something happens to the project in chaos. Documenting decisions is always a good practise rather than verbal communications.