Jeff Moden (9/19/2008)
No... hiring a DBA would solve the problem. The hard part, it appears for most managers, is actually finding a DBA and not some cowboy that thinks (s)he is because they know how to install the Developer Edition. 😀So far as getting people to listen and learn, you sometimes have to use a "bat" in the form of before'n'after code. If you cannot prove what you say, what you say is not proof and few will listen without proof especially if your way is on the fringe of innovation or effectiveness. And, "white-papers" and forum posts are not proof. Only code or demonstrably hacking lame security is proof. 🙂
Everyone has had managers that would rather get it done in a hurry instead of doing it right. You've got three choices there, too. Proof of the ROI of good code, do what they say and smile even if artificially (I never do that if they're wrong), or get out of the company.
Absolutely correct. I have often given up on resolving something in meetings and just said "I gotta do something even if it's wrong." Challenge my ideas and we can easily get into a stand off. Challenge my code by demonstrating an alternative and the results can be measured objectively. Developers have an inherent distrust for people who talk or write about how the code should be written but don't write any to prove it. You still have to be wary of code loyalty - a sorry waste of emotions IMO. People will come up with some pretty lousy reasons not to change code even in the face of evidence. "It's easy to understand and better for future maintenance." (You mean like changing it now? 🙂 ). "Your code depends on observed behavior" (Duh! The whole point of benchmarking is to observe behavior). That sort of thing is one of the issues that caused me to step down from management. When code isn't right you can correct it and it stays fixed. People are different...