The art of developing an application, or maintaining a database server, really consists of finding ways of postponing or avoiding programming. As Phil Factor points out, most good DBAs and developers are marked out by a propensity for "bone-headed stubbornness and practice beyond the patience of an ordinary mortal". It's only when this attitude blinds a person to an easier way to do things that it becomes an issue.

The problem is that the whole Microsoft culture is one that positively encourages immediate coding. It all seems so easy and satisfying to cut down on the tedium of routine administrative tasks by scripting them. It is hardly surprising really, since by leaping naturally to the use of scripting or, god forbid, programming, you never need to stand back and consider those difficult initial questions like "Should I really be doing this?" or "Is there a more effective approach?" One thing leads to another and before you can wake up to the futility of what you are doing, you have thousands of DTS scripts, or directories full of un-maintainable Perl scripts, written in some bizarre form of shorthand by someone who left the company before documenting it all. And then you find out that there was an existing tool that did the same job. Only better.

In any enterprise there is, or should be, an exercise which must be gone through before you even consider building an application. You have to find answers to the following questions before you get asked them:

• Should we be doing this at all?
• Have we already got the means of doing this?
• Can we modify an existing component to do this?
• Can we buy-in an existing product or tool to do this?
• Should we get someone else to produce it for us?

Only when the answer to all of the above is "no", when all other ways of developing the application have proved futile, should you consider "rolling your own".

Even when the decision is made to build the application, you should reuse whatever components you can, and code only when you can't avoid it. When you are refining a prototype, you'll use scripting just to allow you to make rapid changes, before finally casting the application in concrete with a compiled language. Coding in C#, Java or the like should, in almost every case, be just about the last thing you should do.

As always, we'd love to hear what you think. And as usual, the best contribution to the debate, added as a comment to this blog, will receive a $50 Amazon voucher.

Cheers!

Tony.