For a long long time — starting in 2009, actually — I’ve been hacking away on a PHP framework, writing loosely-connected bits and pieces of code here and there as the mood struck me, repeatedly reconsidering the implementation of components as web development practices continue to evolve and as I continue to learn more as a developer. And at the end of the day, what I consider the “trunk” of the project (including the literal trunk in source control) has never consisted of more than a handful of parts that benchmark blank pages nicely but don’t really do anything.

And every once in a while, some job thing will come along with requirements perfectly suited for the application of that perfect framework, the manifestation of which exists only in my mind. And so I sit down, and in a few days, I hammer out something pretty close to what I’ve got in mind. Sometimes I’ll reuse existing components — I’ve got a database singleton I’ve been hauling around for at least a couple years now just because it works and I don’t have to think about it — but it’ll mostly be original to that project. And when the project’s done, I move on with my endless conceptualizing of something better. I may update the external original of anything I dragged in that that saw updates, but for the most part, I feel that my employer (none of these situations have ever been contract work) owns the implementation I’ve written on their time, so I take concepts with me, not code. Those concepts get rolled into the never-eventual “what I want to have”, and I go back to tinkering until I next need to pull out the stops.

I’m not really sure why I keep this up. Based on the time it’s taken the times I’ve had to finish an implementation — two or three, now — I could, if not finish this, at least have something ready to rumble in about a week straight of plugging away at it. Maybe some part of me enjoys the perpetually unfinished state: it’s a chance to continually explore (or at least contemplate) new development methods and design patterns. I think it’s more likely that without an objective clearly in sight, I find it hard to make progress on milestones. Every time I’ve had to get something operational for work purposes, it’s been a subquest: “vanquish the demon” requires “craft a website”, which has one completion path involving a frameworky backend. But at the same time, I think defining a use for the framework would somewhat rob it of its usefulness; despite the futility and inevitable over-complication involved in any attempt to craft a perfect be-all, end-all base for everything else, something reasonably close to that would be nice. Maybe I can settle for more clearly defining what it must provide.

Or maybe I’m just lazy and get distracted easily and someone throwing money at me makes me more likely to finish something. That could be it too.

LooseDetective and I completed our project for Software Engineering Thursday night. It was due at midnight, but I didn’t get it e-mailed off until 00:02:55 Friday; multitasking live sound for a band at the student bar* and frantically debugging a JTable model does that to you.

LARS — Like a Rental System — was a huge undertaking, and I’m still not quite sure how we managed to finish it at all, even a couple minutes late. The topic of the course was software engineering: the process by which software is designed in relation to its development cycle. As a class, we were tasked with the architecture of a video store rental system, and split off into self-selected teams to execute it. Thanks to the Asian professor’s thick accent, none of us clued into the fact he really wanted us to implement the system until about a month before its due date; even still, Loose and I didn’t actually sit down and start writing code until last Sunday afternoon.

Still, I’m fairly happy with how it turned out: despite what one might think, there are very few really hackish parts to be found in the codebase (probably to Loose’s dismay, due to the amount of extra time consumed in doing it “the right way”); actually, at the moment, I can’t think of a really good example of one. The design went through several changes as development progressed; the largest similarity can be found between the original design documents and the finished product in the data structures. Its largest issue is severe over-engineering: earlier in the semester, when we weren’t aware that we’d have to implement LARS, we designed an excessive number of features into it, including the ability for some items to be rentable, others just purchasable; price modifiers, allowing the modification of purchase/rental price and rental duration on a per-item basis; and a couple other things like that. In retrospect, had we known that we’d have to implement it, we probably wouldn’t have done that, but I do feel I was the driving factor in adding those, which makes me a bit guilty of the added work put on both of us.

Despite the crunch and stress associated with completing a 4,500-line-of-code project in five days, I’m not sure I, at least, would have been motivated to complete it had I started it any sooner: I feel like I would’ve put it off with thoughts of “oh, that’s started, I can finish that later” and then would’ve ended up rushing to get most of it done in two or three days and made an utter mess of it. But I don’t know; this is the first big project I’ve worked on side-by-side with another coder since Slyf and I did the Smiths Falls Chamber of Commerce website in 2008 (which I won’t link to, as it’s since had its interesting functionality gutted). That was an interesting aspect: even though I didn’t see this article until yesterday, I was most definitely the guy in a room. One may argue that that’s OK in a crunch-time scenario where the others involved don’t have experience with Methodology A or Technology B but I still feel badly about it, and it’s not the first time I’ve noticed this sort of thing: even though Rinnly and I don’t work side-by-side in the same codebase, I feel there are times where I’ve held up project progression or at least hindered teamwork with the magic words “no don’t worry about how x is going to work, I’ll take care of it”.

Anyway, it’s done now. All teams are to present their finished work to the professor (and, as I understand it, the class) tomorrow morning; as over-engineered as ours is, I think we can manage to show its ins and outs pretty quickly and still manage to impress. And then we wait for the mark — it would really suck if the almost-three minutes late does count against us and we get a 15% deduction on what may be an otherwise-perfect submission.

* Speaking of which, Adam and Steve did an absolutely fantastic job and I can’t wait until they next perform. Hopefully they don’t get the clever idea of doing a run of concerts over summer while I’m not here (please? Please don’t?).

Years later edit: I’ve converted the project’s Subversion repository to Git and uploaded it to GitHub.