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

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.