I pretty much do this but also write an outermost skeleton too. There's usually some piece or pieces that you have to know how they'll work before you can really do anything. Also, I get some data/input to feed to my empty shell of a program and even just to look at before I've done much of anything. (But, then, after a while, you still have to write the darned thing.)
update: Oh, and get something visible running soon (for some definition of "works"), then you have the confidence/support to take the time to get it right. Otherwise, no one can be sure anything's going to come of it.
p | [reply] |
I take a similar approach, but even one step further.
On large projects, I first write the meat of main man pages - consisting mostly of overall functionality, command line switches, etc.
Then, assuming an OO project (in Perl or C++ -- and most large projects should be OO, imo), sketch out each object, and all of their public methods!
For me this usually entails writing the document for the use of the class/module.
I can't stress enough how critical this is on large projects, especially if you are, or will be working with others.
On countless occations I've seen classes/objects gradually morph as the project progresses... eventually into hideous monstrosities. This is always a direct result of bad planning, or a lack thereof.
ClassA, for instance, doesn't quite click with a part of ClassB.. so each add another method to fit together more cleanly. Then ClassC comes along and requires a bit different output from each of those, so A and B get new member functions that wrap existing ones, to return a bit different.... and so on and so on.
If all components of the project are first mapped out, and their external interfaces designed in detail, all that is left is sticking the code in - and when these components are first mapped out, the coding usually is about 10% of the project. | [reply] |
