Imagine if you will, a construction company stating that a building design is flawed and the whole thing will probably collapse under it's own weight, but they go ahead for approval anyway. Alternatively, a defense lawyer saying her case has holes, but she hopes her client does not get the electric chair before she clears them up.

As should be obvious to you, those actions would be inexcusable and dangerous, however, this is almost always the approach taken when it comes to Software and Systems Development.

The bottom line is, most problems a System Administrator finds himself toiling with are not problems arising at the implementation level of his system, but rather they are deeply rooted and embedded within the design and coding of these applications.

This is no mystery to him, nor is it a mystery to the developer, publisher or the distributor. When he hands over millions of dollars for Operating System and Office Suite licenses, do you think he is naive to his fate? He knows that he is putting himself in a position that will have him downloading Service Packs and security updates for the life of the product. He knows that he will inevitably spend thousands of man-hours fixing, tweaking and debugging problems arising from no fault of his own. He knows that he's being thrown into a world were a 'plan b' is never enough, where being paranoid as to the security and availability of his data is a daily occurrence. He knows that the question of his system going down isn't answered with a "when", but with a "how many". The question is: Why?

In no other field or discipline would one worry about the stability and availability of an entity once it was implemented per the manufacturer's instructions. This however has never been the case when it comes to software systems implementation. IS developers get away with murder.

Is your information worth that little to you? Do you have the time and energy it will take to maintain a system that has countless bugs and oversights that will no doubt leave your data and your job in jeopardy? Why have we come to accept that an inferior system design is the norm and that there is no choice? To understand this, you must first understand a few rudimentary concepts that are law in IT.

Firstly, to be a programmer you need only call yourself one. There is no regulatory body stating who is a programmer and who is not. This is a very rare occurrence in the field of engineering (which software development inevitably falls under) as every other branch known to this author has an authoritative body. If I have mastered C, Java, and Assembly, I'm a programmer. If I have been studying QBasic for 10 minutes, I'm still a programmer. You can question my abilities and my experience, but you cannot question my title, and as is the case with any other discipline, once you have the name you can practice under it. As you can imagine, my knowledge of QBasic won't be of much help to you when you need your mission critical systems designed, but you don't know that I'm unaware of what OOP is, all you know is, I'm a programmer. I can call myself a Console Programmer, a Web Application Developer, or, my personal favorite, a Business Systems Developer (which isn't actually anything at all, but it sounds important). I'd call myself the Queen of England if it were a class of programmers. Whatever is not regulated is doomed to become bombarded by substandard parties. Someone needs to hold the bar.