hmm. i just said this another thread. but i think it's worth saying here, too.
i don't mostly design programs and then code them. i code them and then i design them. i say, mostly, and i mean that, not by any means always.
what i mean is that i'll do any old damned thing to get it to do what the customer wants it to do. once i have that, i then -- don't go all glassy-eyed on me -- listen to the code, and the code tells me what the design will be, and i design it that way.
along the way, of course, i have "go to" patterns i use, based largely on 40 years of geekery. some of them are the ones whose names you'll recognize, others not so much. but i just use those mostly as, idunno, framing tools to make it easier to make the stupid thing run.
a for instance, i'm pretty fastidious about separating model & view as early as i can reasonably do so. but i just do that cuz it's easier for me -- for me, in particular -- to move when i work that way.
maybe it's like this: those patterns i use to organize my work on the way *in* to getting it to run are like cranes and steam shovels and earth movers. i'm using them to make the hole, and i use them cuz they make me -- me, in particular -- faster.
it isn't until the digging is done that i can really tell what the design should be, and even then often only in fits and starts, some of them angry fits, and some of them false starts.
one thing i have learned over and over again is that my idea of what the code's gonna be -- my starting design -- is almost always grossly out of line with what the code winds up being -- my ending design.
you would think this would make me feel bad, being so wrong all the time, but it doesn't. it's quite liberating, actually, cuz it means i don't have to agonize. i just make a call and roll some code based on it.
this way, i get to stay detached from the design when i'm on the way in, and that detachment makes it much easier to see what's there, as opposed to what i imagined will be there.
tho most people know me as wildly verbal, i'm not actually a mostly verbal thinker. i think best by standing at a whiteboard and drawing and talking. i spend a lot of time at the whiteboard. but here's the thing, i spend more time *after* i have it working than i do *before*.
one of our old xp mantras is DTSTTCPW, which means "do the simplest thing that could possibly work". i don't sloganize much, and i'll be the first person to point out that most of the words in that one are vague subtle judgment calls....
...but that's pretty much what i do on the way in. i think of something that might do the trick, and i try it. if it works but the story isn't done and i'm not totally disgusted with what i did, i keep moving. if the story's done, or i'm grossed out, i stop & design what i did.
i wonder what some of my old-hand geek friends do, if they feel the same way?
