Here is a link to my SOLID MVC in Perl presentation slides, and here is a link to the Perl sources used. I’ll post the recording here as soon as it’s available.

Photo by Robert Lukeman via Unsplash.

Dan North gave a presentation a few years ago about some of the decisions a software architect or a developer might make.

At 46:50 he begins to talk about the DRY principle (“Don’t Repeat Yourself”). He makes it clear that he’s a fan of the Pragmatic Programmer, but this section of his talk is a warning about following one principle (DRY) without giving consideration to other competing principles. In this case, the opposite of DRY code is decoupled code, another desirable goal.

I’m trying to understand premature generalization. First, why is premature generalization a problem? Dave Smith:

One result of premature commitment to a generalization is that you’re supporting code that isn’t used. I’ve joined projects and found that 1/3rd of the code base wasn’t reachable, all because one or more programmers had tried to write class libraries that would solve all possible future needs. It is really, really tempting to give in to the misplaced belief that “… as long as I’m here, I might as well add the other methods that people might need at some point.”

Martin Fowler on the will to design:

In order to work, evolutionary design needs a force that drives it to converge. This force can only come from people—somebody on the team has to have the determination to ensure that the design quality stays high.

This will does not have to come from everyone (although it’s nice if it does), usually just one or two people on the team take on the responsibility of keeping the design whole. This is one of the tasks that usually falls under the term ‘architect’.