Slaying the Scary Monsters
I don't have a definitive answer, and I haven't entirely decided how to do this on day-to-day or sustainable terms. I've found myself relying on various things to begin this process of cognitive ordering. Basecamp couldn't do it all, so Jay and I threw together Labs Code in an hour or so. There are still plenty of other things that Labs Code can't track, so I started throwing things like meeting minutes I typed up in various places. I keep dreaming of one big bucket to capture it all, but there's none in sight. I also keep asking myself the same set of questions over and over again: "Other people do this here, right?" "Why can't we do this collectively for every one of our projects?"
I don't have an answer for these questions either, but I've been looking for answers elsewhere by reading voraciously, as is my wont. I recently finished Scott Rosenberg's Dreaming In Code, and I'm almost finished with Frederick Brooks' The Mythical Man-Month. These books are both inspirationally and terrifyingly educational as I watch scenarios from both of these works play out with projects here.
Dreaming In Code describes Mitch Kapor's project to put together truly revolutionary, open source PIM software (hey, knowledge organization!). The project resulted in Chandler, which just hit 1.0 last month. It's a fair characterization of software development between the idealization of wanting to get something cool out the door and the reality that you can't really get anything done without a clear idea of what you're supposed to be doing. Rosenberg invokes Brooks' work repeatedly, as we watch the Chandler team run into the full force of "Brooks' Law" over and over again: Adding manpower to a late software project makes it later. Brooks reworks this into a more comprehensible statement: Adding people to a software project increases the total effort necessary in three ways: the work and disruption of repartitioning itself, training the new people, and added intercommunication. As Labs grows, I see (and have seen) us getting tripped up in the same way.
The twenty-fifth anniversary edition of The Mythical Man-Month also reprints an essay entitled "No Silver Bullet -- Essence and Accident in Software Engineering." Brooks warns us that "there is no single development, in either technology or management technique" that will reliably make software development run more smoothly. However, the rest of The Mythical Man-Month provides a fair number of suggestions on how to organize people and information to make things run slightly more smoothly.
I understand that any methodology might not be our silver bullet for slaying the werewolf, but we need to start somewhere. Clearly defined specifications are obviously not fun to write, but everyone feels better once they're done. It's easier to put tangible deadlines on things when you know all the constituent tasks. In addition, I know that I'd greatly benefit from having project managers around to resolve disputes or help me get resources when needed rather than me having to do that and, so to speak, be on the shoproom floor.
The final question for the time being is how to begin this when you've only had only occasional contact with this sort of thing. I never worked as a developer before, and I know I can't just waltz in and begin espousing Scrum or whatever. How do you begin writing specs when you don't know how? How detailed do you go? It's clear we need them, though, because the werewolves, vampires, and demons have been stalking us for far too long! If we can't find our silver bullet, let's band together and at least build some pitchforks.
2 Comments
The kobold chieftain shall not be defeated by the likes of you.
Mark,
You make some really interesting points. I think it is especially hard when new teams are created with staff with a variety of skill sets and equally various backgrounds. I am not sure software has much to do with it. Seems to me that teams form in stages and that a lot of the early work is learning how to best work together. However, I am assured by a whole host of Operations Research folks that the most self-sufficient, productive and satisfied teams are those that are comprised of members who represent a wide variety of talents and who are willing to work through the initial rough patches.
I agree that project management plays a key role in work flow and information sharing but I also think that not all teams need managers in the sense that the phrase "project management" suggests. Some teams need more guidance than others and some teams need no management guidance at all.
I am sympathetic to your desire for control over the process. So one of the things we all need to do is get together and talk about the needs of the various players in DEG and see if we can come up with a variety of tools that can help meet all our needs. --bt