Yup! I can think of several "dirty little secrets" in the project I am currently responsible for. Quick-hack data extraction from some simple XML generated in predictable ways only within the current suite comes quickly to mind.

Which brings me to the matter factoring these little nuggets. As often as I can, when I commit one of these "quick solutions," I wrap it in such a way that later, when things get more complicated, it will be easy to exchange the "adequate hack" for some serious code.

The slippery slope of quick hacks embedded in code that has a future is when we later find ourselves writing around the inadequacies of the quick hack instead of fixing things. I try to set up subroutines that claim to do the job robustly even though a quick glance at the innards makes it obvious that their capabilities are limited. Later when the routine stumbles under new demands, I fix that subroutine rather than adapting the calling code to the limitations of the quick hack.

My ability to predict which well-wrapped quick hacks will need this attention in the future is far from perfect. (Which is why Extreme Programming counsels us not to spend too much effort solving problems that have not yet come up.) I have said two years later "Yee Gads! Is that functions still doing the job? It was just a placeholder." as often as I have said one month later, "I thought sure I had anticipated everything in this block!"

And often when something breaks, there is the wonderful 'Aha!' moment... "So that's why it's safer to use the recommended module!" Those are the lessons that stick.

I think quick hacks are fine if documented and factored properly. I would even argue (XP-ishly) that effective programming is a constant process of weighing wisely the least you can do to produce code that does the job now and lends itself well to future modification.

------------------------------------------------------------
"Perl is a mess and that's good because the
problem space is also a mess." - Larry Wall

In reply to Re: Simplicity vs. Doing It Right by dvergin
in thread Simplicity vs. Doing It Right by dws

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.