Hacker News Reader

Comment by anthonyrubin | Hacker News Reader

I suggest a bit of both. Start with "Dijkstra style" and finish with "hacker style". Adjust levels of each as appropriate for the project you are working on.

View on HN

I prefer the opposite; hack together a prototype to get stuff moving. Encounter issues you didn't even think about during the planning stages. Eventually notice your code is a big morass of hacks that you don't want to look at. Enumerate all of the issues with the hacked-together software which could be done much better now that you've got hindsight and experience with the problem domain, and rewrite the software Dijkstra-style.

I agree. Working everything out is the best way to get all the details into your mind. Once you know all the details a good design should be much more obvious. You may need some extra coffee to finish the final version, it is tempting to leave it alone once you are intellectually satisfied since you already have a working version. If you managed a decent modularization of the first version, you may be able to prioritize and just do a final version of the important parts.

This relates to the "version 2.0" dilemma. Version 1 of a program works well enough to make money, so that team gets to make a version 2. But they try to "redo it right" by making their product do everything conceivable (think emacs), but it's slow and buggy and in the practical ways, worse than 1. Version 3 (where they learn from version 2 how to make it elegant) doesn't get written because the team gets split up because v2 was such a failure. Another example of the v2 problem is Winamp.

The Dijkstra argument is that looking at examples, learning about concrete cases may prevent you from thinking about the most general abstract problem, for which you may devise an elegant solution. So according to the Dijkstra argument the prototypes you create may bias/prejudice your thinking, and should be avoided if you want to get to an elegant/optimal/general solution.

That sounds right, I can think of some revamp/rewrite projects that felt stunted because we only really thought about the problem in terms we already created in the first iterations.

However, in practice I find that programmers don't necessarily know what the (software engineering) problem is, what feasible solutions are out there (feasible != possible), don't know what the drawbacks to their plan are, and generally feel unmotivated if they don't start banging out code relatively soon. It seems really easy for a project to stay indefinitely in the planning stages if you want to make sure it's a "perfect" solution, and it's very hard to know that a solution is "perfect" without encountering its drawbacks through experimentation, i.e. coding.

I often do this without even thinking about it -- I'll start a new program by writing a working prototype, but I won't even run it through the parser until I feel that it is minimally complete and have "proven it correct". It lets me focus on writing and thinking instead of editing and the 'trivial' matter of whether it works at all.

Then I spend some time fixing stupid syntax errors and namespace collisions so it parses and works, init version control, and after that I do super-short iterations.

Reply on news.ycombinator.com