Choose your inheritance carefully

Posted by on Sep 9, 2010 in Culture, News & commentary | 0 comments

Have you ever tried to drive around Boston?  It’s nearly impossible to navigate the narrow, winding streets that meet at odd angles, curve back around, and join in traffic circles that you find almost nowhere else in the country.  Why would any city knowingly design its streets in a fashion nearly impossible to navigate?  Well, there’s an old story, perhaps apocryphal, that the streets follow the old cow paths from the days when the Boston Commons was a cow pasture hundreds of years ago.  

If you’re tempted to laugh at Boston, take a step back and first look in the mirror and ask yourself if you’ve designed anything like that.  Too often, technology projects do exactly the same thing.  They build systems that strain to look like something else.  One of the first PC based word processors, MultiMate, was specifically designed to look like an even older Wang word processor, as if that were something worth emulating.

These types of designs typically result from several different sources:

Backward compatible technology.  One of the most common sources is trying to make something new that retains its ability to support previous standards.  You’ve got to balance the need to retain backward compatibility with the complexity of designing, developing, and supporting something that may no longer be in general use.

Minimizing user education.  Another common reason for building new systems that look like old ones is to minimize user education.  I suppose that the reason that MultiMate was so popular during the early days of PCs, was not that it was particularly functional, but that typists who had already learned the Wang interface wouldn’t have to relearn a new one to switch to the less expensive PC environment.

Taking requirements vs. building consensus about what should be done.  But perhaps the most common source is that too many IT Professionals try to “gather requirements” at the beginning of projects.  They make it sound like user requirements grow in strawberry patches and just need to be harvested in order to learn what users need.  Unfortunately, users rarely know exactly what they need.  More often, there are many different ideas floating around about what’s needed.  But I’ve never seen anyone actually just go out, ask a few questions and successfully deliver a system.  You’ve got to see the early phases of projects as a process of building consensus within the user and client community about the goals and needs for a new system.

Sometimes it’s necessary to build a system with vestiges of previous ones, but it’s much too easy to just assume that you’ve got to do it.  It’s too simple to assume that business operations and users will always do things the way that they do now.  Before you build them into new systems, make a conscious decision that it’ worth it.  Are you building something that will truly serve the needs of your clients and users or are you laying out the street map of the next Boston?

For more information about how you can leverage geeks to get the technology you want, contact or call 310-694-0450.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.