[BatFastard]

It depends on how familiar the engineer is with the problem space.

If the engineer knows little about the problem space, then any type of optimization is not warranted until a working version is achieved.

The biggest secret to writing software is "not painting yourself in the corner".

[brianwawok]

If an engineer is not familiar with the problem space, he should learn more before he writes more code.

[bryanlarsen]

But the best way to learn is often to write some code.

[Klathmon]

Yeah, when starting a new project I tend to write a POC, throw it out, make a ton of notes on the problem and possible solutions, write a second POC, throw it out again, refine my notes, make sure i really understand the problem and my solution is actually working, and if everything looks good, write it "for real".

[coredog64]

The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. […] Hence plan to throw one away; you will, anyhow.

- Fred Brooks, "Mythical Man Month"

[sqeaky]

Then the problem is an academic endeavor and hopefully not something to be sold to a customer. If it is open source, then it is likely to fall into disuse like 99.9% of open source endeavors. If it is in the 0.1% of open source projects then the community will find the effort for a rewrite, but it could be painful like python 2/3 or perl 6/7

[adrianN]

Have you never written a prototype to understand your customers needs?

[sqeaky]

I usually iterate. Building upon what was already built.

All to often a 'prototype' becomes the finished product without the intervening iterations. If that was the plan from the start it works more smoothly.

[sqeaky]

By academic, I mean any project for learning. Not something specifically realated to schools.