3 ms·

I kind of disagree with the premise here, from my own experience, it's much better to work fast but ruthlessly refactor and never be afraid to delete your own c

I kind of disagree with the premise here, from my own experience, it's much better to work fast but ruthlessly refactor and never be afraid to delete your own code. I find I rarely nail things on my first attempt, but by being quick and failing fast, I learn more about the problem domain and I end up with a nicer end result than the person that agonized about their decisions rather than trying things out. (Of course, the corollary is that I usually do these things on a branch so I'm not inflicting it on my coworkers) The problem with doing a big design up front is that you're generally going to run into something that's surprising, that you didn't account for (unless what you're doing isn't novel -- but then, why are you writing code rather than reusing it?) I think when people get all ponderous about these things, they're not really learning about the problem, they're just procrastinating. We're not building bridges here, if your first attempt isn't brilliant you're not out a million dollars of concrete.

cgearhart 12y ago
It depends a lot on the problem domain. Sometimes rapid prototyping is a useful tool, but the benefits rapidly diminish in the face of complexity. In my experience with moderately complicated scientific and mathematical software, there isn't anything to prototype - either it works, or it doesn't. If you aren't deliberate about design choices, the bugs can be really devious to find and squash.
- overgard 12y ago
  I think the implication of this article is that fast = reckless, but I disagree with that. Sometimes you recognize that you need more data points, and writing something that works will move you closer to the correct solution, even if the first version isn't perfect. But yeah, it depends on the problem domain. If you're asking me how to build a website, I can probably have a pretty solid idea of what that code should look like. It's not a novel problem, usually. If you're asking me to build, I don't know, a voxel renderer and you're trying to figure out if an octree is the right way to go for representing the data, or you need to do something more exotic, I'm gonna have to play around a bit.
snowwindwaves 12y ago
The author of the article also says he sometimes starts over. That his first attempts just explore the problem domain. There was a post about Jon carmack throwing out some "gross" code because as he worked on it he found the true crux of the problem and it reduced the complexity significantly. Almost an aha moment. Different problems take different styles to solve, but I see a lot of people on here have the same experience that quality takes time, if you get it on the first time or the third depends on if your environment can tolerate the intermediate steps.

cgearhart 12y ago

It depends a lot on the problem domain. Sometimes rapid prototyping is a useful tool, but the benefits rapidly diminish in the face of complexity. In my experience with moderately complicated scientific and mathematical software, there isn't anything to prototype - either it works, or it doesn't. If you aren't deliberate about design choices, the bugs can be really devious to find and squash.

overgard 12y ago
I think the implication of this article is that fast = reckless, but I disagree with that. Sometimes you recognize that you need more data points, and writing something that works will move you closer to the correct solution, even if the first version isn't perfect. But yeah, it depends on the problem domain. If you're asking me how to build a website, I can probably have a pretty solid idea of what that code should look like. It's not a novel problem, usually. If you're asking me to build, I don't know, a voxel renderer and you're trying to figure out if an octree is the right way to go for representing the data, or you need to do something more exotic, I'm gonna have to play around a bit.

snowwindwaves 12y ago

The author of the article also says he sometimes starts over. That his first attempts just explore the problem domain. There was a post about Jon carmack throwing out some "gross" code because as he worked on it he found the true crux of the problem and it reduced the complexity significantly. Almost an aha moment. Different problems take different styles to solve, but I see a lot of people on here have the same experience that quality takes time, if you get it on the first time or the third depends on if your environment can tolerate the intermediate steps.