Re: Re: Re: Simplicity vs. Doing It Right

[jordanh]

Some software follows this pattern and when it does, it usually follows it right to the point where it does a lot of stuff which isn't useful and none of it very well. I think that's true whether its full of kludges or cleanly designed.

In my experience, there is a whole helluva lot of software out there in the world which does something useful, requires almost zero maintenance, and runs daily on production servers. A lot of it is just the kind of makeshift stuff that dws is talking about, I think. That stuff doesn't grow. It just runs and no one touches it because they don't want anything to break.

Part of the problem is that you can't know in advance which software will need to grow in functionality, need to be rewritten or need to be maintained.

It's generally best to assume that the software will need to be maintained and that you should code with that in mind.

How many times have you been stuck in a quagmire, fixing something that should have been built better in the first place? I know I have, many a time. In at least some of those cases, I know the original author never dreamed that this particular piece of software would be used so long, or other software would become so dependent on it when they implemented their "makeshift". I know this because I was that original author.

In most of the cases when I wasn't the original author, I strongly suspect the original author didn't foresee the future maintenance.

[joe++]

It's generally best to assume that the software will need to be maintained and that you should code with that in mind.

What's more, even a oneliner tends to break in a hard to find way if no strict and warnings are enabled. My experience is that especially in "duct tape mode" I tend to shuffle around scripts, paths and files.

Taking the effort of enabling warnings and declaring my variables saves me a lot of debugging effort, even for scripts that solve one ad-hoc problem in an ad-hoc way.

Many times such a "proof of concept" later became part of a more serious project. Then it pays to have a more robust start.

(on a side note, I'm currently really interested in the eXtreme Programming method, where you start to design testcases rather than jumping at solving a problem by hacking away).

--
Cheers, Joe