We have a small development team of four members. Each of us has varying levels of skill and years of experience in the industry. As many of you know, years of experience are not directly proportional to level of skill, our team is no exception. I actually have the least years of experience on the team. The main problem I see is that we have no Team Lead or Architect that guides the overall development of the Product. Some folks would say that is a good thing and that Leads are a waste of time. That's true if you have a team of super stars or some other process that replaces the need for a Lead. Because we have no overall direction, what happens is we each go into our own little hole for the duration of the development cycle and emerge with disparate pieces of functionality that when cobbled together form our Product. Here is the makeup of our team:
- Mort - A solid developer who's skills have never been pushed to the next level.
- Jade - An excellent developer, the closest to what I would consider the team lead (but with no authority to say "Because I said so"), who's fed up with trying to improve the process.
- Primadonna - If he didn't write it, it's crap. He has nothing new to learn because he already knows the best way to do everything.
- Troublemaker - Gets into trouble because he always ask "Why...don't we have an automated build process...don't we write unit tests...don't have automated testing...don't have coding standards...do we tolerate bugs..."?
When I was first brought onto the team I spent a solid week looking over the code trying to get a handle on how things worked. When I came across poorly written code or pieces of functionality that didn't make sense the answer to my question was "Oh, that was written by Scapegoat, she left the company a year ago." No one understands the code and the code is extremely difficult to maintain because it was written in a vacuum. Any problem with the Product is because of Scapegoat. So why don't we fix it? "We haven't fixed anything that Scapegoat has done because we don't have time." When I question portions of the code written by Primadonna, the answer is "Well, I didn't have enough time to code it properly. I was just told to fix it."
I was tasked with improving the speed/performance of a critical portion of our Product. In the process I have refactored to separate concerns, write code that was testable, written unit tests, and done everything in a consistent manner. It's not perfect but it is progress. I realized today though that I am only perpetuating the problem. I have gone into my little hole and I am writing my own code and will emerge with something that will be part of our next release of the product. I can feel good because I know my contribution was well written, easier to maintain, has automated unit tests, and adheres to a standard. However this doesn't do the team any good because they have no idea what I've done. If a bug comes in it will automatically be assigned to me because that's my "subsystem." It may be easy to maintain, but only for me, because I understand the code, the tools, the unit tests, mocks, etc.
I can't fix our problems just be writing good code. I'd like to begin a peer/code review process to achieve the following goals:
- Grow the skills of the team. Explain concepts like how to write testable code. How to properly separate code so that each portion fulfills it's intended purpose. How to write unit tests. How to write good unit tests. How to use mocks. When to use mocks. Knowing when to refactor. How to refactor with confidence, IoC, ORM, good exception handling practices, implementing logging...etc.
- Cross training and TEAM ownership of the Product. That's not my bug because it was found in a piece of code I wrote. It's our bug and any one of us should be able to reproduce it, write a unit test for it, and fix it.
- Identify problems early.
- Collaborate on a set of standards.
- Foster a setting where members can demonstrate a desire to improve. If I see something I don't understand, I can ask for an explanation and learn something new. If I'm struggling with a particular feature I can ask for input from the team.
What I don't want our code review sessions to be is are technology workshops. I don't want to stand up and spend 30 minutes giving a presentation on IoC and separation of concerns. What I do want is for the team to ask "Why did you choose to use an interface rather than just write the class." I'm really not hung up on coding standards. What I'm more concerned about is seeing 1500 lines of code in the set accessor of a property.
I don't think code reviews are a long term requirement. I hope that eventually the skill level of the team will begin to see diminishing returns from code review. At that point we can have short standup meetings and spike sessions to hammer out particularly troublesome features.
I would love to hear from everyone else's experience using code reviews and/or alternatives to growing the team.
Technorati tags:
development teams
posted @ Thursday, March 08, 2007 11:38 AM