Earlier in the month, I blogged a response to – “What would you say is the average percentage of development time devoted to creating the unit test scripts?”. As I was telling a friend about it, I realized that I missed an important point!
The question also implies that development time is constant. Or maybe not. But if I tell you that I spend X% of my time on creating unit tests and your project currently spends Y time on development, I imagine you are considering the development time with unit testing takes Y + Y*X.
However, this isn’t the case. The real time is Y + Y*X – Z where Z is the time saved in finding the defects in the code faster. The benefits span past the current project, but this factor matters even if one just measures within the current project.
Or another way of expressing this is that “your Y is different than my Y.” My time on development has been adjusted by creating software in a different way.
This seems like a convoluted way of expressing it. Has anyone come across a better explanation?
Pingback: a response to – “What would you say is the average percentage of development time devoted to creating the unit test scripts?” | Down Home Country Coding With Scott Selikoff and Jeanne Boyarsky
Jeanne,
In your formula, I believe the Y + Y*X represents the real time to complete an application and have it ready for production deployment. The Z factor kicks in after the application goes into production and now it’s in the maintenance mode.
The Z is affected by Y*X; the more time is spent on unit testing (represented Y*X) the less time it takes to troubleshoot and fix the problem (represented by Z).
I believe that relationship is not shown in the formula.
Regards
I disagree. The cost of maintaining an app over time is more complicated. Which is why I didn’t include it. I think that having tests in place minimizes long term costs, but it can’t decrease them to less than zero.
Unit testing in my experience usually replaces most of the time blocked off for debugging. IF people actually planned for debugging, which they don’t. So you replace an activity that’s unplanned, unpredictable, and often frustrating, with one that’s planned, predictable, and constructive.
I believe unit tests are usually overrated as a testing and maintenance tool (the dirty little secret is that often they cost more to maintain than they are worth), but underrated as a development tool (where they are one of the most efficient ways to find and fix initial bugs and design flaws).
Scott,
Good analogy on debugging. Of course since debugging isn’t planned for, it doesn’t get measured or accounted for.
I have seen tremendous value with unit test as a testing/maintenance tool. Poorly written/tightly coupled ones, not so much. But good unit tests do help down the road.