Avoiding the Top-Ten Design Mistakes

Visual Studio Enterprise

Avoiding the
Top-Ten Design Mistakes

Building scalable enterprise solutions

Visual Studio Enteprise

Avoiding the Top-Ten Design Mistakes

Understanding the problem…

When the smoke has cleared after a battle, the generals usually get together to smoke their cigars and the careers of those underlings who didn't meet muster in the thick of things. Client/Server systems project reviews are often done the same way. When the project is finally wrapped up and delivered, the managers get together to decide what went wrong, what went right, who to promote and who to blame. All too often, in my experience, the tools and developers are assigned a significant part of the blame and the architects and systems analysts are given most of the medals. Rightly or wrongly, I have found that many designs are flawed long before the first line of code is written—even though the developers who work in the trenches often contribute to the fallibility of the designers. With apologies to David Letterman, I would like to propose the following top ten reasons for systems (especially client/server systems) not meeting expectations:

Recognizing the pitfalls…

1) The design did not deliver what the customer wanted. In many cases, this is because the customer did not know what they wanted until you didn't give it to them. In other words, they knew what they didn't want, but they did not have a really firm grip on what they did want. Generally, this is the result of an implementation without a specification. When one creates a specification, one has to study what needs to be done—and come to an understanding about the end result. The designer and the customer must come to a common understanding about what the end-result will look like. Take Noah for example. If Noah did not know what a cubit was, his design could have forced the project over the allotted time—and where would we be if he was still wrangling with his gopher-wood supplier when the rains started?

2) The architect or analyst that designed the system knew how to lay bricks but not use a hammer—so you seemed to end up with a lot of brick out-houses. Invariably people build what they know how to build, using the tools they are comfortable with. If they are experts at ISAM designs, they think about ISAM solutions to the problems at hand; even if they don't always work very well. The customer has no way of knowing what the best implementation would be, and perhaps management doesn't know either. Sometimes a better understanding of the alternatives is in order before charging off to implement using old or inadequate concepts. Too many times we have seem complaints that Visual Basic or Access or whatever was seemingly incapable of building a cursor against a giant table, when the real problem was lack of a complete understanding of how a multi-user client/system is designed in the first place. For the most part, client/server applications that support dozens to dozens of dozens of users don't build SELECT * cursors on base tables—they use stored procedures, views or server-side intelligent objects to return information—not just rows.

3) The design assumed that since the application worked for 5 users it would work for 50 or 500 or 5000. A corollary to this problem is: "since the application worked with 500 users on the test network, it would work on the live corporate network". Too often we see designs that don't account for the volume of traffic generated by their application and all of the applications that use the same design taken as a whole. In today's world of 500K email messages broadcast throughout the net to announce the birth of the new group administrator's son, network bandwidth is already pretty much taxed to the limit. Scalability of any application depends on the quantity of resources consumed by each individual application. This includes workstation resources but also must include network packets sent and received, round-trips to the server, and resources on the server. If a single application creates a 40MB TempDB sorted result set, how is the system going to support 50 or 500 instances of the same application—each consuming server resources like teenagers at the jar of M&Ms?

4) The developer forgot the oldest maxim of all: "Stuff happens". In a robust C/S application, much of your code should be there to deal with the errors (and messages) returned from the server or the OS running the application. Not only should the application deal with all of these errors, it should do so from the beginning when the developer best understands where the problems can best be trapped and addressed. All too often one assumes that the network or the available resources will be there and just as readily available as they are when the application is written.

5) The design called for mustard on the buns, so mustard was added to the bread recipe. We have seen a migration from fairly simplistic two-tier client/server applications that baked many of the business rules and field edits into the application instead of putting them on the breakfast table where all of the developers could reach them as needed. While this does not seem to have much of an impact when you write the first application, and perhaps not when you write the second, by the time you get to the fourth or fourteenth, you can really see the problem arise. Each time business rule code is included into an application, you risk having to go back and change each and every application when the rules change. For those shops where the business rules never change, you can disregard this problem.

6) The design didn't account for everyone wanting to use the same clerk. Imagine a fast-food restaurant designed to deal with dozens of people at once, but with only one cash register that all of the teenagers behind the counter have to share. This same problem is often duplicated in client/server designs when insert/update activity is focused on the pages containing the most current rows. This is the "hot-spot" problem many of us have seen. Unless you deal with this problem by adding a few more clerks, your system is destined to bog down as individual applications vie for the most often used pages. Generally, the easiest way to deal with this situation is to change the data indexing scheme to make sure new rows are added to different pages in the database. That way, when the page is locked by someone down the counter ordering a full-meal-deal, another operation can complete without having to wait.

7) The design didn't account for that kid in the back room who used a pair of binoculars to watch the cook open the combination lock on the pantry. Security is a prime concern where I work and it should be concern for your designer as well. Since Visual Basic and all the rest have made client/server data access so simple, the ability of a well-meaning bungler to get access to the corporate cookies and stomp all over the data is all too easy—especially when the User-Id and Password you assign is granted permission to access the base database tables. By building stored procedures (or server-side ActiveX objects) to gate access to the data, you prevent the kids from wandering through the pantry fingering the goodies. This design also gives you a way to implement business rules on the server and simplify application design and dissemination. Since the SPs can change without the applications having to be re-compiled, you can make some pretty significant changes without having to change a single installed application.

8) The design called for colorful ad copy to be delivered to the customer and instead of including it in the Sunday paper, it was printed in full color on each loaf of bread. I, for one, am not a fan of putting Binary Large Objects (BLOBs) in the database. While it is possible to do so, I have not seen many cases where this has worked out. Yes, I have seen a case where the alternative was tried and was ultimately rejected, but in many, many cases I have seen abysmal performance turned around overnight by simply leaving the photos, documents and other BLOBs in the original source files, and putting a pointer to the file in the database.

9) The design failed to account for tornadoes. Data backup and restore regimen must be part of any workable C/S design. When it is not, it is just a matter of time before you are faced with an angry mob wanting to get at their data. There are few problems that are more job threatening than not having an adequate backup and restore strategy. Be sure it works too. In many cases you might not be able to restore a single table or even restore at all if you don't have the proper utilities and procedures in place.

10) The design called for the bread to be re-warmed in a toaster-oven (because that's what we know how to do)—even when the customer uses a microwave oven. The NIH (not invented here) problem has hamstrung companies large and small since the dawn of time. How could someone else's solution be as good as one we make right here in River City? More often than not decisions are made based on tradition and comfort level as opposed to what works best for the situation. While this is a valid concern, it must be tempered with the realities of future viability and support. In many cases the decision to buy or make has had more to do with people skills than technical merits. That is, if you have a shop full of COBOL programmers and you need to implement a PC solution, and you can't leverage the existing code, you can either re-train the staff and start from scratch or buy an outside solution and have your staff sit on their 80 column cards—neither is particularly easy to do. Companies that don't make these tough decisions die or are absorbed sooner or later.