Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Two Scenarios
The following two experiences illustrate how the quality of a database can make or break an application.
A Success
During one consulting engagement, I met with a small group of developers to review their design for an application, and to verify that their development practices were sound.
The developers began the review by explaining the motivation and requirements for the application. The firm was a service business, and they were wary of being overtaken by competitors if they did not add capabilities. The developers thoroughly modeled their application, and carried it forward into the database design. Their model was sound, and their database design was solid. It was apparent that management had assembled a team of skilled developers who understood modeling and databases well.
The end result was that their application ran well. It was flexible, extensible, and fast. They had a modest number of bugs, and met their scheduled delivery dates. The successful application helped maintain the company's business position and keep competitors at bay.
A Failure
Another time, a client asked me to evaluate a product sold by a prominent Fortune 500 company. The vendor had a great market vision, and the product supposedly had many impressive features. The vendor understood the business requirements well, and my client was enthusiastic.
The first hint of a problem came during installation. The documentation was confusing, and it took my client's support staff several weeks to install the product—only to find that it was buggy and slow. An experienced developer attended their training course and found it confusing. I decided to reverse-engineer the database to understand the product better.
I was surprised to find that the database was poorly designed. Even though the vendor was a large credible company and understood the requirements well, the database was mishandled. It looked as if it were designed by a programmer who was new to databases. In later discussions, the vendor confirmed my suspicions. It never occurred to anyone that database design was difficult, and that a bad design could cause so much trouble. It was no wonder that the software ran slowly and was confusing. My client rejected the product.The upshot is that the vendor wasted several million dollars in developing and marketing a flawed product. This could have been readily avoided by carefully developing the database. A few months of time from a talented database designer could have saved them much rework, increased the quality of their product, and boosted sales. The product was temporarily withdrawn from the market, fixed, and is now being sold again.
Remainder of the Article
The remainder of this article discusses inputs to and outputs from development. You can prepare the outputs from the inputs by following a well-defined process that is a series of stages. Even though our presentation is necessarily linear, all portions of an application development need not progress in a serial, lock-step manner; several other development lifecycles are also possible.