Developers and Databases
Databases provide enormous challenges for developers in both the technical and customer-relationship spheres. On the one hand, they have to know a great deal about coding, security, compatibility with other systems and other issues involved with databases and their applications. On the other, they have to know how to deal with customers — very, very fickle and uninformed customers.
In fact, the latter is often more difficult than the former, largely because the people who are calling the shots really don’t know anything about databases or technology in general, for that matter. “In terms of getting database applications and stuff up and running, it’s generally a labor-intensive process,” said Josh Berkus, one of a group of core developers for PostgreSQL database technologies. “In 10 years of database consulting, I have yet to run into a business that had clear specifications for database applications. Database applications tend to be controlled by the executive management of the company, simply because the database tends to be central to the business, but the executives are not computer people, or engineers or architects of any kind. As a result, they generally don’t understand the concept that — when presented with the choice of doing it this way or that way — they have to choose it one way or the other, and not trying one way a little bit just to see how it feels. I’ve gotten that. I actually had one executive tell me that in the morning we’d be doing it this way, and in the afternoon we’d do it that way.”
Because of this indecision, the building and installing processes around major databases and their applications tend to be three to four times over schedule and at least twice over budget, he added. “That’s simply because there’s this enormous amount of spec drift. You can compare it to physical construction: Building a major database application or installing a major vendor database application that has a lot of options is very similar to doing government construction. You’ve got a hundred people on committees, any of whom can give you change orders and none of whom are responsible for results. That’s really not different, from open-source applications to (Microsoft’s) SQL Server. It’s still more a matter of business and dealing with the executive staff of a client, rather than the technical details of the system you’re using.”
So what are developers to do in seemingly impossible situations like this? Well, there are some ways to navigate the difficult passes of database development for corporate clients. First of all, it’s essential to establish a certain course of action between you and the customer, get that on a printed document that’s signed by all parties, and follow it to the letter. If alterations are made during the development or implementation stages, it’s understood that those modifications constitute a change order, which will require additional time, money and resources.
“The most important thing is for you to be consistent as a developer and for you to make sure that everything gets done in writing,” Berkus said. “That’s because you know the people you’re dealing with are going to be all over the map and are not going to follow their own procedures or stand by their own decisions. That means you have to be super correct in what you do. I think that a lot of the flailing you see around major databases and their applications is because there are still a lot of IT managers and consultants who haven’t picked that up yet in terms of taking that detailed and plan-oriented approach.”
A corollary of instituting a precise arrangement is making sure the language you’re using to describe what you’ll be doing clearly expresses that to people who don’t know much about the technical side of databases. “The basic end-user education issue is that people do not think like computers,” Berkus explained. “As a developer who works with clients or your own management, you have to be a linguistic and cultural interpreter. Human beings think in terms of fuzzy logic. Computers do not. It’s up to you to say, ‘You have to give me a set of rules that is absolute. If you can give me rules that are absolute, then I can implement it. You can’t give me a set of rules that says, ‘Well, sometimes this goes in the red bucket, but if we’re feeling sad that day, it goes in the blue bucket. Or maybe we’ll have a committee meeting about it. I’m not sure.’ That’s the sort of thing that computers can’t handle.”
Thus, database developers should aim to have a three-legged stool of overall knowledge and skills: The first is an understanding of programming and coding, the second is familiarity with the set theory found in relational databases, and the third is the ability to communicate with the “suits” who you’re designing the database for. “While the executives feel perfectly free to not have any understanding of computers or databases, you have to have some understanding of how they think,” Berkus said.