The place for nonprofits, charities, and libraries

What mistakes have you made when selecting a database or other technology?

What mistakes have you made when selecting a database or other technology?

  • In Idealware's article Ten Common Mistakes in Selecting Donor Databases, fundraising technology strategist Robert Weiner addresses ten common mistakes that can prevent you from selecting the right database and managing it effectively.

    Whether it was wishful budgeting or falling in love with the salesperson, have you made any of the mistakes Weiner identifies, either in selecting a database or when choosing another technology? Help others learn from your experiences by sharing them here.
    senior editor, TechSoup
  • I would add to this that a company may want to hire an independent technology expert to help make the decision. I've witnessed on many accounts non-technology people making technology decisions that don't serve the organization.

    Often a third-party technology person will avoid several of the items listed, for example, falling in love with the salesman.

    A third party techology person will know the current network technology of the organization and can differentiate between the different database products that are being presented.

    I've served in this capacity on a volunteer basis for a local company and believe that I chose the software program they were initially interested. Having a third party confirm their decision helped them feel good about the decision and reinforced the commitment to the software from management and the IT department.

    Lou Storiale Storiale Consulting Group, Inc.

  • Where does one find an independent technology expert? My org is in the midst of this situation, and an impartial voice would be very valuable.
  • Failure to "Reverse Engineer" the database

    Non-technical managers MUST educate themselves on the essentials of database-centric systems. As a starting point, I suggest my mentor's book on the topic: A Manager's Guide to Database Technology: Building and Purchasing Better Applications by Michael R. Blaha

    Databases can't hide. They're fundamentally "open" technology, and can't "black out" their quality (or otherwise) from a skilled pratitioner. With suitable tools and practitioner expertise, purchasers owe it to themselves to obtain an independent assessment of the system caliber, before investing precious money and time into doomed products.

    The technique of "reverse engineering" offers such a method. I've distinguished excellent and inferior software by examining the underlying database structure. I look at table names. Index coverage. Relationships. Constraints. Coherence, and consistency, and componentization. I use experience to imagine how a skilled developer would use each database construct to provide each screen, each report and each data-extract capability. Some database structures make it *really* easy to build nearly any imaginable feature. Frequently, I've found technically inferior database structure and content in supposedly "big-name" products. After many years and many evaluations, it's inescapable:

    Ugly database structures always product ugly apps. Buildings are no stronger than their foundation. Databases are the essential foundation on which all apps depend. Fund-raising database apps are the life-blood of not-for-profit organizations. When donor databases are fragile, error prone, difficult to use, teach, learn and extend, the programmers have hopeless challenges to surmount, and software quality suffers.

    Sadly, the overall caliber of software practice is frighteningly low. Most programmers are highly-paid amateurs. (Consider that your 747's control systems were probably developed by somebody with no more computer training than yourself, just some self-taught experiements and a few copies of "Programming for Dummies" and "Teach yourself Technology in 21 days.") Most database structures are pretty bad. Database programmers frequently have little (or no) training or skill developing proper database structures, implementing those strutures, and exploiting those structures. These inferior practitioners create database structures doomed to fail. Features are difficult to extend. Screens are difficult to use, slow to navigate, and frequently under-accurate.

    Anyone can buy the tools. Anyone can read the names of tables and columns and relationships. Anyone can see the consistence (or otherwise) and get the general ideas that "The Whole Thing Hangs Together", or "It looks like a dog's breakfast of different techniques, different styles and general sloppiness." The more subtle refinements require training and experience to really understand; that's why one spends the up-front time and money to get informed before committing one's organization to a huge investment on which the entire organization's long-term future is dependent.