Beefy Boxes and Bandwidth Generously Provided by pair Networks DiBona
There's more than one way to do things
 
PerlMonks  

Re: Make it good

by FoxtrotUniform (Prior)
on Oct 18, 2004 at 20:55 UTC ( #400317=note: print w/ replies, xml ) Need Help??


in reply to Make it good

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.

--
Yours in pedantry,
F o x t r o t U n i f o r m

"Lines of code don't matter as long as I'm not writing them." -- merlyn


Comment on Re: Make it good
Re^2: Make it good
by radiantmatrix (Parson) on Oct 19, 2004 at 13:26 UTC

    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.

    radiantmatrix
    require General::Disclaimer;
    "Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy
      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.

      --
      Yours in pedantry,
      F o x t r o t U n i f o r m

      "Lines of code don't matter as long as I'm not writing them." -- merlyn

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

        radiantmatrix
        require General::Disclaimer;
        "Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy
Re^2: Make it good
by Anonymous Monk on Oct 19, 2004 at 15:06 UTC
    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://400317]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (14)
As of 2014-04-16 17:41 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (433 votes), past polls