Centuries ago, English communities would walk the little boys around the perimeter of their parish as a way of preserving land records. This was called “beating the bounds.” The idea was that by teaching the boundaries to someone young, the knowledge would be preserved for the lifespan of that person. Of course modern geological survey techniques make beating the bounds unnecessary.
Software development hasn’t reached the sophistication of geographic survey. Many software shops use a knowledge management system remarkably similar to beating the bounds. They hire a new developer to work on a new project. That developer will remain tied to that project for the rest of his or her career, like a serf tied to the land. The knowledge essential to maintaining that project resides only in the brain of its developer. There are no useful written records or reliable maps, just like medieval property boundaries.
Update: Here’s a response from Johanna Rothman about how to avoid medieval project management.
{ 1 trackback }
{ 4 comments… read them below or add one }
John Venier 08.22.08 at 09:02
Yes, that’s common and bad. Even the method of transmission is similar — take a new developer and walk them through the code and build / deployment process.
Years ago I spent some time as a chemical laboratory technician. The same held true for them. There were official protocols as to how to perform certain laboratory tests but they were at best incomplete and at worst outdated or just plain didn’t match the actual practice. The chemists ordering the tests were aware of this — well, at least the experienced ones were. One old boy had been a chemist for over 40 years, and he said he learned early on to go talk to the technician actually performing the tests. He would say, “I know the protocol and have read it.” Then he would grin and conspiratorially suggest, “Now show me how you _really_ do it.”
Sarah Edmonson 08.22.08 at 10:23
Yes, I was recently downsized from a position after only 6 months there. I spent the first several months just figuring out what my predecessor had been doing… then the company hit a rough spot financially just as I was starting to get some real work done. My gift to that company: as I uncovered issues and developed plans to solve them, I documented like mad - so when they’re able to afford someone else to take on the job, perhaps the new person’s ramp-up won’t be quite so steep.
KoenD 09.02.08 at 03:24
Recently my previous customer (a software company) had given me the message to look out for a new project (I wish every customer could inform me three months in advance). Things were not going that well
for them. So I did look for a new project.
One of their customers was informed that I was going to leave the company and they were looking for someone with my profile.
So eventually, they let me work for them (mainly because that customer really pushed). All three parties agreed that - when they needed me - they could call me to ask to come to their office.
And this is actually the case once every 3-4 weeks. Then I need to go explain something or develop something personally as I have worked there for 5 years and of some projects only I know what’s going on under the bonnet.
You could ask yourself if maybe I didn’t do my job sufficiently as almost nothing is documented (or documentation is outdated).
Well, let’s say that there was just no time for that. Every development was planned and measured in terms of development: no testing budget, no documentation budget. I brought that up one day and they asked me if I was crazy (as if the customer would want to pay us to test software we had written ourselves!)
I found that to be a very bad attitude. Testing and documentation should always be a part of a project (budget) imho. Call it overhead, call it what you want. But for God’s sake: include it in the scope of the project!
If not - which is exactly my point - they will remain dependent of me and it will create situations like this where they have to call me from time to time because they need my help.
And I am not the type that wants to be kept hanging on a string. When a job or contract is finished, there should be no open ends…
PM Hut 10.12.08 at 12:17
I’ve seen this everywhere, especially for internal projects.
Documentation helps but is not the key, you cannot document every line (otherwise the whole source code would be cluttered). Sometimes the developers take pride in writing complicated code, or sometimes they just don’t feel the need to give functions/variables meaningful names that will make the code readable.
Try telling a developer to comment his/her code or write a more clearer code, and see the look of skepticism in their eyes. Check this article on testing in Project Management, although it is aimed at the testing phase, it highlights the Programmer’s Ego.