Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: Simplicity vs. Doing It Right

by Aristotle (Chancellor)
on Oct 13, 2002 at 11:39 UTC ( [id://204888]=note: print w/replies, xml ) Need Help??


in reply to Simplicity vs. Doing It Right

jplindstrom++, best post on the thread IMO.

He points out exactly the points my signature is meant to put in one short sentence. Any piece of software tends to grow if it does something useful; if you don't do it the right way right off the bat, you end up with a big ball of mud full of kludges and quick hacks that you'll basically have to rewrite from scratch, or spend a long time labourously refactoring.

People sure are free to stray from the beaten path once they understand why so many people have walked it. Once you can tell exactly when and how your homegrown CGI or XML parser will break, you are free to write one when you think CGI or XML::* is overkill. But that's not something you will be able to do before you have acquired a fair degree of proficience in both the language as well as the specific problem domain.

And by definition, anyone who comes to the monastery with questions about those isn't.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re: Simplicity vs. Doing It Right
by sauoq (Abbot) on Oct 14, 2002 at 00:01 UTC
    Any piece of software tends to grow if it does something useful

    I can't agree with this.

    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.

    Funny, but I always thought your signature referenced that latter class of deployed code.

    -sauoq
    "My two cents aren't worth a dime.";
    
        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.

        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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://204888]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (3)
As of 2024-03-29 15:54 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found