4 ms·

I think most of what he says is correct, but it doesn't seem to address the actual problem I run into. The problem I see with my group's projects is not that we

I think most of what he says is correct, but it doesn't seem to address the actual problem I run into. The problem I see with my group's projects is not that we're trying to make it perfect. That almost never happens. Instead, management wants us to "just get it done," and "stop wasting time planning," and we end up with something that doesn't work well and is hard to maintain. Where a few days of pre-planning would have pointed out some areas where we were likely to get stuck and given us enough foresight to think up a better (but not perfect) architecture that we could implement in the time allotted. It still wouldn't be perfect, but it would be good instead of bad, which is what we end up shipping usually.

darkerside 9y ago
What I've found is that those days of pre-planning can be hit or miss. Yes, you might uncover a design flaw or missed requirement that would have set you off in the wrong direction. However, a prototype implementation is much more likely to uncover those same flaws, and probably also a few that you never would have found without building a prototype. I've found the prototype approach leads to a far higher likelihood of success. I think the real challenge with it is getting management to understand what is a prototype and what is a finished product, the danger being that you ship the prototype. Of course, this is all highly dependent of the nature of your work and length of development cycles. But if you're shipping in weeks, I'd wager you should be planning for hours at a time, not days.