Kim Burchett posted a link to a fantastic paper on his results with software methodology. I haven’t read the whole thing yet (it’s not really that long), but the first half is gold. He notes that there are many, many software development methodologies, and any of them can work for particular tasks… and any of them can fail for particular tasks. He goes on to describe that how people are encouraged to communicate on a project, and how people’s individual characteristics match the methodology is much more important to the success or failure of the project.
This is important stuff for me. I’ve managed one project in my life: IPC. It was a semisuccess. I certainly got our team to crank out something vastly more complex than any of them had ever done before. The problem was that… I did more than half of the work. I see my mistake now. I’m a good software designer. I make abstractions up the wazoo, make everything easier (if you understand how it works), extensible, etc. The trouble is that I don’t understand how to get others to understand my abstractions, or rather how to make abstractions that others will understand. If you look at the IPC code, you’ll see things like:
template <class Ty> class PValVal : public PVal<Ty>
These guys had just barely been introduced to inheritance, and I’m doing generalized inheritance with templates?! No wonder they couldn’t use it. I just figured they needed to learn more, but now I see that it was my responsibility to give them something they could work with, not their responsibility to work with my stuff.
Anyway, it’s been an enlightening couple of months. Maybe by the time I’m 30 I’ll be able to design like Dan Sugalski.