Steps to remember during tradeoff analysis

It is important for all software architects to be aware of conducting the tradeoff analysis on the "Non Functional Requirements" (NFRs). It is better to have a handy tradeoff guide available during the design phase.
The tradeoff guide could be built either based on one's own experience or by taking help from other architects/resources. It would be good, if the guide covers most of the architecture principles and the non functional requirements (also called -ilities)

I would recommend following steps while doing tradeoff analysis

• Understand the customer's requirement and convert it into SMART objective
• Prioritize the requirements (NFRs) by having continuous collaboration with the customer
  
• Finally, using the tradeoff analysis guide, recommend the final design and educate the customer about the impact of the design on the priorities.
  

Open Source is not free

All of us know that the Open source softwares(OSS) are available free of cost to download, modify, distribute and even sell this to our customers and make money.

Many companies wants to use OSS in their product development/projects thinking that they could save money by choosing OSS. In reality, choosing the right OSS helps companies in saving money, and at the same time the wrong ones would incur cost to them.

Check this article out to know why OSS is not free !!

Premature Optimization and the evil

Right from the day I have started designing applications, I have been hearing people quoting the famous words,specifically dealing with "performance".

Premature optimization is root of all evil - Sir Tony Hoare (popularized by Donald Knuth)

As we aware, the words like "Premature", "Optimization" and "evil" these are generic terms and open for interpretations with no SMART objective associated with them. Developer to PM to architects, each interprets the above quote in their own way and, sometimes using it to their own advantage as and when needed.

let me share my perspective of the above quote. "Premature optimization" has two important hidden pointers. First one, the "time/period" i.e. how much "premature" is acceptable. The second pointer is "quantity" i.e. how much "optimization" is necessary.

Let me start with the second pointer "Optimization". Optimization of any application could be done at various stages. During the design stage, implementation and pre release. So, what stage is ideal to do performance optimization ? Or, should it be done continuously ?

My experience shows that following steps are needed during performance optimization

• performance criteria needs to be well understood at the beginning of the project,
  
• it should be explained to all team members(means testers included)
• Good design and coding guidelines(ex: proper use of String Vs StringBuffer, use of sets, hashmaps, etc) around performance needs to be created and taught to the development team
  
• Each component/module needs to be designed to satisfy the ground rule created at the beginning around performance, and excess tuning needs to be avoided.
  
• Check points at regular intervals should be created and performance testing should be done
  

Summary of my understanding around premature optimization quote is,

• Optimizing design,code is a continuous process happening throughout the development cycle.
  
• excess application optimization at the beginning of the project should be avoided

My thoughts mentioned above are also reflected pretty much in this artice, and the author has gone in depth and has given a good explanation around premature optimization.

Patterns to improve performance in J2EE Applications

Precisejava provides a list of patterns that would improve performance in J2EE applications. The author explains each of the patterns with good examples and reason behind improved performance.

Amazon web services goes down

It is unbelievable but true ! Amazon Web Services suffered a major outage this morning, affecting the thousands of Websites that rely on its storage (S3) and cloud computing (EC2) services. Here is the whole story

When I first got introduced to S3 and saw the demo of the concept with the high availability architecture behind S3, I felt this is the thing of the future. Now, I am thinking, we still have a long way to go while building highly scalable and available applications.

101 design pattern tips

This site has a consolidated list of 101 design patterns. The author has put a lot of effort in organizing the patterns into different groups (GOF + others). Upon clicking on each of the patterns, it provides the motivation, mechanics with an example.