Many of the projects I work on begin with me as the sole designer — and I think that’s a good thing. As Paul Graham points out, one key to good program design is the ability to hold the whole thing in your head. More than one head means hours and hours of trying to sync heads. Now, I have been part of some amazing twosome design teams – both people tuned into the problem space and generating great ideas off each other (shout out to Ken, Kevin, June, and Behrooz). Add one more person, and you get design by committee. Even with two, in the afterglow of those brilliant mind-melds you always have to divide up the remaining work to avoid stepping on each other’s feet. You need a piece that you own all to yourself in order to be effective.
But unless you want to get saddled with maintaining it for life, there comes a time in every project when you have to kiss your baby goodbye and let others take responsibility for its maturation from frolicsome adolescence through sensible adulthood and on to eventual senility. What kind of person will become the guardian of your precious progeny?
What if it’s that newly hired sparky young programmer who can hack anything, and usually does? How much of your subtle design will he massively re-engineer before he wakes up one day and says “Oh, that’s why they did it that way.” By which time too many new features have been tacked onto his hacks, and the old design can never be reconstituted. By the way, I have been that sparky young programmer myself more times than I care to admit.
Worse yet, what if it’s someone who not only takes great pains to understand your design, but even reveres it? Standing in awe of its genius, she does not consider herself worthy even to attempt modifications. When new problems arise that your design could easily be expanded to address, she therefore codes a separate solution. Your creation, worshiped as the king of design, becomes mummified and entombed within a protective mausoleum of immutable interfaces.
How do you find or create that person who will not only preserve your design, but adopt it as their own and let it grow within them?
- I’ve tried touching their forehead and murmuring “Remember” before, but that didn’t seem to work.
- Documentation can help some, but it’s often either too much for them to ever read it all before it’s too late, or else it’s too little to communicate the ideas effectively.
- A code walk-through might be a good plan, as long as their eyes don’t glaze over from information overload and they forget three-quarters of what you said as soon as you leave the room.
- Self-documenting code! To the degree that you can write the code to read like talking about the problem domain, you’ll avoid misunderstandings. But there will always be subtleties of design that no programming language (not even Ruby) can make obvious.
Help me here. What do you do to keep your design alive long after they’ve pried it from your cold, dead fingers?
No comments:
Post a Comment