I was in meetings most of this last week at work. Meanwhile, one of my co-workers was learning a new style of programming--and thus was trying to learn about four big new things at once. She sent me emails, but I was slow to answer; I was in meetings. Days passed; she could read documentation, she was a quick study, she was learning a lot... but wasn't learning the things that would help her, you know, get started doing stuff. Before you know how to get started, you're not sure which things to study to get you started. On Friday afternoon, I sat with this one co-worker. I didn't tell her much--but I steered her at what she needed to get started. Soon afterwards, she was set up with her development environment, had a "hello world" going, was ready to apply some of that stuff she'd read about. Such a difference. Face time speeds things up. Except, of course, that it won't help the next person who wants to learn those four big new things.
How do computer programmers learn? Though it pains this professional tech writer to say it--they don't learn much from documentation. There's gossip, but that only gets you so far. There are so many different kinds of things to learn: general tradecraft, programming languages, project-specific knowledge... The project-specific stuff is especially tough to learn, because you're probably rewriting your project's code all of the time, pulling the rug out from under your own feet. In Knowledge Sharing in Software Development the author, Jan Chong, studied two teams of developers organized in two different styles to watch how job-knowledge flowed within each group.
(Yes, puzzle huntists, that Jan Chong. No, I probably wouldn't have heard about it if she wasn't a puzzle huntist.)
One of the groups followed the Extreme Programming cult, the others were Waterfa-- Hey, come back! This is not a Book on $foo about how $foo is better than the Waterfall strawman.
This book is Jane Goodall among the Geeks. Except that the author is a geek herself, and understands what's going on a lot better than Jane Goodall understands chimps. So when she took notes, she didn't say "Vocalizes technical knowledge, wish I could understand it." She said, "Desire to project technical competence." Oh yeah, how many times have you been stuck in that conversation.
The book doesn't start out seeming useful. It starts out in full-on academic mode. No sentence escapes without citing a couple of sources.
"Work has changed significantly over the past fifty years, moving from a workforce predominantly based on manual labor to one that is increasingly based on knowledge work (Drucker 1993; Elliasson 1996)."
It's not just that, as an academic, one has to cite sources to back up a statement like that. It's that one has to state a statement like that in the first place or risk getting questioned on it by some professor type who doesn't even know what it's like to work for a living these days. Halfway down page 2 of this, I nearly gave up. But I riffled ahead and saw
The Waterfall programmers also invited me to several team-wide social events in the course of observations, including periodic board and card game nights (e.g., playing Robo Rally, Chez Geek, Guillotine)...
Well that was more accessible. And I couldn't help but notice that the list of games didn't say "Robo Rally (Garfield, 1994), Chez Geek (Darbro, 1999), Guillotine (Peterson, 1998)" So, OK, first few pages have plenty of citations to remind the committee that a sufficiency of past reading has gone into the work. But you don't really need to slog through much of that to get to the real work. And there's good stuff in here.
The book describes the behavior of two groups of programmers. One group is a team of Extreme Programmers--they pair-program, forming new pairs each day, all sitting in one big work area where everybody can hear everybody. One group is a team Waterfall programmers, each sitting in an office with a door, where every bit of intra-team communication requires effort. The book looks a lot at the social networks that formed. But that's not what I focused on.
I focused on this snippet about the XP programmers:
...the practice of pair programming made visible the process of reasoning inherent in code construction, a process normally only available through post hoc accounts and code inspection. Through pair programming, the process was made available in situ.
They developed code faster because they all looked at the same code. They rotated between areas of the code. No one was the "datastore expert" or the "security expert" or the whatever expert--they all wrestled with all parts from time to time. They didn't need to comment or document their code so much--because they could talk it over with each other.
They produced code with little documentation. Like most code, it didn't make much sense--but if one of them didn't understand it, they could always ask someone else on the team. Then again, if someone who wasn't on the team didn't understand it... that person would have been out of luck. The XP programmers were happy to be oral, because they didn't need to slow down to explain things. But heaven help you if you wanted to understand their code and you weren't on the team. The XP team checked email once a day; didn't answer their phones. They spent time with the team, no distractions... from, say, the people who were stuck maintaining the code the XP programmers had previously developed.
...on the XP team, specific program code changes were actually quite opaque outside of a given pair.
Yeah, I bet.
So... the good news is that the XP team developed code very quickly by working all day, ignoring the outside world, and not trying to make their code understandable outside of the team. The bad news is that they ended up with some semi-understandable code. By working in pairs, they made sure their knowledge was distributed between their brains but that also made them less likely to capture their knowledge where someone else could read it.
Of course, most of the time that the Waterfall team puts into recording knowledge is wasted.
You re-write code so many times over the course of a project, it's a waste of time to explain how any of it works--until you're ready to share it with somebody else. They track so much crap, most of which won't help future maintainers.
What would be the best of both worlds? How do you get the team to work together well, but make sure that they explain their work before they hand it over to the outside world? You almost want to set up an XP team--and then geographically split them up in the last few weeks of the project, force them to clarify things, nudge them to capture the knowledge that they use to clarify the code to each other. Just remember: that explanation you emailed to your co-worker probably also makes a dandy code comment. And the very fact that one co-worker needed that email suggests that patch of code isn't as self-explanatory as you hoped.
(Yes, training-minded co-workers, I have this book at my desk and you can borrow it.)
Labels: book, programming, research