A Businessman's View

(Originally published by me on www.servicevirtualization.com ) Complexity yields defects In part 2 , we examined why SCRUM and TDD exhibit problems when measured from the perspective of the number of defects that they both yield. Before we can begin to understand why Service Virtualization helps address both of these reasons, it's worth elaborating on statements made in part 2. You'll recall the equation to the right, presented last time. c represents the degree of complexity, which has a direct correlation to the amount of code that must be written to meet the business requirements that yielded the complexity to begin with. Because t is fixed and c continues to trend upward (over several releases) then the number of defects will also increase over time. Therefore, t is the primary constraint around which everything else revolves. Expected number of defects In SCRUM , an increase in the complexity of an individual sprint or the total application expressed as ...

Classic physics... (Originally published by me on www.servicevirtualization.com ) In part 1 , we briefly examined the reasons why application development is challenged: namely, architectures have to be more complex to address the similarly more complex needs of the business.  We also briefly looked at the primary goals of Agile (SCRUM, specifically) and Test Driven Development (TDD) with the promise of further scrutiny to see why, although they take steps in the right direction toward better management of this complexity, they still fall short. The impact of increased application complexity is that there is an increased rate of change in all of the cogs and wheels that will (hopefully) mesh together to produce the final result expected by the business.  Over the same amount of time, this increased rate of change will yield more points where failure can occur.  And given the same distribution of probabilities, this will ultimately yield a greater number of defec...