Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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".



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


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


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".


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"


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


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


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: