http://www.perlmonks.org?node_id=400618


in reply to Re^2: Make it good
in thread Make it good

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

Replies are listed 'Best First'.
Re^4: Make it good
by radiantmatrix (Parson) on Oct 19, 2004 at 21:11 UTC

    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
      Having read the thread in a somewhat spotty fashion, I'd say that it's the difference between (make it run) implement the correct features and (make it work) implement the features correctly.

      The emphasis for "make it run" is to get features fast to your users (make the program actually run the code). If it solves problems that aren't the user's problems, it's useless. If it solves a few of the user's problems earlier rather than later, it may be more useful. It sure provides more feedback.

      The emphasis for "make it work" is for your program to not contain bugs. If it solves the user's problems the wrong way, it's broken.

      IMHO,

      /J