DBAs, developers keep alibis handy

By Robert Westervelt, News Writer 21 May 2004 | SearchDatabase.com

Digg This!     StumbleUpon     Del.icio.us

Facing mountains of work and left with little time to address small problems, DBAs and programmers often rely on a tired list of alibis, said Craig Mullins, director of technology planning at BMC Software Inc. and a SearchDatabase.com site expert.

He spoke with SearchDatabase.com recently about why DBAs and programmers make excuses to each other, and how they can break the pattern and gain productivity. Starting with DBAs and moving to programmers, Mullins listed the top five favorite lines used by DBAs.

1. It depends.

One of the most common excuses out of a DBA's mouth is: 'It depends.' There is a lot of validity to that statement, but a developer should never let a DBA stop there. A DBA should say what it 'depends' on and figure out what the problem is.

2. RTFM -- Read The 'Friendly' Manual.

Too many people waste time asking questions whose answers can be found in a manual. However, DBAs can take the time to tell inquiring minds where in the manual to start. Companies want a DBA who engages and interacts with different development groups.

For more information DBMS Performance   DBMS Monitoring   Ask the Experts

3. Did you fill out the form?

A lot of times DBAs will ask users to fill out a form for everything. That's so the DBA doesn't have to drop what they are doing. It's good to have the forms, but it's not necessarily good to have a form for every request. Too many forms can harm productivity.

4. I'm busy.

DBAs are usually overworked, but they are not the only ones who are busy. This isn't the right approach. The DBA and the developer both need to understand everyone is busier these days, with more data and more systems going online and fewer resources going into figuring out their problems.

5. Well, IBM says …

This is a line most often heard when DBAs are attending design sessions. The question is, who at IBM said what.

Programmer excuses:

1. Something's wrong with DB2.

Every DBA hears this excuse. A developer won't say something is wrong with the code. Instead, they say something is wrong with DB2 and the DBMS is immediately suspect. Blaming the software without investigating the problem will get you nowhere. Looking at return codes -- and spotting things that have changed -- is the way to find a solution to the problem.

2. But I copied that from another program.

Often the best way to write a program is to copy things that are working in other programs. But developers have to make sure that copying that program is practical and best for the company. For example, a 'select distinct' removes duplicates from the result set, but it is also going to prompt a 'sort' and cause performance problems. If you see something in the code that you copied and don't understand, it shouldn't be in your program. Copying code is a viable way of doing things only if the code is well understood.

3. It worked yesterday.

It's a new day. If it's broke, fix it.

4. Isn't there something YOU can do to make it work.

In this case, the developer is thinking that perhaps there is a parameter that the DBA can tweak or a level switch that can be flipped. But rarely will there be a quick fix.

5. Relational databases stink.

Thirty years ago, relational databases had horrible reputations for poor performance. Now the processors can handle more, and DBMSs have been streamlined so that they are very efficient. A developer has to understand how the DBMS works and understand that, in most cases, problems are caused by the way the program was written.

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary