Follow Project Patterns

Projects establish patterns, or ways of doing things. Patterns are made in implementation (ie, code or interface) and design (ie, choices made that led to those implementations).

I'm talking little-p patterns generally, not Gang of Four Patterns or anything like them.

Projects without patterns are messes, without form to organize the chaos. Patterns are useful. As programmers, our jobs are often to recognize and use patterns. Here are three jobs we have in regard to patterns at different points in a project.

Start project

When you start a project, it's your job to establish the patterns.

• The patterns don't exist yet. You get to make choices, sometimes hard ones, whose effects will be felt well into the future.
• Be clear about the design principles you are optimizing for. Document them so that they are clear and can be shared.
• As you learn, which you do a lot of at the beginning of a project, be sure to keep your pattern clean and consolidate variation.

Join project

When you join a project, it's your job to learn the patterns.

• You come to this new project with patterns you already know from before.
• You could implement previously-known patterns immediately. It'd be easy do. They worked so well last time.
• But this is a new time. The previously-known pattern may fit well in this project, or it may not.
• First learn this project's existing pattern well. Become adept with it, like it or not.
• Then you'll know whether the existing pattern should be destroyed, adjusted or followed, according to the design principles of the project.
• Seek to know why it exists, what it accomplishes, what its design principles were, how it's integrated in the project. This will help you count the cost of existing investment and benefit of potential adjustment.
• It is very challenging to gain the perspective that led to patterns. Patterns are the product of many, many experiences, influencing factors, tradeoffs and decisions over time.

Every day

When you're on a project, it's your job to follow and improve the patterns.

• If we're doing it right, we're always learning. With new knowledge comes the temptation will be to implement a new pattern.
• If you change a pattern, it's your job to do a complete migration of existing code to the new pattern.
• Sometimes that kind of change is well worth it, but sometimes the net cost/benefit is unclear
• Two patterns to accomplish the same thing is just extra cost. It's duplicative work to understand, read and maintain.
• But there is room for multiple patterns when those patterns provide something new and needful.
• But there's probably overlap, so the cost of duplication, to a degree is still there. Use caution. Don't pay the price flippantly.

All projects die. It's just a question of when. A lack of clear patterns or a duplicative collection of patterns in a project will make it die faster.