If It’s Broke, Fix It
I was having a debate with a developer today about a situation similar to the following:
When reviewing the build for a new SSIS / SSAS deployment, I noticed that because of the way their build was structured, a failure could occur in some critical underlying processes, while on the surface, everything appears normal. <geekery> This was due to 1) a bug in how SQL Agent jobs work in SQL 2005 (see here), and 2) the way their process was calling the SQL Agent job to process an Analysis Services cube. </geekery>
Now, immediately in my mind, this was a clear showstopper. I mean, if I can’t tell for sure if an automated process failed or not, how on Earth am I supposed to support it? I luughed at suggestions such as manually checking on a daily basis or just telling business “it’s broken, but if you don’t care we won’t fix it”. Ultimately, the developer’s final comeback was basically that “I followed conventions of how this was supposed to be set up, so you can’t require me to make this change before we go live.”
Huh? Since when does “it’s broken in other places, so I can leave it broken here” work as a reason not to fix something, especially before it’s actually running for real? How about showing the business we’re looking out for their best interests and ensuring a quality client experience?
