I was looking over such a piece of code last night. Someone needed a web interface for running tests cases, and put together a web server that would serve up HTML, images, and run Java test cases and return the results (in HTML). All in 61 lines of Perl. Granted, it was hardly a complete web server. It worked off of the first line of the HTTP request, and returned a minimal (but correct) response header. Some of it looked like raw socket code lifted out of the Camel book. No strict, no modules (other than Socket), and only one comment. Still, it solved someone's real problem in less than page of code.

Looking it over, I got to thinking about some of the people who wander in here with real problems to solve. We usually advise them to use strict, use CGI, and reuse some set of modules from CPAN. Instead of a minimal script that'll solve their problem, they're sent off with a shopping list of things needed to build a "correct" (i.e., heavier) solution. And often these solutions require fresh CPAN downloads to install elsewhere, which raises a real barrier in some situations.

The problem with the "right way" is that it's a slippery slope. Do I really need an XML parser if I'm given a simple chunk of XML to deal with, or are regexes sufficient? Do I really need a database for a simple content management system, or are would flat files work adequately? Do I really need to use CGI if I'm doing something simple inside the firewall? The "right way" adds weight that isn't always needed.

But many of us are inclined to do things right. We know that today's requirements are incomplete and will probably grow anyway, and that we'd better plan for the future by building solider solutions than are asked for, leveraging tested, off-the-shelf code where possible to save effort.

I suspect, though, that this leads many of us to over engineer the occasional one-time problem we encounter.