This piece was written awhile ago by Jeff Atwood, but I saw a mention about it recently. It’s about software developers hating software. It’s a fun piece, and written a bit tongue-in-cheek, though with a lot of truth in there. Certainly lots of the “bundled software” that come with gadgets is unnecessary and poorly tested. That’s sad, as there is the chance to add value to products if the software is well written, and perhaps, open sourced.
However the thing that caught my eye was the ending. Mr. Atwood says that if a developer in an interview doesn’t say the worst code they’ve seen lately is their own, then they may not be a competent developer. I hope that part is also a joke, and I suspect it is. Though I also think that it’s a healthy attitude for people to see room for improvement in most of their endeavors.
No matter what type of task you are performing, and certainly programming is an area many of us focus, complacency is a poor way to approach your work. We know we won’t be perfect, we know we’ll make mistakes, we know there’s room for improvement, and we know we NEED TO GET THE PROJECT DONE. The balance we strike in moving forward should be accomplishing tasks, learning what we did right and wrong, doing more of the former (and less of the latter) in the future, all while taking pride in the work we do well.
Certainly some people are obsessive and perfectionists. There’s probably another few choice words some of you have for those individuals, but most of us need to balance our desire to build something amazing, with the necessity of completing work. We also need those little wins that come from having our work solve problems, even if we’d build software better the next time. The important thing is that you try to do better the next time.
Steve Jones
Listen to the MP3 Audio ( 2.7MB) podcast or subscribe to the feed at iTunes and Mevio . 
The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
Voice of the DBA 
I love this topic. Bad code. I see it all the time. Bad code is the primary reasons for poor performance, increased user wait time and system resource bloat.
Case in point. Take a company that has decided to put a heavy investment into a system to manage their core business. They spend 2 years in their due-diligence and select a “mature” solution. The solution comes in-house along with a number of Sr. Software Engineer consultants to customize this solution to closely match the business needs.
It isn’t long before the consultants find that there is more work than first scoped out. Since the commitment has been made they decide to plow forward. This is a typical scenario that breeds bad code. The cycle begins…. A phased approached development/deployment plan is developed to roll in new custom code. Since there are so many consultants doing so many things there isn’t any coordinated effort in managing the overall application but instead someone is insuring all of the new features are added on schedule. Bottom line is the consultants are working at a pace where getting things done is more important than good, sound design standards are met.
To end this case the consultants are now done, all features are installed and they leave behind one big mess.
I have seen this scenario many times. I have been on the receiving end of a poorly developed database(s) and am left to “make it work”.
This is a very easy trap that companies fall into and happens more times than not. The life of a DBA marches on….
Kurt Zimmerman
Database Administrator
Lefrak Organization
New York, NY
LikeLike