Principles

I'm pulling this discussion over from some comments on Ayende's blog because I think it deserves more thought.

So I said:

However... it's been my observation that architecture patterns are much more likely to be embraced when:

1. They can explained in a few sentences without resorting to jargon like separation of concerns, single responsibility principle, decoupling, unit testing, and SmallTalk. ;-)

2. The average developer has a multitude of examples to learn from.

3. In addition to being highly recommended, the architecture is perceived as "the right way" or "the natural way" to use a given platform. This essentially means getting first mover advantage and uniform acceptance when a new platform is released. Consequently most of the ability to dictate these things is in the hands of the platform vendor.

To which Steve replied:

1. Those principles you speak of as jargon are the core concepts of what patterns are about. I feel the reverse of your statement: understanding those concepts should come FIRST before even attempting to understand a pattern. I think you have the cart before the horse.

To me the average developer should be trained similiar to how electricians are - they study under master electricians and learn the trade. These concepts such as #1 would be taught first.

(Note: We're in agreement insofar as various MVC styles are concerned.)

I agree it would be better if these concepts were understood first... but unfortunately that's not the case today. In truth, I don't expect it ever to be the case. Not everyone was born to be a master electrician: most people just run extension cords around the house. I imagine after a few years on the job many electricians won't remember much more from their training than how to run wires from source to switch to plug and a few rules of thumb for estimating capacity for large appliances. Much of this is codified in building codes anyways. So if there is a shortage of discipline and deep understanding of core principles, what can you do?

• Improve the quality of education. (When? How? For whom? With what resources?)
• Raise the minimum threshold of acceptability for admission into the professional trade. (Who's the guildmaster for Software Engineering?)
• Make foolproof tools that provide on the job training. (Hotwire the keyboard to 220V AC, that'll teach 'em to ignore compiler warnings! Ha Ha Ha!)
• Provide better examples and just hope nothing really bad happens.

I fear that the latter is really the best solution. Somehow best practices must be demonstrated in actual practice so that practicing practitioners can practice these practices. *ducks*

But really... Screwed up software design doesn't usually deliver clear, direct and timely feedback. Unless you've got a very strong design team and peer review everything, most problems only show up in hindsight. That's fine for throwaway code and most internal tools but it can be costly when you plan to maintain and extend a large product over decades.

Ensuring that all new programmers receive a firm grounding in software design principles (and sufficient practice to keep their skills fresh) is probably prohibitive. Therefore I believe the most effective approach is simply to flood the networks with coherent examples, standards and documentation that don't necessarily require -- but promote -- deep understanding to adapt and adopt.