I’m working in a team of 2 front-end developers on a web-based late-stage startup project.
The site works quite well, but there’s a lot of room for improvement code-wise, as the code is quite messy and disorganized.
I would like to clean things up gradually by writing tests and carefully refactoring to avoid breaking anything. (Using principles from the book ‘Working Effectively with Legacy Code’)
However, the developer I’m working with is being given a lot of high-priority feature work, and I don’t want to burden him with maintenance tasks. A lot of the time he has to write messy code simply because of the time-constraints.
As the team grows I’m concerned about how to manage the different concerns.
I’m thinking of dividing the team into 2 groups:
- Does rapid development on new features, with less care on code quality.
- Writes unit tests, refactors code, generally optimizes things.
The result I’m aiming for is to bring as much of the code under test as possible, while still keeping up the pace of new-feature development.
Has this been tried before? Any thoughts?
There is a problem with dividing the team.
The group doing the rapid development of new features will be very popular with the sales force, and the management. They will be perceived as more productive, more solution-oriented and they will be included in more of the important discussions.
The group worrying about the quality will be perceived as costly, negative, unproductive, problem-oriented whiners.
The bean-counter reality of it is that the “easy wins” of the rapid group accumulates hidden costs of poor quality. If this goes on too long the code will become more and more messy as new rapid code builds on old rapid code and it will become more and more time-consuming and risky to add more features. Those hidden costs becomes visible when no one can add any new features anymore.
Think two years down the road. Your rapid coders will probably have moved on, cashing in on their many “successes”. The sales force will be talking about them, and how easy it was when they were running the shop.
It’s like weed in a garden. It’s easy to solve the problem early, much harder when it’s all weeds.
The engineering reality of it is that rapid coding shouldn’t be messy. You don’t save time by doing things messy. If it looks that way, there is either a skill problem or a framework problem.
So if you divide the group, rotate after every iteration!
And how do I know this, scenario so well? I came in after the “successful” coders had left…