Subj : Re: Is well written code a rare species ? To : comp.programming From : John Date : Fri Aug 12 2005 04:19 pm "Anonymous George" wrote in message news:pan.2005.08.12.17.56.50.318008@somewhere.nu... > Good day everyone, > > This is my second job now. By now, in my 10 year career, > I have had to maintain some programs that were written > by others. Most of those programs were badly written. > Global variables all over the place, way too long functions > with hardly any useful comments, badly chosen function names, > you name it. > > Is bad programming common practice ? > Is well written code a rare species ? > > I ask this, because I want to know if I should change > myself or if I should just go to another employer. > My current job is driving me crazy, because it takes so much > effort to do even the simplest modification to the application. > > And how can I learn during a job interview whether the company's > product has high quality source code ? I know every company will > say that about themselves. Hi George, IMHO; ugly code is everywhere. I believe there is a many reasons for this : 1. Consultants who never maintain thier own code. I know there are probably some good consultants out there, but I'm willing to bet they agree with this statement. 2. Programmers who don't understand the code they are maintaining. 3. Deadlines undermining the programmers better judgement. 4. Project evolution turning a good design into a bad one. Either over the course of many years, or months if the requirements/specs weren't done correctly. 5. Weak programming culture. 6. The fastest coders are rewarded, even when they cause most of the maintainence work ... because nobody watches who created the bug. I believe reason #1 is the biggest problem. Test driven development may help eliviate enforce cleaner code. And I'd like to say working for a product developer would have cleaner code, but the shrink wrap software company I worked at had the WORST code I've ever seen ... because of every problem listed above. In regards to reason #6, I once buiilt a very flexible tool, which handled 95 percent of what you would ever do, and you could do it quickly. There was also a customization feature built in to handle the other 5% of difficult tasks. After building this tool, and using it without problems for years without maintainence, a consultant was asked to do something that fell into the 5%, I told him how to manage it. But instead of building the customization feature, he decided to change the underlying tool. The tool was a problem ever since, and I can only imagine what it has turned into with other consultants trying to fix it. But that's ok, because since I built the tool ... I'm sure they all blame me. ;) Good luck, John .