Hofstadter’s Law
David Hofstadter’s law of programming:
It always takes longer than you expect, even when you take into account Hofstadter’s law.
This was in one of the closing chapters of Dreaming in Code, which I just finished last night. I read the quote over and over again, and just thought it was wonderful, because it describes exactly my dilemma with estimating how long it will take to complete virtually any programming project.
I come up with a number, and I know–from past experience–that it will certainly take longer than that. So I double it, or maybe triple it. And, wouldn’t you know it? It still takes longer than that.
I only wish sometimes I could go back to the days when I didn’t know that things always take longer than I think, and they only took about twice the time I expected.
I have a confession to make. A while back I wrote about some good progress Travis and I made on Acropolis. Well, the truth is we weren’t working on Acropolis, exactly. We were actually working on another project for a different client– however we have been building this other application with a mind towards the exact structure we expect Acropolis to have.
We haven’t been able to spend any real time on the new version of Acropolis itself, but everything we do now, we do it with Acropolis in mind.
Despite my objections, I have been forced to make modifications on the old version of Acropolis (considering it is in daily use over here) and even though I am writing in straight PHP5, my experience with CakePHP has influenced me greatly. Before, whenever working on one “module” of software, I would generally start with one main script that would load whenever someone accessed the page. Then I would throw in a javascript file that would contain all my JQuery controls. And then I would have several small scripts that would be called by AJAX requests, updating this or that element of the page. The problem always was twofold: 1) I would get lost in my structure (or lack thereof) and 2) I found I was constantly repeating myself. I would write one element in HTML, and then repeat the same element in one of the smaller scripts, or even insert a duplicate into the DOM using javascript. All this to give the “appearance” of seamlessness, but beneath the surface it was anything but.
This time my approach was different. I was working on Product Options. I started off by creating a separate file that contained my class, which was called “Option.” The class began with a constructor function that checked the Querystring for default variables. The class then contained several functions, such as “existing options”, “add,” “remove,” “edit,” which contained both the mySQL queries and the corresponding HTML for the functions. In the first script then, product-0ptions.php, I included this file and then called the appropriate functions throughout the code. Whereas before I would build a select list for the existing options, I simply called the function as so: $option->existing_options();
Whenever a change was made, the ajax request would call the very same file, except the parameters were passed in the querystring. The most important of which was “action.” So, to update my existing optiosn, after say, one was added or removed, I would call this url:
product-options-class.php?action=existing_options&product_ID=4&manufaturer_ID=7
The include file would then use an eval() statement to call the requested function and return the correct HTML. In other words, the exact function that first generated the HTML was the same one used to generate the updated HTML once the change was made. You can’t imagine how much easier this has made my life.
I know examples would be really helpful right now, but of course, due to Hofstadter’s law, I simply don’t have the time.
More to come!
Recently
Leave a Reply