Design by Defect

Posted by attriel September 2nd, 2008

Imagine if you will.  A room with 4 people for a meeting.  Two of them are coders.  Developers.  It’s a design meeting.  Lets call them A and N.  The other two people we’ll call D and C.  Because that way the letters are nice and random ;)

The meeting is talking about the design and design decisions behind a new content framework for a series of sites.  Rather than investing in a CMS that might do most of what they want badly, the customer has asked for a custom built deal to perform the functions they need well.  (OK, that’s a bit of a stretch.  Group S convinced the customer that this was the best way to do it, but the customer isn’t necessarily convinced they need anything more than their current “bob edits the HTML files for us” system).  A has just been invited to the meeting, apparently related meetings have been going on for months.

N, the other developer, has a system he worked on previously that he feels can be easily retooled to provide CMS functionality without having to start from scratch.  Reusability of code, cool.  Reusability of code from another client while working for a different company, questionable.  Reusability of an inventory tracker as a CMS framework … uh … When you have to start wedging site design ideas around the existing code so you don’t have to rewrite it … 

D is a manager.  His major contribution to the meeting was fairly benign.  Basically, anytime N asked a question about how this or that should work, D deferred to C or sent the question back to N.  He also nailed the manager ability to agree with everyone in the room, even when they disagree with each other.

C is an idea man.  He generates ideas, mockups, etc.  He doesn’t work on the code, directly.  During the meeting he shoots down multiple design choices due to the customers being, effectively, retarded imbeciles.  

So, during this multi-hour meeting, you have A making repeated comments and suggestions based on a total lack of background.  N making choices and declarations based on how the sites can best be modeled as inventory.  And C firing down ideas due to customer incompetence.  N and C both keep making suggestions based on, effectively, retaining the current system and model.  Which is Bob edits html files by hand on the server.  D’s major contribution is repeated use of statements like “outside the system”, and then wanting these tasks that exist outside the system to be triggered or to effect a change in the system.  Without them being connected.  Every user role that comes up is “Well, that would be Bob”, the only example in every mockup is a section that, within the first 20 minutes, is written off as not-exemplary of the rest of the system. 

In the end, it’s a poorly implemented system based on a defective design, intended to minimally meet abysmal requirements for a product that the customer isn’t even sure they want.  What could POSSIBLY go wrong?

Comments are closed.