Customer code coverage

The notion of code coverage is well known in software testing. In short, code coverage is the percentage of code which is covered by automated tests. The more your tests are able to "exercise" different parts of your code (e.g. enter into all its conditional branches) the better. 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 an actual customer feature request.

How much of your code has been executed at least once by one of your users/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 user/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. That would be an extreme case of premature optimization :-) .

I do believe that this "customer-driven development" approach is the best way to proceed in many scenarios, especially in early-stages of product development. It's almost impossible to guess right what clients will need or ask in the future so you may be better of not trying or you may end up blindly developing many features that may 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 users 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).