Log in

No account? Create an account

Previous Entry | Next Entry

When is software "good enough?"

Dave Taylor has another thoughtful essay, this time on the subject of whether/when it makes sense to strive for perfection in software. As it turns out, he, I and Dan Heller (aka argv, author of mush) had a debate over this in email, many many years ago. I recall my position being (primarily) motivated by some criticism that had been aimed at some people who I worked with at SRI for buggy code, and my reasoning that at least part of the problem would be solved if people used better (more efficient) algorithms. (There were other issues, such as the usual concern of developers of not having enough time to completely test their code before releasing it.) But I was also feeling somewhat insecure about my own abilities in that regard, particularly since at the time there were some people who'd just been hired who had a lot more problem-solving ability than I did (as evidenced by having a greater understanding than I did of algorithms at the time).

Dave made many of the same arguments back then that he just posted. One that I remember was that under some conditions it's good enough to write a shell script even though a full implementation in a standard programming language might be called for, on the grounds that it's something that can be quickly implemented. Dan's response, after a few exchanges between Dave and myself, was that he was in total agreement with Dave, and the basis for his opinion was that programming was a hobby for him, not just a career.

Well ... I have never really considered myself to be a hacker. I think I have tried, over the years, to strike some kind of a balance between doing "the right thing" and doing something that users, customers, or a proxy for same (ie. management) thought was necessary. I have certainly seen the dark side of "good enough" software – it may have been good enough to work for six weeks of transition while bringing someone up to speed to take over my reporting responsibilities so I could join the index build team, but it wasn't good enough (and was never intended to be) to be a replacement for Yahoo's log processing, and would have had to be in order for me to remain employed there ... So while I certainly respect Dave and Dan's arguments, I have to admit a certain frustration, perhaps because I've been burned ...

BTW, one of the "heritage" radio stations in the SF bay area, KFRC, changed to a new format, which features (among other things) pop songs from the mid-to-late 1980s. There was a station on the air back then called KYUU that played many of the songs KFRC plays now. KYUU's frequency was 99.7, which is KFRC's now as well. I mention this because I was a regular KYUU listener around the time Dave, Dan, and I had this debate.

(Why do I remember this, but don't remember what the DNS options are for tcpdump?)


( 2 comments — Leave a comment )
Sep. 23rd, 2006 07:09 am (UTC)
Any time there's a discussion about whether something is "good enough" the obvious question follows: good enough for what? This is of course a part of the maxim/aphorism: "cheap, fast, good: pick two". (Usually heard to describe restaurants, but can be applied to almost any project, I think.)

When I was at Apple, the three factors "bounding" any project were quality, features and cost (and "cost" was usually measured in terms of "schedule"). I guess that's similar to how we as customers evaluate any product or service: quality, quantity and cost. How good is it, how much do I get, and what will it cost me?

I'm currently working in IT for a company that is reducing its cost footprint, and has been for a while. For me that means I am working on the fast/cheap end of the cone, and have been for a while. Right now I'm working so fast and so cheap that I amost don't have time to even think about how something could be made better, let alone make a choice between good enough and better. But the fact is, the quality of our IT doesn't distinguish us in the eyes of customers, when we are compared with competitors. I realize now that this is one of the reasons I am unhappy with my job--the only "challenge" I get is how quickly can I get it done and move on. It's like I'm working in the M*A*S*H unit for IT tools. Almost constant triage.

It's been a while since I have had an interesting "scalability" problem. At least at AV we sort of had to think about whether something we were about to deploy would chew through scarce resources, or whether it was simply consuming CPU on a machine that was mostly idle on CPU because it was IO bound or similar. That's an environment where better algorithms are certainly important, because you're dealing with a scarce commodity other than programming man-hours.
Sep. 23rd, 2006 10:02 am (UTC)
I'm more professional programmer than hobbyist these days (family responsibilities soak up a lot of that hobby time). From my perspective, I consider my primary responsibility to work within the constraints imposed by my employer. After all, that's why they're paying me. However, I am extremely careful to inform all concerned when software is a prototype, or a quick and dirty solution (I have a few programs whose names begin with "qnd" for just that reason). And I build at least basic testing into my development time.

Two benefits of having many a fair amount of experience, generally and with this employer, are that it takes less time to craft decent software than when I was younger, and I am given more opportunity to manage myself. While there are many applications that I'd like to optimize or even rewrite, I'm confident that I haven't misrepresented any of the work, including the stuff that I think is functional, but rather suboptimal. For me, that's good enough.
( 2 comments — Leave a comment )