Re: Make it good

[FoxtrotUniform]

You missed the most important one: Make it run.

A program that meets 90% of its spec and takes a week to write is often more useful than one that meets 99% of its spec ("there is always one more bug") and takes three months to write. Basically, what I'm saying here is that your program should always work to some degree, so that you can release them to the users, get feedback on how you're doing (real-world specs are moving targets), and get part of the problem solved right now. If it's buggy, so what? Make sure your users know that what you're releasing isn't "finished", and make sure they know that you're listening to the bug reports.

I'm thinking of this mostly from the perspective of the tools I used to write in industry: data-munging scripts to save people hours of drudge work. In almost every case, I could get a large chunk of the problem solved in a matter of hours, and start saving my users time right away while working on the rest of the feature list. On the other hand, I think this works well in most other application domains, too. Let's say you're writing a dynamic, user-tracking website for tracking local bands and gigs. Don't wait until you have theme support and a spiffy forum to release the first version; let people start listing (and advertising for) gigs right away while you add to the feature set.

We'd all be pretty disappointed if vroom had waited until Recently active threads was implemented before going public with Perl Monks.

[radiantmatrix]

I didn't really mean to suggest that one should wait until all these goals are met perfectly before releasing anything. In fact, I'm pretty sure it's impossible to create the "perfect code". But, what you release should work, at least reliably enough for your target users. Beta releases are somewhat exempt -- that's why they're beta. :)

The development process is, of course, iterative. And the mantra of "release early, release often" is definately valuable in the quest toward good software. You do have a valid point about not waiting until you implement 100% of the features before a release. However, I did say "conforms to the spec" -- what you do implement needs to be as correct as possible. In many cases, you can conform to a spec without implementing every feature of it. In some cases, though, you can't.

[FoxtrotUniform]

I didn't really mean to suggest that one should wait until all these goals are met perfectly before releasing anything.

I don't think you did. All I'm saying is that you didn't point out "make it run". I'm not attacking your position, just adding to it.

But, what you release should work, at least reliably enough for your target users.

(Emphasis added.) Here's my point: don't get so hung up on technical correctness that you forget about why you're writing the program in the first place. If your target users can get more work done with incomplete, beta software than they can without any software at all, give them the beta while you work on the next release.

[radiantmatrix]

I guess I'm still not understanding you. How is "make it run" fundamentally different from "make it work"?

[Anonymous Monk]

It entirely depends on what you are writing. I guess if your MP3 player is silent for a second every 10 second (meaning it works 90% of the time) that's ok. But given the amount of traffic lights I need to take en route to work, I'd have two or three accidents a week if they only worked correctly 99% of the time.