Wed 22 Oct 2008
On every project, there is a phase where you have to pick the essential technologies that you will use to build the system. You need to decide what programming language to use. Is there an available framework? Does the system need a database? If so, which DBMS should you use?
Ideally, this is done logically and methodically, making sure to choose the technologies that best meet the stated needs and provide for a future growth path. Like most human activities though, this process is often subverted by the foibles of those involved.
Here are a number of Design Fail Patterns, ways that bad designs get chosen.
“To A Man with a Hammer, Everything Looks Like a Nail.” – Mark Twain
Sometimes a team makes an ill choice because of their background. There are more technologies available than ever before (see Software’s Cambrian Explosion). It is impossible to stay on top of every language, framework, and system. You do have to make a choice from the set of technologies you are familiar with or ones you know to explore.
Sometimes the right choice is the tool you have expertise with, even if another is more capable. Predictability is a key factor in the success of a project. Many projects don’t afford the time necessary to learn and master a new technology. So, success depends on doing the best with the tools at hand.
However, I have seen familiarity promote technologies way past their utility. I worked on a real-time communications system a few years ago. The architect on this project was a former Database Administrator. While he was a first-rate DBA, he knew little of object-oriented design or the design of large, complex systems. His design reflected his knowledge. Consequently, the system was designed as a transactional database with a thin veneer of objects to interact with the user and other systems.
I’ve also seen this work the other way. On another project we were building a system to manage patient records. While this was obviously a database project, the team treated this primarily as an object-oriented system, using the database merely to serialize their objects. All permissions, synchronization, and look-up took place in the object layer. To do that, they loaded all of the objects into memory when the system started up, with predictably poor results.
Every system we build has an essence that defines the nature and purpose of the system. For each, there are always technologies that are better or worse suited to that essence. It is very important to look past your familiarity and find the ones that best meet that need.
Design by Resume
Sometimes a team makes a bad choice because of a technology they want to work with. For a technical field, software development is full of fads and fashions. At any moment in time there is some hot, new technology that is supposed to render all others obsolete, and developers clamor to gain experience in these systems.
One such technology was Enterprise Java Beans (EJBs). A few years ago, the media was abuzz with articles extolling the virtues of this almost magical technology. I can hear the voice of Billy Mays now, “Try EJBs, the distributed data solution that removes stains and whitens your teeth.”
For several years, every Java project I worked on desperately tried to find a way to use EJBs. Developers who had never actually used EJBs fell all over each other trying to wedge them into the design. Ultimately, none of the systems I worked on found a good use for them.
Sometimes that hot, new technology will be the right fit. Just be sure you are picking it because it is the right tool and not because you want that experience on your resume.
Design by Magazine Article
There is an entire ecosystem in software engineering that exists just to tell you how glorious new technologies are. That used to be the domain of trade magazines—you know the ones, the large newspaper looking things that are always lying around the break room. Now, websites have taken over as the number one source of telling you what you should be using. Seminars and conferences are another source for this.
Regardless of the source, Design by Magazine Article occurs when the technology direction is chosen because of one of these experts telling you how to do things. This differs from Design by Resume principally in motivation. Design by Resume comes from the desire of the developers to expand their experience. Design by Magazine Article occurs when engineers put too much faith in the so-called experts. Often this occurs in management circles, like when a CTO has time to kill on a long flight in first class.
And this leads us to our final Design Failure Pattern…
Design by Management Fiat
This may be the worst of them all, and certainly is one of the most common. In this situation, upper management decides what tools and technologies will be used. Often this comes as an effort to standardize on a tool set, like when a company decides it’s a Microsoft shop or Java shop. Sometimes it is driven by cost, like when companies standardize on tools like Eclipse.
This pattern is wrong on many levels. First it robs the team of their sense of buy-in. This is an essential element in a team that is functioning at its highest level. Second, no tool or technology is right for every situation. I’ve used both SQL Server and Oracle. In many cases either will do just fine. In some cases, SQL Server is a clear win for its simplicity and lower cost. But sometimes you need the capabilities that only Oracle can give you.
Finally, this pattern is bad because the policy is written in stone. No matter how effective some other solution might be, once management has made up their minds they will not be swayed, at least not until the next hot-shot CTO comes in and talks them into the latest set of must-have technologies.
Friends, let me share with you the one sure thing I’ve learned about technology: it is hard. You are faced with innumerable decisions about which way to go. While there are no roads to guaranteed success, there are many roads to guaranteed failure. You need to keep your options open and make the best choices you can.