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:
- Heavy regression testing.
- Subtle bugs that surface only under production conditions, in spite of heavy regression testing.
Also, you have to invest upfront in:
- Selecting a suitable TDD framework.
- Training your dev team in TDD.
The payoff would be harder to pin down unless you take the following steps:
- Explicitly call out what benefits you are looking for.
- 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.