The notion of code coverage is well known in software testing. In short, it computes how well the test suite you are using to test the quality of the code covers all parts (statements/conditions/…) of that code. Obviously, the higher your code coverage the lower the chance of your software containing undetected software bugs.
Still, I’d like to argue there is an even more important metric when you’re starting a new software project customer code coverage .
Customer code coverage metric: percentage of your code written to satisfy a customer feature request.
How much of your code has been executed at least once by one of your clients? And how much of your code was written thinking that a client would need it, and you’re still waiting for that need to appear?
Of course, as for all code coverage criteria, the goal would be to reach a 100% coverage, i.e. all your code should come from understanding and responding to the real needs of your clients. This would mean that all the code you’ve written has been developed to satisfy the needs of at least one client. No pieces of useless code in your software. Imagine the cost of maintaining (evolving, refactoring,… ) blocks of code that in fact nobody has ever executed, not even once.
I do believe that this “customer driven development” approach is the best way to proceed in many scenarios. Since it’s almost impossible to guess right when thinking what future clients may want, it’s better to wait and see what they ask for instead of blindly developing many features that maybe will never be executed.
A completely different discussion is how many clients should ask for a given feature before you decide to develop it. Probably the number goes up as the tool matures. It also depends on whether those interested customers are ready to put the money where their mouth is and fund this new feature upfront (this would be especially beneficial in open source projects).
