Little Rules And Patterns

ObjectOrientedDesignIsDifficult

The biggest thing I have realized is that my code quality did not improve by following a better recipe-like process. My code quality improved by following a better bunch of little rules. The bunch of little rules I use now are better than the bunch of little rules I used six years ago. (The XP rules, and several other rules from Wiki, helped my collection of rules a lot).

I don't really know if LittleRulesAndPatterns are alike or different or both. But the rules I end up with seem to be quite concrete - about the same level of concreteness as pattern names.

Very little rules (like what you shouldn't do in a constructor) are less known than complicated DesignPatterns, especially since they don't have fancy names. And they're ignored all over the places.

KentBeck, in SmalltalkBestPracticePatterns, said: "I'm not a great programmer, I'm a pretty good programmer with great habits."

This is the way of it: the rules expressed so strongly here aren't my rules or Kent's rules. They are the rules that the team embraces. We do require everyone to follow them, because we believe that they make us more effective. When the situation changes, or we get a better idea, we discuss possible changes and often change the rules. After all, "They're just rules" is one of our rules.

AgileSoftwareDevelopment

"Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior." --DeeHock, VISA System (requoted from AlistairCockburn's AgileSoftwareDevelopment)

http://www.enteract.com/~bradapp/docs/patterns-intro.html

Patterns for software development are one of the latest "hot topics" to emerge from the object-oriented community. They are a literary form of software engineering problem-solving discipline that has its roots in a design movement of the same name in contemporary architecture, literate programming, and the documentation of best practices and lessons learned in all vocations.

Fundamental to any science or engineering discipline is a common vocabulary for expressing its concepts, and a language for relating them together. The goal of patterns within the software community is to create a body of literature to help software developers resolve recurring problems encountered throughout all of software development. Patterns help create a shared language for communicating insight and experience about these problems and their solutions. Formally codifying these solutions and their relationships lets us successfully capture the body of knowledge which defines our understanding of good architectures that meet the needs of their users. Forming a common pattern language for conveying the structures and mechanisms of our architectures allows us to intelligibly reason about them. The primary focus is not so much on technology as it is on creating a culture to document(see:http://www.visa2003.com) and support sound engineering architecture and design.

Donald Schön talks about "design-like" professions, where the practitioner is always inventing something (in the small) to advance the situation with the client. A line of code is "no big deal" but it may be unique in the universe! Similarly with how a pianist plays a note, or what a therapist says next. Schön talks about "dialogue with the situation" to emphasise the improvisation needed. Any "designer" could (try to) capture some of their skill in a pattern language. Notice that you still need to improvise when using patterns, but they certainly narrow the scope.

Is there a similarity? Is there a difference?

There is a similarity in that they are supposed to be guides in how to do (or not to do) something. There is a difference in that LittleRules? are practiced by many, if not all effective people almost every day, where is patterns are more complicated global guides that people may wish that they understood and were able to integrate into daily action. I would say people know how to use rules, they do not have similar comfort and knowledge about how to use patterns. Patterns may show you how you get from a to z, while rules get you from a to b. Little rules like "never use a goto" are well known and observed, and the understanding of why the rule exists is known. Also known is that RulesAreSometimesBrokenForGoodReasons?, as in the occasional use of a "goto" by even the most knowledgeable programmer.

I would say that a pattern is a formal method of evaluating and communicating little rules. There have been little rules in software for a long time, but it was often very difficult to communicate them to other people. You just kinda had to learn them on your own. There's a lot of hidden context in a little rule, but the context is explicitly laid out in a pattern.

I agree. Little rules seem to be used daily by individuals and teams, that know the implicit and unwritten context of the rules. Patterns seem to be used to learn, communicate and teach.

This page mirrored in WikiPagesAboutWhatArePatterns as of April 29, 2006