Software: The Dildo Design Pattern

You will find this design pattern in Knuth and K&R. This is because it’s not specific to the underlying design pattern, but how its applied. A team will take an advanced tool or some architectural guidance, and use it to vigorously fuck themselves right up the pooper. This is because they assume they can implement something complicated, for free, without any of that complicated book-learnin’. There ain’t no fucking freebies. First law.

Never Picked Up a Book

There will be a solution to a problem. The solution is probably a little complex – it will require a rough understanding of the problem. Noobs don’t understand — they just see that solution exists, and that is “best practice”. The inevitable fail then goes down in one of two ways:

They will create their own version of a “best-practice solution”. They will do this without understanding the problem or how the solution relates to the problem. They will then end up fucking themselves by creating yet another shitty code-generated data layer that doesn’t support the concept of a unit of work or relationships.

Either that or they will use a “best-practice solution” to a problem they don’t have. They will take on all the disadvantages of a solution without any of the benefits, or even any knowledge of what the benefits should be. I’ve seen whole websites implemented using a Web-Part-per-page model, without using any of the features of Parts – just using the disadvantages.

16 Layers of Abstraction, Look!

There must be some fuzzy feeling, or herd mentality, in applying the same solutions as everyone else. We see this kind of crap fairly often in people discussing Google level scalability regarding their shitty Rails app — which on an unusual day may have to deal with two simultaneous requests…

Advertisements