Separating rapid development from refactoring/optimization

Question

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:

1. Does rapid development on new features, with less care on code quality.
2. 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?

Answer 1

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...

Answer 2

Hi I think You Can not dive team into two groups.

@Guge Have covered financial and political impact on members of those groups.

And there are more:

1) Speed group will not care about quality of code.(They wont be paid for it!!) So they will produce ugly code.

2) Quality group will rewrite some code to be better. Speed group will add to this code some new functionality and again code will be ugly.

3) Speed group is about to add new func. to code that was not refactored. They do no refactors (they are not paid for it so management may be anger if they do, or if they work slow down) so they will create ugly^2 code at lower speed than if they refactor first.

4) No new func. mean no $$$ mean smaller wages mean worse developers assigned mean lower speed and quality.

5) Better devs will find a way to change goup to speed or a way to change work :)

5) If quality group will improve any subsytem speed group may deny implementing any patches to existing code to not slow down.

Ok So what to do to prevent such situation?

Talk with your managment, You need to maintaing balance betwen new func. and quality of code. Only good code allow to introduce fast changes or implementing new func. at high speed.

Good argument is that badly written code or architecture that evolved into something ugly is a debt. When you wont pay it monthly interest grow rapidly. You can afford to not paid one month probably but not longer.

You can get you credit card with you to emphasize.

And maybe if your team get too much work to do it in deadline it is always worth to speak it loudly. But carefully ;)

And all programmers should refactor and write testes (if relevant). No exception. Just refactor a bit today a bit tommorow etc.

Trick with credit card is borroved from Fowler "Refactoring" <- great book.

PS there are projects like "death march" where only pushing hard dev. make economic sense (because project will make money only if success in deadline with limited expenses; symptoms are constants work over hours with less dev than required) and my suggestions don't apply to it

Answer 3

I think that in the short term its not a problem for you to devote some people to new development, and some people to cleaning up the new code. However to keep this as an ongoing pattern is flawed. Your aim should be to get code delivered on time and to a high standard and your entire team should be working toward this goal, If you split the team then you have one half of the team writing exciting new features with no concern for code quality, and the other half cleaning up after them. Over time you may find that the cleanup team needs to be significantly bigger than the new features team.

Your first step (which you seem to have made some progress with) is to decide on what sort of quality your code is and how it is going to be measured (test coverage, cyclomatic complexity etc). You can then apply these metrics to your current code and understand how much of it doesn't come up to standard. This code is the code that has accrued 'Technical Debt' which needs repaying.

The next thing to do is to repay this technical debt. This involves bringing this code in line with the standards that you have put in place. This is a tedious task if it has to be done often, however it needs to be done, and to be done by anyone who is free to do it.

Finally make it your main goal to produce code that is in line with your quality measures. If a deadline shows up then you may have to ignore them for a while but once the deadline is met your priority is to get your code back up to the quality you need.