| Fixing Poor Programming Practices I see a lot of poor programming practices in real-world code. I'm sure I've written a few myself. I'm also sure that many of you see the same thing and sometimes wonder how that code got deployed. One of the things I told myself over the last few years was that I had to accept the reality of situations. It's easy to complain and say that code should be written differently or entities should be modeled in another way, but I (or you) can't change that situation today. And it ignores the fact that we are stuck with this environment and we have to move forward from here, not try to rewind the clock and go back in time to design things better at the start. Today I'm wondering how you've adapted to poor practices and fixed them. Do you have stories to share that might help others deal with their situations? Post comments below, and to help, I've got a few stories from my past. Both of these deal with third-party software products that (poorly) use a SQL Server database. One company purchased a new accounting package with very poor security practices. The installation noted that the software needed to use the sa account. I couldn't think of a reason why an accounting package needed sa on an instance, especially as we were installing this on a production server with another database. I called the support line and we discussed what was happening. They said that for the accountants to add new users, they needed to add a login and thus needed sa. This was in an older version of SQL Server, but that still didn't make sense. It was lazy developers not understanding the security model and wanting sysadmin to make things easy. We showed them that we could add a login ourselves and a public user mapped in the database, which the software would pick up and allow finance people to assign rights. Poor practice mitigated. In another piece of software, we found a view being used that was querying other views and tables. As you might expect, performance was poor. We decided to "fix" the view with better code, but first, we created a new schema (with our company name) and added their view to this schema. That way we kept their code around. We rewrote their view to run more efficiently, and if we had a support call, we'd replace our better view with the original one from the previous schema. We even had a proc in our schema to do that for us. Of course, our view was kept in our VCS, as it should be. If you've got stories, let us know in the comments today. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums | 
