One of the things that we deal with on most software projects that continue on for a few years is turnover. People come and go. I'm not sure it's more prevalent with the software industry than others, but it is painful. As managers we spend a lot of effort making sure transition plans are put in place when it happens so that the asset that is the developer's knowledge isn't lost.
Unfortunately, we haven't done a good job of that with the CDT. We have a number of instances now where developers work hard and put in a great complex framework to solve a really complicated problem. We really appreciate the contributions to make the CDT better.
But stuff happens. The developer gets put on other projects or leaves the company that was paying him to work on the CDT, and poof, the detailed knowledge of what they were working on is gone. But since we don't really have a manager/employee relationship with them, it doesn't really cross our mind that we need to manage the transition and make sure we capture that knowledge. And maybe we should.
The other side of the coin, though, is that developers love what they do and want to do it forever, especially on exciting projects like the CDT that are doing good for the world (or something). I'm not sure they consider the possibility that they may get pulled off the project and they don't spend the time to properly document what they are doing so others can pick up the pieces. Or worse, they try to be very clever in their solution making it more complicated than maybe it could be, and certainly difficult for downstream maintainers to understand.
The concern I often hear from them is that, since it's open source, their employers don't give them enough time to do everything you would on a commercial project. And we were also going through a phase where we needed contributions badly and didn't consider it prudent to enforce that documentation be provided. But we're definitely paying for it now as we have a pretty big bulk of undocumented code that we're trying to fix bugs in.
So the lesson of the day is to code like you won't be there tomorrow. You can create the best system ever, and people will appreciate it while you're there, but they may end up cursing you if you disappear and leave it in their laps. At the very least, they'll be wishing you could come back.
You are clearly a manager who
ReplyDeletedoes coding by himself! :)
Sure I know you do - but one
can never train a non-coding
manager about this issue such
that he *really* understands
the worth of transition and
documentation. I would add:
communication - so people
talk to other people before
they get deep into coding.
P.S.: For me one of the relevant
buzzwords from extreme programming is "shared code ownership".
That's true. One of the key problems we had was the diversity of culture amongst the CDT committers. We tended to bring ourselves to the lowest common denominator. But then you end up with pretty much no process at all.
ReplyDeleteBut then I've been watching another project at Eclipse that has a heavy process and it makes me not want to get involved. Too much overhead for my taste.
Which goes to show that, being the project lead, it is my responsibility and I really need to do more to fix this.
Historically, we have not worked this way though. ;-)
ReplyDeleteJohnny, come back! ;)
ReplyDeleteJob security man, all about job security ;)
ReplyDeletej/k ;)
My philosphy has always been, "Code -- and document that code! -- like you know you're going to be hit by a bus tomorrow."
ReplyDeleteSure, there's job satisfaction in being the go-to guy, or the only person who knows a piece of code, but damn that's boring. If it's well-written (and well-documented!), one day you can move on with the knowledge that you won't be burying your successor under a mountain of pain.
(I suppose this comes from having been a co-op student who had to pass the metaphorical keys to another student knowing that in 4 months I'd have to take them back. By 'paying it forward', I hoped that I'd also be handed something easily approachable when it was my turn again.)
Totally agree with your comments, but in order to make that a reality, developers need to find as much joy and excitement in documenting what they are creating (and not just at the code level, but at a system and rationale level) as much as creating it.
ReplyDeleteIts the old software development: Art or Engineering debate?
Artists don't concern themselves with anything that will block the creative flow ... engineering decisions are calculated choices that can be documented and explained.
One might argue that if it was art, it wouldn't need explaining (or documenting) -- it would be self-evident. Maybe it's abstract art? ;-)
ReplyDeleteAs to finding joy in documentation, really, for me, it's about finding joy in easing users' adoption. Because if you build it, they will come... but if it's not easy to use, they will go.
Another great advantage of documenting your code, is that you can move to another interesting project, even if you stay in the same organization.
ReplyDeleteIf your code is well documented, somebody else can pick your job, and let you free to work on the next cool feature / project.
Otherwise, your boss may never let you work on that next project, since you're required to maintain the current / old project.
So, making it easier for somebody else to replace you may be a good thing!
In fact, you know, you might be happy about the docs yourself - a couple months down the road ;)
ReplyDelete