This blog item I have dedicated to zoom in on Bugs, a specific type of Waste (muda which is Toyta lexicon) aka DEFECTS as they have a huge effect on Productivity.
But lets start with the Analysts and their magic 8-bal that has shown them that Lean Software Development will become the hit of 2009.
Bloated applications, platforms and architectures slow application development and make QUALITY CONTROL and everyday usage time-consuming and nonproductive, said Forrester Research principal analyst John R. Rymer. Forrester’s newly-published report, Lean Software is Agile, Fit-to-Purpose, and Efficient, lays out how software got so fat, costly and inefficient; the evidence that IT organizations are moving to lean software; the challenges involved in lightweight software development; and strategies for joining the movement.
There is a lot to say about Lean Software Development as I already mentioned in my blog item on the REAL cost of Offshore .
The best you can do is to read the book of Mary and Tom Poppendieck and of course The Toyota Way. The XP, Scrum and even some RUP adepts under the readers they know that it is all about being Agile (whatever it means).
“Agile development is independent of any technical platform or development approach “It’s a method. What’s neat about this is that people are delivering application features sometimes every two weeks or each month. Rather than deliver the big-bang project after years of work, they’re delivering applications in increments. They’re working in an incremental fashion to deliver features over time, providing value quickly and continue to add value. That’s a way to modulate your costs, to spread your costs and investment over a period of time.”
And Yes, it`s not easy to break through old habits as I know by experience that companies are really good in adopting RUP and then transform this iterative methodology into a Waterfall approach.
What have DEFECTS to do with AGILE development and Offshore?
Partly taken from Yourdon Report on a presentation that Michael Mah(QSM) gave at the New York City SPIN group.
Assume, for the moment, that you’ve got a software development project where the end-users (or customers, stakeholders) and the developers (i.e., programmers, architects, database designers, business analysts, QA personnel, etc.) are all working in company X, local. And imagine that you have another software development project, of equivalent size and complexity, where the end-users are in company X, but the development team is located in an offshore outsourcing company on the other side of the world (e.g., China, India, Singapore, eastern Europe, etc.) Why is it that software metrics (from QSM) are showing that project #2 will have approximately 2.8 times as many software defects as project #1?
Precisely because the end-users and the developers are not “co-located” (in contrast to many of the “agile” or XP development projects, where a “customer proxy,” or end-user representative, is literally sitting in the same office cubicles, alongside the programmers), communication problems escalate. Despite the tools, the world, is not flat: you can’t just assume that software developers can be sprinkled randomly around the globe, where they’ll participate in a complex software development effort with no problems at all.
The second reason for the higher defect rate is because offshore outsourcing firms typically offer an essentially unlimited number of technical personnel at a lower labor rate, many firms think they can achieve faster delivery schedules by hiring larger teams of offshore developers than they would if they staffed the project locally – and yet still save money. Which I have explained in my previous article on “The REAL cost of Offshore” is wrong. Thus, if the firm had previously staffed a project with 10 “expensive” local programmers, they figure they can hire 20 “cheap” Indian programmers, and still save money – while (in theory) cutting the schedule in half, because they’re blissfully unaware of Brooks’ Law .
Aside from the schedule issue, it’s a known fact (but pity enough not to everyone) that software defects are strongly correlated to the number of “lines of communication” between the developers on the team; and that number increases combinatorially (i.e., N*(N-1)/2) as the size of the team increases (this is a variation on Conway’s Law , first articulated by computer programmer Melvin Conway in 1968, which says that the structure of a system is isomorphic to the structure of the organization that builds it). Hence, the number of defects in a software system increases in a manner proportional to the square of the number of developers; and as a result, he says, offshore projects are more likely to deliver buggy software.
There is a lot more to tell about core metrics needed to measure, compare and predict productivity but let me stick to the topic of Defects.
On an average, we introduce and detect 0.4 Defects (without Unit test defects) for every Staff day (including training, project management, requirements writing, testing, documentation, etc.) of effort I.o. in a medium project (10 people, 6 months) we can expect more than 500 defects!
You can find these research figures e.g. at the different SPIN presentations or use the QSM Slim tooling. But there is more, it also a known fact that the longer a Defect is in the system the more it cost (time, money, risk) to repair it. A defect inserted while writing Requirements but discovered during Acceptance test can cause a lot of rework as it can have also its influence on other parts of the system and sometimes even the architecture.
Cumulative Defect Density (defect per kloc) versus actual found Defects is an important metric to avoid the big bang on Defects in the last stage of the project. You all know by experience what management decides. First we have to make overtime, then the project team size increases, both resulting in even a higher defect density. Testers are not getting enough time to test, which leads to another important metric, defect turnaround time (time needed to change the state of a defect). More and more fixes are not being able to test and then the inevitable happens, either the project is released with bugs or it is cancelled.
A lot of defects can already being found through reviews lowering the Cost of Quality as Testing is more costly, but there is an optimum to find. But as we all know, reviewing requirements is not easy and I advocate here the Test Driven Approach. You should write Test Scenarios based on the requirements and whenever you encounter a discussion on Testing/Reviewing most likely the Project manager / Customer complaining about the extra cost then there is only one answer to give.
“If its not worth Testing, it`s not worth Developing“`which leads actually to the biggest saver in your project as the Standish Group once has estimated that 55% of the software features are hardly or not used by its users. Another point for Agile techniques, by focusing on the most important requirements first.
This conclude my view and experience on Software Development in general and more specific on what are the most important reasons why projects hardly live up to the expectations of the stakeholders.