Traditionally in projects I've worked on the developers write both the code and the JUnit tests. The developer will write some code, then write tests for the code he just wrote. This means that a developer will spend a portion of a project schedule writing the code, and a part of the schedule writing the JUnit tests.
I wonder if that approach can be improved. I'll use an example. Consider a software development project with six developers. One of the developers is also the team leader. The team leader both develops code himself and manages the other developers on the project. This example is somewhat based on a project earlier this year where I was the team leader with around six developers. Although this example refers to Java and JUnit, it applies to the general issue of code and formal code testing.
In the traditional model described above, all six of the developers would both write code and write JUnit tests for that code. I can immediately see drawbacks to that approach.
- Many developers at the code. That means more communication links, more coordination, more management to do. With more developers the team leader has to spend a lot of time keeping track of who is working on what, and managing the dependencies, and making sure people who depend on one another understand what the other person is expecting.
- When the team leader spends a lot of time managing, then he has little time for writing code. This is generally a bad thing. Typically a developer is made a team leader because he has shown technical ability in the past. If the better developers spend their time not programming and the lesser developers write most or all of the code that's not good. There's probably an antipattern around this. You want the most capable developers to write as much of the code as possible. It's hard to write code when you're managing people.
- With split responsibility of both code and JUnit, the JUnit necessarily cuts into the time a developer can spend writing code and informal scratch testing. The code is the most important product of a development project. I'm suspicious of activities that compete with and distract from writing code.
- Lack of visibility. If a developer writes some code, then writes some JUnit, and the code builds and the JUnit runs through successfully, well he's done right? I guess so, things seem to be done. However the developer has worked in isolation. You don't really know until you pull the pieces together if he did a good job with the code and the JUnit. After all if someone writes bad code, then the JUnit will likely also be low quality and fail to detect the problems in the bad code.
Well I think there may be a better approach than that described above. Instead of having everyone do both code and test, split the development team into two. Have a code team and a test team. The code team does all the code. They should do informal scratch and feature testing as they go, but not formal JUnit testing. The testing team does the formal JUnit tests on the code the code team writes.
Using the example above, the team of six would be a three person code team and a three person test team. The original team leader is the subteam leader code team and remains the overall team leader. One of the JUnit test team developers is appointed subteam leader of the JUnit team.
I can immediately see benefits to this.
- There are now only three people at the code instead of six before. This is good because there is less communication and dependencies between developers. There will be less misunderstandings and disconnects. There is less communication and synchronization overhead. The code development should go more smoothly.
- With less code developers, the team leader will spend less time managing and coordinating individuals. Thus he can spend more time writing code himself. This is good because typically the team leader is also one of the better programmers. You want your good programmers to spend as much time as possible programming.
- With a separate JUnit team, the management burden can be partly offloaded from the overall team leader to the JUnit subteam leader. This frees up the team leader's time to focus on writing code himself and managing the more important code project.
- There is more focus. The code people are not distracted with JUnit and are able to spend more time on the code development. The JUnit people are able to focus on doing a good job testing instead of just having it cut into more important code activity.
- Most software development sites aren't like Google. Instead of programming superstars everywhere there's more of a mix of strong developers, reliable middle class type developers, and people who tend to require more supervision (you need to keep this third group to a minimum, max 10% of developer head count, or you're in big trouble). By splitting the team up you can put the most capable people on the code team. Thus assuring a higher quality of delivered code. The rest can do the JUnit. If they do a mediocre job it doesn't really matter since the code will be solid anyway.
- Do you still need six people? With less synchronization and coordination among individuals, and the team leader able to spend more time programming, I don't think you do any more. You can now get the same job done with higher quality and the same schedule using only five people instead of six. Two JUnit people will be enough to do a good job. So that's a financial benefit to the company, being able to get the project done with five people instead of six in the original schedule.
- Finally, this way actually forces a real budget to be allocated for the JUnit. I've been on projects where the schedule was overambitious, and we were just told to "fit in" the JUnit on top of doing the code, even though the schedule didn't really even have enough time to do a proper job of the code. You can guess how much JUnit got done on those projects and the quality of it. By allocating a proper budget and resources for JUnit, it is much more likely to actually be done and a better job will be done with it.
Sounds good to me so far. Of course there are some hazards to this type of plan. I can see some political type problems from this. Some people are suspicious of change in general so a departure from established ways may meet resistance just because it is a bit different.
The other issue may be in the assignment of developers between the code and JUnit teams. Some people might not like the idea of developers being on a software project but being "relegated" to unit testing and not writing production code. One way to deal with this is to mix it up over different projects and have developers be code team on some projects and JUnit team on others. Or just deal with it and use it as an incentive to the mediocre developers to improve themselves to get on the code teams.
I think it's worth trying.
