A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
the more you sweat in peace, the less you bleed in war
to err is human, but the company policy doesn't allow it!
Putting it to software line, it translates to that as much time you spend designing your program, the lesser problems/reorganization you face while coding.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Stan James:
Be aware that this is a controversial point of view. Some projects like the Space Shuttle get fabulous results with lots of design up front (at fabulous cost) but others get by quite nicely (and very quickly) designing one test at a time.
I'd suggest you practice both ways for a bit and learn to travel as light as works for you.
Which probably has at least something to do with their ability to have well-defined and precise requirements. What happens when a client needs something, but they can't precisely define what it is? What if those requirements are changing in unforseeable and significant ways at a rapid pace? Spending too much time in design in that kind of scenario leads to nothing getting done because by the time the design can be worked out the requirements have changed, if they were ever truly defined to begin with.
to err is human, but the company policy doesn't allow it!