How much overhead for code-review , test driven development , refactoring

Question

If i work in a software team which is typically driven by delivery, and if we want to study the introduction of peer review, test driven development and refactoring, how much time delay can be expected in a typical delivery cycle ? Would it be 30% slower, costlier ? Would it reduce over time ?

I find that most managers want to introduce these but are under time and cost crunch and so do not introduce them.

Thanks.

Answer 1

I find that most managers want to introduce these but are under time and cost crunch and so do not introduce them.

Sadly it is the norm that there is always time and money enough to fix problems but never enough to do things right the first time.

If you want to build a business case for peer review etc ask yourself how much it is costing your organization in time and effort and customer dissatisfaction to fix problems that are identified after delivery. I would wager that adding peer review into the mix would be cost and time neutral at worst if you look at your systems end-to-end.

Answer 2

how much time delay can be expected in a typical delivery cycle?

There is no pre-determined number which can be attributed to delays but it is certain that introducing these elements into your current process will reduce team's velocity and delivery, at least in the short term. This number may vary from company to company and team to team based on skills, cohesion, culture, and environment.

One suggestion would be to introduce these items one by one instead of starting all of these items at once. Include one such improvement into the process and measure its impact on velocity and delivery cycle. Let it go on like this and fine tune it according to your needs and situation. Once the team has a good handle on it, introduce another process improvement and repeat the cycle.

These measures should be considered an investment. Delays due to such measures would give you profits in the future in terms of better quality, less headache in code maintainability, evenly distributed code knowledge in the team, etc. Some of these items such as Refactoring are essential. Regular refactoring should be part of your delivery estimations. Sometimes it is necessary to refactor code in order to implement a new feature. You cannot (rather should not) ignore it in favor of feature delivery, otherwise it is going on haunt you in the long run.

Answer 3

I've been part of the introduction of Test Driven Development (TDD) at a previous company and 30% was a good thumb suck for how long it initially took, however the reduction in defects discovered in Test and then release was significant and sold the entire dept on the process.

Over the next few projects it did reduce but not by any great amount (perhaps 5%), however the defects remained at a much lower level than other projects and freed up the developers to do more work rather than be bogged down in BAU defect resolution.

I cannot say how it worked in the long term as I moved on and in my current workplace they do not use TDD.

Answer 4

You can reduce post-release issues and make changes with confidence

how much time delay can be expected in a typical delivery cycle ? Would it be 30% slower, costlier ?

We were in a similar situation in one of my previous assignments. When one of the deployments caused a significant disruption of service, we did a retrospective and decided that peer review was the only way to catch those kinds of problems. The cost was only about 10 to 15%. However, we were able to see the payoff in the increased confidence level with which we were able to deploy and fewer post-release issues.

Test driven development and refactoring are a different kettle of fish. For one thing, you don't want to venture into refactoring unless you already have unit tests written for that part of the code. Otherwise, you will end up with:

1. Heavy regression testing.
2. Subtle bugs that surface only under production conditions, in spite of heavy regression testing.

Also, you have to invest upfront in:

1. Selecting a suitable TDD framework.
2. Training your dev team in TDD.

The payoff would be harder to pin down unless you take the following steps:

1. Explicitly call out what benefits you are looking for.
2. Implement it in one app or one module and see how it compares with the others.

Would it reduce over time ?

Not really, except from climbing the learning curve. But, the production issues and the consequent fire fighting should go down. If you have QA testers, they can focus less on code coverage and more on user experience, performance testing and so on. Also, developers can take on code refactoring with more confidence.