Software Development

Handing off your project (without killing it)


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?

  1. I've tried touching their forehead and murmuring "Remember" before, but that didn't seem to work.
  2. 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.
  3. 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.
  4. 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?

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

7 comments
fdaugherty
fdaugherty

I like to socialize the ideas and concepts whenever possible. Provide relatable concepts in terms that everyone can remember. Such as, "this design allows for that Marketing person that wants to concentrate on the left-handed, blue-eyed people that live at 4 digit street addresses that end in even numbers." Now that is flexible. It also explains why the design seems more broad than the 2 or 3 programs we are running currently. Another suggestion would be to find hand off people that have similiar values and understanding of the projects. This is more difficult to do in our adult ADD world.

A contractor
A contractor

Handing off projects is a little like sending your kinds off to college. You hope you've doen your well enough that the project (and your kids) can survive any outside influences and still be recognized is yours. Then you have to let go into the hands of another and let them live their own lives.

Tell It Like I See It
Tell It Like I See It

In cases when you can think ahead a while (as much as a year out, depending on the system), begin grooming a particular person to take the job. Start by bringing them on board as a "junior partner" and have them handle some of the relatively routine updates -- such as changing text on a screen or web page. You still handle the major stuff. This begins getting them acclimated to the coding style you used. Over time, give this "junior partner" more and more responsibility for more advanced changes. At some point (when you feel they are ready), start bringing them into various meetings with the users, such as for requirements gathering. About the same time you begin taking them to requirements meetings (and other meetings as well), begin asking their opinion on design issues. At first, you'll have to point out a lot of issues they hadn't thought of (and you should point these out) and ask for a revised idea. Possibly even hint to them about an idea you had -- but do your best to let them figure it out themselves. Once they begin figuring out a design that you agree would work well, let them implement it in the system. Just as with the coding, let them start out relatively small and build from there. You still handle the large stuff initially; but over time the "junior partner" takes over more and more of the design work as well. You may be surprised once in a while. Sometimes the "junior partner" might actually come up with a solution even better than yours. If it gets to the point that this happens regularly, it is time for you to step aside and let the "junior partner" to take over the mantle of master. Hopefully the newly mantled master also learned some grooming tips from your bringing them up so they can begin the grooming process with their own successor. It is not always possible to do this for a variety of reasons. However, when it is possible, this can be a tremendously effective way to pass on the torch. The approaches you mention are like insurance, for when this grooming process can't be used or doesn't work. They can also help with the grooming process, perhaps streamlining something that would otherwise take a year down to a quarter or so (IF you get a really good "junior partner") so they can still be valuable. But they can't truly replace the grooming method.

wellsanon
wellsanon

Try involving those who will be responsible for the care and feeding of your baby long before the project ends. Make them part of the team... you can have them perform peer review, work up a maintenance plan with them, involve them in meetings while the project is still hot so that they don't come in cold.

Sterling chip Camden
Sterling chip Camden

One nice advantage to a two-person design team is that when one member moves on to better things, the other can continue with the project -- taking the whole thing on as their own. They can then train a protege to replace the one who left, and eventually take over in a continuing cycle. In my experience, though, it still gets pretty bungled by the time that third person takes sole command.

Sterling chip Camden
Sterling chip Camden

... and I have seen this work very well at least a few times. Unfortunately, more often than not (especially when you're a consultant) you don't get allowed that much time with your successor before they have to take on the whole thing. But it's good to keep this ideal in mind and try to emulate it as much as possible.

Editor's Picks