Subj : Re: Is well written code a rare species ? To : comp.programming From : David Date : Sun Aug 28 2005 06:30 am Hello George, I've been away from the computer for a few days. I also read your reply and had to change tasks before replying and it got lost in all the stuff that has come in the last few days. At least I've found it again. I hope you are doing well this weekend. On Thu, 25 Aug 2005 21:20:18 UTC, Anonymous George wrote: > On Sun, 14 Aug 2005 13:16:53 +0000, David wrote: > > >> On Fri, 12 Aug 2005 17:56:51 UTC, Anonymous George > >> wrote: Most of those programs were badly written. > > > > Why did it take you 10 years to write this? > > This new job has more pressure and making changes *fast* with > poorly structured code is really hard. Yes it is. It is sad that some employers need/want fast fixes to problems that are better solved with a little thought. > > More importantly what did you _do_ when you found code > > that could have been written better (in your opinion, anyway)? > > I usually only change the minimum necessary to fix a bug or to implement > an enhancement. If the code is badly structured that takes a lot of time, > because it's hard to find out where you have to make the changes and what > the changes are. So in such case, I complain loudly and try to get more > time to understand and restructure the code before making the requested > changes. But there's a lot of pressure to deliver the fixes > and enhancements and usually there's no time to fix the > structural problems in the programs. Trade-offs are part of the problems we must deal with. They may accept a low cost of making a quick fix and not realize what could have happened with a little more effort over time. Certainly you can see where certain bugs will tend to repeat themselves. Sadly management often sees this as productivity -- the ability to make fast changes with minimal cost. They don't measure the fixes they have to fix again later or otherwise address in other parts of the code. It sounds like you are part of a team and the overall goals are basically to make changes. A lack of ownership and responsibility can sometimes lead to code that gets neglected. Perhaps you can suggest some smaller 'fixes' or process improvements that will give them a nudge in the right direction. For instance, if the problem was a misuse of some function (say a locking feature) even when you have the fix for that problem at a specific point in the code, perhaps suggesting a quick review of all such calls would prevent similar problems that are not yet reported or experienced. Sometimes we can improve the code and make the mistake harder to make the next time around. Sometimes the manager doesn't understand that improving the whole product can be worthwhile as part of the process. There are companies that have fix-only processes that follow the path you describe. I worked for several years at IBM and they had a team that developed each new generation of products and kept moving on. I was part of the maintenance crew and although we reported fixes up the chain of command, no one thought the original programmers could make the same mistake later on in another product. Our code base was also quite large (then entire OS and application suite) and the team was about 200 programmers with managers that expected multiple fixes per day. The rules laid down expressly forbid improving the product at all. Sometimes that is all the product creator wants and we have to live with that burden. > > Is that because the projects are structured so poorly, you > > do not understand how they are put together, or perhaps you are being > > asked to make significant changes and the changes should be rather > > difficult to make? > > The changes are usually not so significant at all. > But because of the poor structure of the code it's much > more difficult than necessary to get a grasp of the base > that I'm going to build upon / am going to fix. I agree. Some changes, though seemingly simple, can be quite complex or far reaching. I've had the misfortune of fixing the same communications code many times over to prevent specific problems only for everyone to find the underlying symptom grew worse with each fix. It started with a minor problem and years later resulted in some very unstable customers that did specific things. Only when the real problem of understanding what the original developers wanted to do and then correcting their logic and the whole mess created since then were we able to actually fix all the problems in that part of the system. The developers looked productive, but management didn't like more severe bugs and the (usually larger and influential) customers certainly didn't like apparently more buggy fixes being issued. It is important to understand when the problem is just a local fix or needs a bit more exploration to prevent far reaching implications. > > I would hope that simple changes aren't that difficult to make. > > They are ! But perhaps it's also me. I hate making errors. > It makes me feel embarrassed. I don't want to introduce > new bugs when I'm fixing one and I don't want to introduce bugs > when I'm enhancing some functionality. I agree. I'm also a perfectionist of sorts. I'd rather have people's view of my work be that I did good work rather than that I usually did something useful and that others had to fix the messes I'd created. I also like to help the team understand that and help everyone improve. We are all learning ways to improve. > Greetings, > > George David .