display | more...
A particular computer program can be:
  1. fast
  2. correct
  3. easy
Unfortunately, a (non-trivial) program cannot be all three.


Before you start to develop a program, decide which of the above goals your program should satisfy. Use the result of this decision to guide you during the development of the program.

Here are some points to consider as you make this all-important decision:

  • a program which produces correct answers but not very quickly isn't all that hard to write.

  • a program which need not produce correct answers should not take long to write (i.e. what's the point?) and might as well run quickly.

  • a program which must produce correct answers quickly takes considerable skill and effort.

  • nobody's interested in wrong answers1. That leaves the choice between fast and easy. Make the choice which is appropriate in the context: don't waste a lot of effort on a program (or part of a program) that doesn't really need to be very fast but be prepared for a MAJOR effort on a program (or part of a program) which does need to be fast.

  • given a choice between fast wrong answers and slow right answers, pick slow right answers every time (well, maybe not every time - see the Sometimes you just can't get there from here section below for more info).


I've found that contemplating the above dilemma is quite useful when setting out to develop a computer program/application of, literally, any magnitude. It has helped me to quickly come to terms with what are sometimes the hardest questions of all:

  • how much effort and skill should be dedicated to the task?

  • within the context of the problem at hand, where should the most effort and skill be expended?

  • how fast does the program truly need to be? (i.e. how much is the "customer" willing to "pay" in order to get a program which is x% faster?)

  • (most important of all) does the program really need to be written? (i.e. is the effort required to satisfy the correctness and performance goals justified by the benefit that having the program is expected to provide or is there a different way to achieve just the really important benefits?)

    This question can also be targeted at individual features: "Is the effort required to implement feature X justified by the benefit which feature X is expected to provide?".


What I find truly depressing is the number of programs which I've used which run slowly, don't work very well and obviously took a great deal of effort to write. At the very least, pick ONE of the goals!


Sometimes you just can't get there from here

There are problems which have been proven to be impossible to solve quickly (see The Traveling Salesman Problem for a specific example and check out NP-complete and NP-hard if you want to risk turning your brain into mush by reading about this class of really difficult problems).

In such a case, "fast" is simply not an option so the wise programmer might be tempted to focus on "easy" and "correct" (the foolish programmer doesn't realize that the problem is NP-complete2 and spends an absurd amount of effort trying to come up with a fast and correct solution which, by definition, simply doesn't exist).

Once the "customer" finds out just how slow a "correct" version of the program is going to be, the programmer is usually forced to abandon "correct" and use heuristics to come up with an answer that's "pretty good". The good news is that such a program is usually fairly fast. The bad news is that "fast" is a relative term and the proposed solution may not be fast enough for the "customer" (who is already not very happy because they've been told that it can't be "fast" and "correct").

The programmer then usually finds that even getting the heuristic approach to work is a lot of work and the "easy" goal vanishes.

The end result is that they end up with a program which:

  • might not be fast enough
  • isn't correct
  • isn't easy
Sigh.

I suppose that the good news is that the programmer has a "good reason" why the program is what it is. Of course, "good reasons" why they apparently failed are unlikely to help them to get their next contract. Some might argue that the truly wise programmer realizes that it's an intractable problem and runs away before becoming committed to the task.


Source

I first ran across this dilemma on a co-worker's whiteboard at Myrias Research Corporation. I've no idea where he got it from or if he (Brian Baird) came up with the idea himself.


1One could argue that wrong answers are sometimes acceptable. For example, a flaw which the "customer" can easily avoid or deal with might not be worth fixing as the effort required to remove the flaw might easily exceed the benefit to the "customer" of having it removed. This is a case in which one might actually decide to choose "easy" instead of "correct".
2In fact, the problem might be solvable in polynomial time and yet still be impossible to solve in a useful time frame. For example, even an O(n2) or O(n3) problem can become hopeless if n gets big enough (you know that you're in a LOT of trouble when n is 1015 and your algorithm is O(n3)!).

Log in or register to write something here or to contact authors.