Programming Fun vs. Getting It Done

I'm pretty sure that a lot of programmers are perfectionists. Software is perfect for that - because you can change, change, change things until they work exactly the way you want. In that regard, it also caters to control freaks. Just as games like Civilization (of which I'm a recovering addict) can also cater to control freaks.

These two activities are fun because it allows the control freaks to indulge themselves. A solitary programming project lets the programmer exercise great control over the code, letting the programmer express themself and produce code that looks and runs exactly how they want it. This manifests itself most for me during a "spare-time" programming project, with no deadline and no stake-holders. This is when programming is the most fun for me - it's carte blanche on indulging my whims for the creation and functionality of software. And again, it is the same for some building and strategy games like Civilization. You make the calls - you set up the empire - you decide what goes and what stays (should your empire be strong enough for that).

Ahh, but in the real world - projects need to be completed. The truth is that there are always, always things you can do to improve software projects. In my own personal projects, I indulge myself and go back and re-do/over-do whatever items I think should be better - more effecient, more usuable, however. But during my 9-5, you have to make progress. You have timelines, milestones, and managers wanting to know if you're meeting them.

Of course, as a programmer, you still must write quality code. Good naming conventions, effecient algorithms and use of memory, readable, and logically organized code is important. And like writing an essay - you can write a first draft of your code, then go back and revise it, then go back and revise it some more - endlessly. But at some point, you have to draw the line. You have stakeholders - management and clients - that want the finished product.

Therein lies the challenge - where do you draw the line? At what point is your code, or your user interface, "good enough"? I suppose that's a personal preference, tempered with concerns from management and stakeholders. If given the time, I think most conscientious developers would go on for quite a while improving their own code. I can tell you that as you get more experience, writing quality code the first time gets easier and easier. So the desire or need to go back and revise your code lessens over time.

But here at 28, as a web applications developer - where do I draw the line? That's a big fat "it depends." In one project, the deadline was extremely tight - and we took terms like "Agile Development" and "Rapid Application Development" to a whole new level. For this project, sadly, quality went by the wayside. Thankfully, there was little in the way of processing logic, so not too much damage done. Most of the code just grabbed data from a form and stored it in a database (and back the other way, too). I'm pretty sure all developers frown at that, and so did I.

In another project, I had lighter timeframes - so the line could be drawn more in favor of quality code. While we did fail to get all (or even most) of the requirements prior to starting the project, which has caused me to have to hack my own design in order to finish by the deadline, there was still a mostly unified, underlying design that I was allowed to create, improve, and implement. So this code will be more easily understood, upgraded and maintained in the future.

As for you ... where do you draw the line?