[From MySQL Developer Zone
Having spent the first 15 years of my IT career in applications development and database administration I can say with utmost confidence that I invested much more time debugging problems and responding to issues than I ever did building new applications. While the teams I worked with implemented many new systems, most of my time was dedicated to ensuring that existing and legacy applications were not only running, but running at the highest levels of security, performance and availability. I also learned early on that even bullet-proof code is vulnerable when it comes to things like corrupt data, empty result sets, security breaches and database scalability issues. Often I would spend valuable time and effort debugging application code only to find that the true culprit was rooted in some obscure value or data returned from an external database call. I remember this happening one particular time and me calling the DBA on duty only to be told thats a known issue in SQL Server 6.5, you need to upgrade to 6.5, service pack 4 to correct the problem. While I appreciated the timely information, I was less than enthused about the fact that I had an unplanned server upgrade on my hands and it had to be done immediately to restore a business-critical application to full functionality.
The article continues at