views:

122

answers:

1

It doesn't seem that this exact question has been asked before, so I'll fire away:

Most of us are familiar with the concept of an anti-pattern. However, avoiding implementation of anti-patterns can in principle swing too far the other way and cause problems itself. As an example, "Design by Committee" has a counter-example that I'd call "Design by Maverick" - wherein the design of an important feature is handed off to an individual to do what they think best, with the intention of reviewing their work later and deciding whether it should be finalised or go through another iteration. This takes much longer in practice as the rest of the team are occupied by other things, and can end up with a feature that's useful to nobody, particularly if the Maverick is not themselves an experienced end-user.

Does anyone have any more examples of anti-pattern counter-examples?

A: 

I see the problem in anti-patterns themselves. It is easy to point out wrong solutions, but it is harder to come up with good ones. Almost always the quality of solution depends on the context, so sometime even anti-pattern when implemented good can be used more than other solutions. So the space for solutions or patterns in general is quite inexhaustable and we have to decide which ones should be looked at. Wrong solutions or good soltions? I guess looking at bad solutions and knowing that they are bad is not as useful as looking at the good ones, because out of good ones (regular patterns) you can get also good principles which were used when comming up with that solution (as with OO design principles in GoF design patterns book). As to your exact example, I heard somewhere about "Benevolent Dictator" and some sort of democracy (with own name) which was adjusted by adding more votes to certain people depending on different priorities of the project.

Gabriel Ščerbák