3 ms·

The best programmers also know to think about performance when designing a system--if you completely abide by the strategy of "don't prematurely optimize", you

The best programmers also know to think about performance when designing a system--if you completely abide by the strategy of "don't prematurely optimize", you end up with a system which wasn't designed with performance in mind, and often is very difficult to optimize later because of this. Sometimes the entire structure of the program has to be redesigned because the original method just was not suitable for performance. A great programmer is able to think about performance at every point in designing something without obsessing about it to the point where it decreases reliability, readability, or extensibility.

noss 18y ago
I think you are correct, but your scenario is a good example of something else: Prototyping and "planning to throw one away" (Fred Brooks / The Mythical Man Month). Having written one lousy implementation in X months does not mean that the good implementation, when starting over, will take X more months. I have never seen a functional specification reaching more than 50% accuracy on details (most are not even close). When implementing you always discover more about the problem. What stops you from starting over tends to be that the customers have integrated with your system according to published specs, or large roll-outs have been made already.
- DarkShikari 18y ago
  I think you are correct, but your scenario is a good example of something else: Prototyping and "planning to throw one away" (Fred Brooks / The Mythical Man Month). Of course, but one is not always implementing a totally new system that justifies "throwing one away". Often one is implementing something whose design is well-known enough that one should expect to be able to do it right the first time. Having written one lousy implementation in X months does not mean that the good implementation, when starting over, will take X more months. Sure, but it still takes Y more totally unnecessary months, even if Y is less than X.

noss 18y ago

I think you are correct, but your scenario is a good example of something else: Prototyping and "planning to throw one away" (Fred Brooks / The Mythical Man Month). Having written one lousy implementation in X months does not mean that the good implementation, when starting over, will take X more months. I have never seen a functional specification reaching more than 50% accuracy on details (most are not even close). When implementing you always discover more about the problem. What stops you from starting over tends to be that the customers have integrated with your system according to published specs, or large roll-outs have been made already.

DarkShikari 18y ago
I think you are correct, but your scenario is a good example of something else: Prototyping and "planning to throw one away" (Fred Brooks / The Mythical Man Month). Of course, but one is not always implementing a totally new system that justifies "throwing one away". Often one is implementing something whose design is well-known enough that one should expect to be able to do it right the first time. Having written one lousy implementation in X months does not mean that the good implementation, when starting over, will take X more months. Sure, but it still takes Y more totally unnecessary months, even if Y is less than X.