On Fri, 12 Dec 2003 17:56:54 -0700, Monique Y. Herman wrote: > On Fri, 12 Dec 2003 at 23:40 GMT, Paul Morgan penned: > [snip] >> >> In the real world: >> >> Do the simplest thing that is consistent with the specification. >> Someone, whose skill level you can't predict, is going to have to >> maintain it after you. > > Corollary: Regardless of the skill level of the person who maintains > the code after you, they will find your implementation unsatisfactory, > bitch about it at every opportunity, and beg repeatedly to be allowed to > rewrite it. > > (I recently made this point at a code review. Someone paused and said, > "You know, you're right. In 20 years of software development, I've > never once met someone who was happy with the code they'd inherited.")
You are dead right. I think this *all the time* (and that's over 30 years!). Actually, I said it recently. There are a set of files from other systems which come in flat and are converted to XML files, with a few translations and database lookups, all of which is currently done by Java processes on a separate server. My view is that this Java process is bloated, obfuscated and completely unnecessary, as I could do the same thing in Perl and make the code much simpler, cleaner and *much* more easily maintainable. I am going to get my way on this one. > >> This takes quite a bit of discipline. The temptation is always to >> write something cool and clever. A lot of development (and support) >> time and money gets wasted that way. > > Someone famous has a quote about how it's always harder to debug than it > is to write code. Therefore, if you use the full extent of your > cleverness in writing the code, you will never be able to debug it. > I agree with that. Also, I have written "clever" stuff that I have had difficulty understanding when I've gone back to it later, even though I make myself comment my code liberally. Sometimes unusual stuff works out well, though. More than a decade back, I implemented a doubly-linked list in Unisys COBOL (!) for a ring-polling process. I did hide the housekeeping in separate sections, so all one had to do was "perform 9100-insert-element", "9110-delete-element", "9120-next-element", and so on. The likelihood of anyone needing to change the housekeeping code was remote, and the main program was simpler than it might have been otherwise. But the real reason I *started* writing it that way was because I thought that it would be fun, cool and clever to implement a doubly-linked list using COBOL arrays :) A personal observation: part of the problem with bugs in the first place is the thoroughness and methodology of testing, which often does not seem to be as good as it once was. I'll stay off the soapbox here except to say that, if you run a test and you have not documented *in advance* the expected result, then you are *not* testing: you're experimenting. :) BTW, the debian community deserves a lot of credit for their QA work. Doing QA sucks for the most part, and most folks do their level best to avoid being part of it. And yet debian, this cloud of volunteers from all over the world, willingly giving their time with no compensation, produces "stable" releases which compare very, very favorably with software releases of similar complexity from commercial enterprises. I'd hire every one of them if I were building a QA team :) Sorry, just realized that I've been talking about myself too much, but now I've written it, I'll post it anyway. If I've irritated anyone, my apologies. -- ....................paul "Do the little things" ("Gwnewch y pethau bychain") St. David (Dewi Sant) of Wales, last sermon, Sunday 27th February 589 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]