Avoiding the
Top-Ten Design Mistakes
Building scalable enterprise solutions
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.
分享到:
相关推荐
"obstacle-avoiding-arduino-code" 提供了一种实现这一功能的解决方案。这个项目旨在帮助你的arduino机器人通过传感器检测到前方的障碍物,并采取相应的行动避免碰撞。 1. **Arduino基础知识**:Arduino是一种开源...
Avoiding conditionals by obeying the Liskov Substitution Principle Making targeted improvements by reducing Code Smells Improving changeability with polymorphism Manufacturing role-playing objects ...
C++ Gotchas Avoiding Common Problems in Coding and Design 英文epub 本资源转载自网络,如有侵权,请联系上传者或csdn删除 本资源转载自网络,如有侵权,请联系上传者或csdn删除
1Avoiding AVX-SSE Transition PenaltiesTransitioning between 256-bit Intel:registered: AVX instructions and legacy Intel:registered: SSE instructions within a program may cause performance penalties ...
Widely lauded for avoiding the typical black box approach found in other operating system textbooks, the first edition of this bestselling book taught readers how an operating system works and ...
of the period that is used for calculating the percentiles (base period). This would make these exceedance frequency time series unsuitable for monitoring and detecting climate change. The problem ...
OSPF Backbone Design in the Hierarchical Model 173 Area Design in the Hierarchical Model 174 Using a Stub Area 175 Example of an OSPF Network with a Hierarchical Structure 177 Step 3: Determine the ...
在IT领域,尤其是在数据存储与保护的技术探讨中,《Avoiding the Disk Bottleneck in the Data Domain Deduplication File System》一文提供了深入的见解和技术解决方案,旨在优化基于磁盘的重复数据删除...
Design patterns were created as a bible for avoiding problems related to software design. Doesn’t that make it a true ninja’s handbook? Table of Contents Creational patterns Abstract Factory ...
Separating model and view, and avoiding common mistakes Mastering strategies and patterns for efficient, flexible design Ensuring predictable object collaboration via responsibility-driven design ...
features on a map avoiding overlaps to improve map visualization. This paper presents a Clustering Search (CS) metaheuristic as a new alternative to solve the PFCLP problem. Computational experiments ...
You’ll learn to develop reliable code that’s speed and memory efficient, while avoiding the infamous and arcane programming pitfalls common at the systems level. When you need to dive down into ...
By the end of this book, you will have acquired the skills to craft applications that are built as small standard units, using all the proven best practices and avoiding the usual traps. Also, this ...
This code is made simple and easy to understand by avoiding complex book-keeping schemes, while maintaining the essential features of the method Python was chosen as the example language because it is...
You will learn about some of the relevant design patterns (and their application) that are most widely used. We start with classic object-oriented programming (OOP) techniques, evaluate parallel ...
Although I wrote the first edition of this book more than 25 years ago, my goals for it remain the same. I want students to receive a solid intro- duction to the traditional topics. I want readers to ...