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.

drowningBut 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 .

lean software development books 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. cost of defectsBut 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.

testing too lateCumulative 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.

test turnaround time

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.

Defects, Lean Software Development, Offshore, oh my …

6 thoughts on “Defects, Lean Software Development, Offshore, oh my …

  • Pingback:Offshore… and defects « Michael Ayvazyan on the Network

  • April 14, 2011 at 1:02 pm
    Permalink

    very nice content u given including the graphs.

  • January 9, 2009 at 2:11 pm
    Permalink

    Hi,

    Thank you for sharing this valuable information. When choosing an offshore service provider, consider both their capability and the level of trust and transparency they will provide. They must not only be able to do the job, but deal with you fairly and honestly.

    Thanks
    Sofia.

  • January 3, 2009 at 9:51 am
    Permalink

    For me it is still a dream as well. Maybe someday at JTeam we can do it. We are progressing in the right direction. Getting the process more standardized for the different type of projects and those sort of things. THe biggest problem is the mindset among people. Not everybody is capable of choosing his or her own work, sell himself to project managers or to developers. There is more to it than just do it. People need to be educated and believe in it.

    Who knows, maybe some day 🙂

  • January 1, 2009 at 6:54 pm
    Permalink

    Hi Ben,
    Don’t get me wrong, I am not against offshore, nearshore or in general off-site development. I had (together with Jettro) positive experiences doing a project twice in parallel (onsite and offshore), but of course I also have quite some bad experiences. A lot of the communication issues can be tackled not in the standard way of bringing Indians to Holland but the other way around bringing the key persons (architect, lead developer, etc.) to India.

    The message I try to give is that Defects have their own self dynamic and are closely related to the team size. Management quite often neglects this and when doing projects offshore with cheap labor the issues become even bigger as most managers think that increasing team size helps solving their problems.

    My dream in 2004 when I wrote a manifesto for Grid development (yes that is the origin of this site) was and is to establish a “open source community way of working” in a commercial setting. Nowadays you see this happening with open source projects sponsored by the big four, as they allow their best people to work on those projects.

    In 2004 I tried to convince Capgemini leaders to start Capgemini 2.0 with a limited group of developers that are self organized according to the open source community model and to let them choose themselves which projects they want to work on. I did not succeed 🙁

  • January 1, 2009 at 11:47 am
    Permalink

    Excellent article as usual, Freddie.

    I just wonder how long it will take companies in the Netherlands to catch on to the fact that offshoring is not really a panacea.

Comments are closed.