I’ve learned an important lesson the hard way this year: addressing a problem too generically is setting yourself up for failure.

I don’t consider myself a programmer, but given who my husband is, I’ve been steeped in agile philosophies for nearly a decade, and most definitely consider myself a proponent of such ideas. I can see how they can be applied to almost any aspect of life, but I was really looking forward to giving them a whirl when I took a contract earlier this year that I’d decided to solve using JavaScript. The script ended up being a lot more work than I’d expected, and while it worked perfectly, the amount of DOM interaction it required made it entirely too sluggish to be practically useful. In the end I had some ideas about how to speed it up, but since I’d been working on a fixed price (something Johannes had thoroughly castigated me for) I figured it was best just to deliver it how it was.

Why did the script end up being so much work? I’d been hired to do a specific job–to adapt tables in a web application to fit the size of the viewport, with the table header remaining fixed while the table contents scrolled if the table was too large to fit within the viewport. In order to do that, I’d set the scipt up to gather information about the original table, process it, then write the new, adapted table into the document.

The stupid decision on my part was the first part of that equation: gathering information about the original table from the document. Stupid because, in an earlier contract, I’d been the one who styled the original table in the first place! Without even having thought about it, I’d defined the problem too generally. My job had not been to create a solution to turn a standard table into a fluid one. My job had been to turn those specific tables into fluid tables. If I’d been clear-sighted enough to solve that problem in the first place, the script would have taken a lot less time and have (hopefully) been fast enough to be usable.

The problems we’re given are specified by the existential quantifier (∃), not the universal quantifier (∀). Theoretical and practical aspects of falsifiability are addressed in computer science classes and tied to real-world examples, right? From talking to Johannes I’ve learned that defining the problem too generally is frequently a problem for developers, however. I think people somehow feel it’s cheating to solve a problem only for specific circumstances. In reality, it’s the only thing that’s possible. We can save a lot of time, energy, frustration, and cash if we keep that in mind.