Essentially the exact same issues everyone else faces, which are covered exhaustively here: http://www.stevemcconnell.com/rd.htm http://www.stevemcconnell.com/r

Essentially the exact same issues everyone else faces, which are covered exhaustively here: http://www.stevemcconnell.com/rd.htm http://www.stevemcconnell.com/rd.htm I'm going to single one out though: tweaking: making changes without adequate anticipation of the effects, or without the theoretical backing to expect that it will be correct. When you have a well structured high level understanding you can make changes knowing approximately what the effect will be and converge on the solution. Without that you end up thrashing around and making changes at random. If you take a random walk you're probably not going anywhere fast. When you are dealing with a well designed and executed system, then tweaking actually seems productive, because you begin from a good place in the solution space, when you explore the "local neighbourhood", then the modifications still produce a functional piece of software and it might actually be better in some ways that you care about. When you are making something new, tweaking gets you nowhere. EDIT: Here is a foolproof process to get me to automatically disregard all your future ideas: 1. Find some parameters that were chosen with theoretical justifications and a real analysis of historical data. 2. Modify one of the parameters based on some flimsy rationale. 3. Run some quick tests that are obviously designed specifically to confirm your expectations, declare victory and act like you've solved something.