I had two major practices to put in place to improve our overall software development for this fiscal year.
- Implementing Test Driven Development with a target of 70% unit test coverage.
- Implementing frequent, lightweight code reviews.
Easy enough, on number two we’ve been fairly successful and will continue to tighten things up over the next year. Crucible has proved to be a good lightweight tool to help enable this.
On number one I suspect we’re at the same place a lot of development shops end up especially if they aren’t already XP shops. We’re doing a bit of TDD, but the bulk of the unit tests are written after the code sometimes days or weeks after the code. Thus we lose a lot of the design benefit. As a bonus it feels more like a chore when you write the tests later.
On a positive note, we’ve come a long way and the developers see many of the benefits of having a good set of tests around your code. And all pretty much all of the code developed this year had 70% or greater test coverage.
Next year is likely to see another goal of going from unit testing to TDD.
Checking in to source control should be done early and often. I’ve taken this as a given since my first early days working in CVS. (I still working in CVS these days as it’s a good enough tool.)
In a current project I got really busy with vendor meetings and other items during which time:
- Over the course of a week I saw only an occasional check-in maybe once per day.
- The check-ins were all by the same developer.
- There were a total of zero check ins by the other three developers.
My preference is to check in at least every hour or so when working. The only rule is it has to still compile and the tests have to run. If I have to I’ll even comment out a broken test so I can do a successful checkin.
An opportunity for group feedback next week.
I work in a decent sized application development division of a medium size company. Today I realized the bulk of our line managers haven’t yet pulled away from technical work to focus fully on management. Signs include:
- Attending almost all project meetings to weigh in on the technical architecture of the project.
- Personally conducting the bulk of all code/design reviews.
- Coding on projects on a regular basis.
- Utilizing the same team members for every project since it’s faster then ramping up others.
I know it’s a well worn cliche that many senior technical folks promoted to management fail to grasp that their role has changed, but I assumed that for many that was a temporary situation. After a year or two you learn to pull back on the coding role.
I think staying somewhat technical is important, but it has to be secondary to managing and developing your team, period. And assigning yourself technical work just creates a bottleneck.
I’m not completely beyond some tendencies myself:
- Having to fill in as a full time Scrum Master on an intranet project for 7 months is wrong and I’d rather have someone else take on the role. On the other hand it’s a very messy political and technical project so I’ve resigned myself to the role. I’ve probably missed a chance to mentor someone into the role.
- I’m still the resident expert on continuous integration which means if something crops up with cruisecontrol I end up troubleshooting it.
- I’m tempted to stay really involved in another project where I attended almost every meeting for the first Sprint to keep it from stumbling off track. For the subsequent Sprints I need to tone down my involvement. Better to let the team self-manage here and learn on their own.