|
|
|
having to hardcode
Wednesday, May 27 2009
One of my greatest assets as a computer programmer is my laziness. Ideally, I never tackle the same programmer problem twice. I find the solution, wrap it in a function, and try to remember that I've solved that problem with a function having the name I decided to give it. I've solved some complicated problems this way; for example I have a Javascript function called insertintoDelimitedString that takes the following parameters: strData, strToInsert, rowDelimiter, fieldDelimiter, intNumericField, intThisNumber. This is the description I wrote about it: "Pass in a double-delimited data string, a string to add, the field containing the numeric key of the data, and the the numeric place in the data to insert it." (I love double-delimited strings, using them frequently in place of MySQL tables, particularly in Javascript environments where database connections are difficult or impossible.)
I do, however, have a tendency to overreach when it comes to creating generic solutions to complicated web development problems. Nowhere is the is more true than in my building of database systems to support questionnaire systems. I've built somewhere between five and ten such systems through the years, always trying to work towards a generic solution. For years I've had the basics down: that such a system consists of tables for questionnaires, questions, answers, suggested answers, and answer types. And I've long known that, from a database perspective, there's no difference between a single-selectable dropdown and a list of radio buttons. But on the ground, every questionnaire system ends up being very different, and those differences usually show up in the way questions interact with answers.
The latest web development job I've been working on is a questionnaire whose code is based on a PHP-MySQL system I'd built two years ago. But the requirements for this questionnaire demanded that the form roll out with different series of questions based on the answers being given. My solution to this problem was to load the entire form into the browser, rendering invisible all but an initial set of questions, and then revealing subsequent questions as dictated by the particular answers being given. I'd thought that all of the form-changing answers would be in response to yes/no questions, so I made a database provision allowing an admin to enter ranges of questionids to be rendered visible or invisible depending on whether certain questions were answered with a yes or a no. And this seemed to be working great until my colleague out in Los Angeles reinterpreted our cryptic "spec" to mean that in one case the form's question trajectory was altered by the change of a dropdown. I'd built no support in my system for this, and generic support seemed like it was going to be difficult to implement, so I ended up hardcoding that one question inside its own little cloud of hardcoded DHTML. It worked, but it made me die a little inside. I understand that there are web developers who always err on the side of such hardcoding, but I wonder how they ever learned how to program at all. 80% of what I know about programming I learned from the challenge of figuring out how to avoid hardcoding. The other 20% I learned from pursuing the unattainable goal of never writing site-specific code at all.
For linking purposes this article's URL is:
http://asecular.com/blog.php?090527 feedback
previous | next |
