Tuesday, February 22, 2011

Principles vs Rules

 

Recently I had an interesting question.. “We heard about design patterns but what are design principles?”

I would try to answer this question in a 2*2 matrix..

principles vs rules

The above matrix essentially talks about 2 things.

  1. Principles: They revolve around the primary focus of the project. These are like
    1. QOS – Quality of Service concerns, they focus around how many number of concurrent users, how many transactions per sec., whats the allowable downtime etc.. this essentially talks about each layer and what the project is looking in terms of numbers
    2. Functionality of the system that is developed – whether captured perfectly or not.
    3. Is the architecture extendable
    4. Are we giving plugging points
    5. How is the risk being mitigated in the project at several points
    6. What are the back up / back out plans
    7. How is the client satisfaction safe guarded for  repeatable business
  2. Patterns : The rules or patterns of good standards.
    1. What are the patterns at each layer
    2. These can be OO related / Database related / libraries related
    3. Reference architecture wise..
    4. Agreed upon development environment i.e. Code Coverage / Unit test coverage etc.

So essentially these are orthogonal, even if I have a very well defined architecture, that might get the QOS screwed. Once the QOS is screwed then its as good as dead since we can’t make ahead way with the project and the client can’t use the product.

I see that QOS must be the heart of the system that’s being developed. With Functionality being safeguarded. These 2 things when are backed with the Rules that make a perfect project.