Post-Mortem on This Term’s Work
December 23rd, 2008
As I’ve mentioned several times, we’ve started rebuilding DrProject on top of Django. We had a post-mortem last Tuesday on our first term’s work, which Blake Winton was kind enough to summarize. The highlights (good and bad) are listed below.
Good
- Everybody gave more than expected/requested/paid for.
- The team produced some remarkably clean code in a very short time, especially given its prior lack of exposure to Django.
- Distributed collaboration worked much better than expected. (The team was spread across four universities in three countries.)
- The dev and commit mailing lists worked well, as did weekly status meetings on IRC.
- Regular, frequent, small commits went well/were a good idea.
- pyflakes and pep8 were great tools for checking code and style (but it would have been nice to have a script to run both on all files in one command).
- Code reviews rocked. (Author’s note: this was the best part of the term for me, and something I’m going to want to encourage in my undergrad software engineering class next term.)
Bad
- Tempers were strained occasionally during reviews and design discussions (more considerate language should have been used).
- Too much juggling people from one sub-project to another. (Author’s note: this was my fault.)
- svnmerge was a pain. (Author’s note: one developer was a real fan of distributed version control systems, and kept trying to move us in that direction. I should have resisted more strongly.)
- The project blog wasn’t used effectively—it was never clear what should go in the blog vs. on the mailing lists.
- People sometimes didn’t know what they should be working on. (Author’s note: also my fault—next term, the newcomers will be given a couple of short, specific tasks at the start to get them up to speed.)
- The release process kind of fell apart, the code freeze never really happened.
You said merging was a pain, but should have resisted DVCS more. The one thing the DVCSs are very good at is merging so your statement appears contradictory.
Roger, then there would have been another point in the “Bad” : “Students needed a lot of time to wrap their heads around DVCSs and use them effectively”.
I should have written the point out in full: there’s nothing wrong with distributed version control systems per se; trying to use SVN *as if* it was Git, Mercurial, or something like that was the mistake.
But on that note: if anyone has any empirical data of any kind showing that DVCS’s make any task faster or less error prone, I’d like to see it. (I’d also like to see any that indicates DVCSs are slower or more error prone, too…)
Regarding code freezes … before we started releasing on a fixed, semi-annual schedule a few years ago, we often had a hard time getting our releases to converge. After the code freeze was widely and blatantly ignored during one release, I decided to appropriate the term for a different purpose. Now, whenever I send a calendar invite to our team for a “code freeze,” it means we are going out to Ben & Jerry’s for an afternoon ice cream.