Programmer Makes Excuses, Too!

In our last post (DBA Excuses… and advice to programmers for overcoming them!) we examined some of the bigger excuses used by DBAs to avoid problems and work. But poor excuses are not the exclusive domain of the DBA; far from it! Application developers and programmers rely on their fair share of excuses, too. And if you’re a DBA you’ve probably heard most of them. Let’s break down the top few programmer excuses and see what can be done to avoid them in the future.

The number one programmer excuse is to blame the DBMS.  If you’re a programmer, chances are high that you’ve either said something like the following (or at least thought it): “There’s something wrong with DB2 (or Oracle, or insert your favorite DBMS here)!” The basic mentality is that the DBMS is guilty until proven innocent; the programmer will never run up to the DBA and say “there’s a problem with this horrible code I wrote, can you help me fix it?”

Blaming the DBMS is never a helpful strategy. Oh, yes, in some rare instances there will be a problem or bug in the DBMS itself, but those instances are very rare. Most “database problems” can be tracked back to programming problems. By keeping this in mind at all times everyone will be better off – the problem will get fixed sooner and you will not alienate your DBAs by constantly blaming the DBMS.

Another common excuse is known as the Copied Code Syndrome. As most programmers know, copying working code from one program to another is an efficient way of quickly developing programs. But with database development you have to be careful to make sure that what you copy is really what you need. Here’s how this excuse works: when the programmer is confronted with a problem in his program he simply says “That can’t be a problem because I copied from another program and that program works.”  Well, that may be true, but many things can go wrong with copied SQL. Maybe you copied something that is 95% what you need, but you didn’t modify the code for your purposes. Or maybe something is different about the rest of the code in your program that makes the copied code in effective. Or maybe you aren’t totally sure of what each and every statement and parameter that you copied does?

A corollary to the Copied Code Syndrome is the It worked yesterday excuse. But today is another day, and if it ain’t working today, it ain’t working. Many things can change from day-to-day that can cause working code to become problematic – not the least of which is that code itself. Programmers make so many changes to code as a requirement of their job that sometimes you can just forget that something did indeed change. The bottom line is to work on solutions to problems instead of excuses to deflect blame. Blame is counter-productive to resolving problems.

Yet another excuse bandied about by developers is the Better Mousetrap excuse. The best approach to developing programs using a relational database is to put as much work as possible into the SQL and let the DBMS optimize the access. But there is always that Wile E. Coyote developer who says “But I can do that better in C or Java (or insert your favorite programming language here).” Doing it in SQL puts the work on the DBMS – and there is a much better chance for the DBMS to be bug-free than whatever code you cobble together.

The final programmer excuse I’ll mention today is the Time Is Running Out excuse. This can best be summarized as “There is always time to do it over later, but never enough time to do it right the first time.” Usually this excuse comes to light when you hear that magic phrase “It’s too late in the project to re-write that.”  But the problem caused by the code continues to exist – the programmer just wants some magic to occur to fix it that does not require coding changes. Won’t happen! There is no magic button out there! Sometimes the code has to change to solve the problem.

In the end, the biggest thing you can do as an application programmer is to research and understand any issue before you go running to the DBA.  If your program fails, find the SQLCODE (or SQLSTATE) and any associated reason code and try to fix it yourself first.  If you don’t understand something, read the manual before going to the DBA. There is no reason why everyone shouldn’t have their own set of manuals; most of them can be downloaded for free from the DBMS vendor’s web site.

To conclude, if I had a nickel for every time someone tried to use one of these excuses on me, I’d be a wealthy man. But life does not work that way. So maybe we can all climb back into the trenches and vow to avoid using all of these excuses — both DBAs and programmers… it’ll makes working with your databases a lot easier!

Advertisements

About craig@craigsmullins.com

I'm a strategist, researcher, and consultant with nearly three decades of experience in all facets of database systems development.
This entry was posted in DBA, SQL. Bookmark the permalink.

One Response to Programmer Makes Excuses, Too!

  1. Pingback: DB2 Hub | Programmer Makes Excuses, Too!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s