Rules are always looked on as restrictive and it is human nature for teams to try and stay clear from many stifling rules, however software design and code is a different matter. We rely on rules. We rely on consistency and when its not there we are left in a more unstable position.
Code is all about rules, "rules of contract", "rules of convention" and we quickly learn the syntax and semantics to improve ourselves and get things done. But most of the 'rules' sit in lower aspects of coding, not the higher areas (in and above Object-orientation, architectural, deployment etc). We need more rules at the higher levels, but we also dont want really hard inflexible rules, but rules that can be made softer. That is where patterns live.
Although Patterns are not all that different from rules it has a lot of little extra benefits.
Design Patterns can be coalesced to make new patterns. Patterns help consistency and stability, but unlike rules, any pattern that fits the problem can be applied. Where rules give governance, patterns give common solutions.
Design Patterns help stimulate heuristics and help promote reuse of ideas and implementation and we should never shy away from anything in code that can solidify and make it more stable.
So how does this subtle point apply to a team, being Agile or writing good software?
Relating to my concerns about Design being overlooked in some Agile environments, A good way of balancing the weight of being Agile is to be patterned focused. A team focused on good design patterns, will help counter-act some ill effects of being Agile.
So to keep with a more Agile way of speaking, we can turn many of the rules that are missing from developments into patterns that enforce a certain level of certainty, without them being thought of as restrictive rules.
Previous Topic
