Posts Tagged ‘metrics’
I would define MDD as a practice where metrics are used to drive the entire application development. In a company which uses MDD, everything from performance and usage patterns to revenue is measured. Moreover, every single decision taken by developers, operations or even business people is based on metrics. Metrics are used to monitor team performance, solve performance bottlenecks, estimate hardware needs or to accomplish other purposes at any stage of development life-cycle.
The beauty of MDD is that it also keeps misunderstandings to the minimum. When a decision is taken based on metrics, there’s hardly any room left for interpretation. Decisions become obvious, logical and simple to explain and thus hard to refute. Decisions are made more quickly and accurately and even the atmosphere in the team improves considerably. Moreover, this has a cascading effect that crosses team borders. Communication between them becomes less emotional and more data-driven. In other words, the blame game that sometimes arises between DEV and OPS or between multiple DEV teams is brought down to a minimum or even completely disappears.
Some interesting snippets:
…What’s interesting here is that we were able to spot this defect using cyclomatic complexity rather than code coverage. Code coverage indicated we were done after one test case, but CC forced us to write an additional one. Not bad, eh?
Luckily, the method under test in this case only had a CC of 2. Imagine if that defect were buried in a method with a CC of 102. Good luck finding it!
…As demonstrated above, cyclomatic complexity is a good indicator of code complexity; moreover, it’s an excellent barometer for developer testing. A good rule of thumb is to create a number of test cases equal to the cyclomatic complexity value of the code being tested. In the case of the
updatePCensus() method seen in Figure 2, you would need 114 test cases to achieve full coverage.