The Mythical Quality of IT

No one likes to be told that they produce poor quality. Each one of us believes that the work we do strikes the right balance between customer needs and time to market, between cost/benefit and right quality. We reassure ourselves that the number of defects in our code is lower than industry standard. But the standard IT customer is not happy, even if they have wearily accepted software defects as a fact of life.

Look at the average IT project plan and see how much time is spent in testing. Doesn’t it strike anyone as odd that the customer first pays people to put defects into code during development, and then pays a second time for people to take them out during testing?

There have been lots of rants about software quality and it’s not my intention to add another one. Instead, I’d like to engage on a concept that isn’t new, but is finally gaining traction across our industry: Lean.

The time people spend putting defects into code is wasteful. The effort to detect them during testing is also wasted; it creates zero economic value.  And of course the time we spend taking the defects out is money down the drain. Why not just stop this nonsense and do it right the first time? In a nutshell this is what Lean is about – it’s not rocket science, but, somewhat surprisingly, as an industry we still don’t see testing as wasted effort. There is a reset of thinking required.

There are a lot of root causes for why quality remains a myth in IT and it will take a lot more words than this short post can afford to get after them all. Some thoughts I’ll explore in future posts include: how Lean thinking addresses the overall system of people, process and technology in IT to drive improvement in quality; what lessons we can learn from companies in other industries who transformed their competitiveness through Lean; and why now is the right time to increase the value our services by applying Lean concepts to the work we do for our customers.


  • Mark Smith April 19, 2010

    Whose responsibility is it to test? Many people will reflexively say QA, but I want to propose that it is developers job to test software. Developers get a set of requirements and then design and implement code to fulfill the requirements. How do they know they are done? The answer is when they test the code and the tests indicate the requirements have been fulfilled. See Test Driven Design (TDD) for more thinking around this concept.

    What then is QA’s role if developers test? Quality Assurance! QA job is to assure that when developers say the code is defect free it truly is. QA would still test, but the emphasis is changed from an expectation of finding defects to send back to development to validating the quality of the code, and testing, done by development.

    How can we get developers to change their approach to relying on QA to find defects? Developers need to stand behind their code. Ask a developer this question. “How much would you be willing to bet that QA will not find a defect in your code?” If the developer does not want to take the bet then they are still working in the old mind set.

    • Gayani November 6, 2010

      I totally agreed with the things u have explained here. QAs responsibility doesn’t sense, that he/she should be able to find the issues made by developers. First thing is, we should change our traditional mindsets as we are saying and blaming to each other who made this? who should be responsible? Software cannot be made without the full time/part time commitment and attention from all the team players of the vendors company and the participants from the clients company. We have to think about if he has done a mistake at the SDLC considering the quality of the output, when this went wrong? what mistakes have been done at each stage? what were the critical points/scenarios of this output? etc But nowadays most of the software companies think, the QAs’ responsibility means, they should be able to find the defects of components and developers responsibility is to code themselves. That is funny. We should stand to do things correctly without finding at the end, is this right?

  • LaDawn April 21, 2010

    Have found your blog and eagerly await future posts.

  • Milinda Dassanayake May 14, 2010

    I think the problem is about unit testing. Whether developers are doing their unit testing properly or not. If they have done, then the product released for QA should not fail. At last the happy path should work. But there can be alternative events which might not pop up in the developers mind, causing problems. It is where QA role is largely coming into play. Quality of unit testing can be measured by the number of iterations the product went through QA, which should be monitored and controlled. But the ultimate responsibility of making sure the product is good quality, is tagged to the QA.

  • Tharindu May 25, 2010

    Hmmm its an interesting point. well since the problem is found by Mr. Clayton Locke i would like to give my idea of solving this out…

    Well to solve a issue like this we have to see it in management point of view, a well known fact about people is that they don’t dare to do anything unless the get benefit from it. The problem is that the developer really don’t care about the quality of his/her code due, at the end of the month anyway they get paid… So we need to make a pattern or to implement a process where developer give his/her best shot in each piece of code in-order to reduce the time we keep a project on testing phase.

    Now the process which i would prefer is this, well we don’t need a process which will cost for the company so what can we give to a developer without costing a penny more for the project/company.. We can implement a process where the developer get a pre determined amount of credits for the developer and this credit schema should be a unique one to the IT industry where every company bound to give credits to the developers based on the quality of the their code and only based on that… And if the developer provides code which is not upto the standards some amount of credits should be deducted. Now the next question you might ask is, what does this credits means to the developer. well this is where industry should get together again, that is they should offer a salary to the developer based on this credits when they apply for a job or perhaps in each year so that the developer has to pay 100% attention to his/her code in-order to take a big bundle of cash to home at the end of the month in each year. And also that would help developer’s who give their 100% yet find it difficult to get promotions and all..

    In aviation industry their is something call no. of flying hours a particular pilot has and airline companies judge the quality of the pilot based on that but in IT industry do we have a such thing to judge the developer’s quality. I think its not, may be it is their, since i’m still a university student I may don’t no about it. somehow i think industry will take a look at my idea and i hope they will find it interesting and useful..

    In the developers point of view – i know all the developers are pretty much mad at me right now since this will put them in a hot seat but one thing we should all agree with is that the company we are working for is “THE MOST IMPORTANT” thing because unless the company perform well we don’t get a better salary and also we don’t have the ability to say I work for that company and show our hi hui to our personal competitors(Of course we do have, because when i was a kid, i’ve heard it a lot by listening to elders while there are partying)…

    Hmmm as matter of fact now i see a downfall of this process as well, that is the developer gets too much of pressure and that may result in producing bad codes but i think well experienced people in the IT industry can sort this out and make a more smoothly working system for the developer that will benefit for the both company and for the developer…

    At last I hope i didn’t waste any of yours important time but provide a good idea for the industry…

  • Clayton Locke May 26, 2010


    Thanks for your thoughtful response. Your idea that we should certify the skill level of developers is interesting and relevant.

    Some of your concepts are in fact being implemented by industry, with skills and quality assessments available (SFIA gradings, for example).

    One interesting thing to consider is that Developers as a general rule want to produce quality code. They don’t set out to put defects into code and they are aware that the quality of their work does matter.

    So why are there so many defects? We can take a lesson from Lean and start with the simple premise that the reason is NOT the Developer — they are not the root cause of the problem.

    The root cause is in how the software development process is managed: from leadership and people management, through development process and tools, to company culture and attitude toward Quality. It’s not the people, it’s the process. Quality doesn’t come from heroics, it comes from good engineering.


  • Tharindu May 27, 2010


    I agree with you…! I should think about a better way of handling software developing process, who knows i might all of a sudden come up with a great idea…


  • Rishi Varshney September 9, 2010

    Quality is a myth today. But who is responsible for this and how do we turn it into a reality?

    Are developers main culprits who inject defects into the system and if so, what makes them do so? Is it that writing software code is a pretty challenging task? so as to say, does the IT industry lack good developers? Should developers do more of unit testing and take up the role of QA folks?

    Majority of the defects occur not due to problems in writing the code, but because the requirements provided were not correct. No wonder why the functional design documents are not comprehendable to the developers..

    In my perspective- it is the failure of business analysts and architects in capturing and understanding the business requirements. A good percentage of this understanding is again lost while transmitting to high level and low-level designers – thanks to communication gap. And why does this communication gap occur? To avoid being considered ignorant, people do not ask questions and clarify the requirements. In an attempt by few of them to show that they are pretty smart and not dumb, the business ultimately takes a hit.

    To resolve this, go back to basics. Ensure that we use flow chart, entity model diagrams, data flows to convince every one that this is how the system should behave. Before writing the code, developers should draw this diagram and verify the understanding with the designers.

    In my view, requirement gathering is not a one step process but it should be more iterative with the business being involved in various stages of the development. Every participant in the software engineering process should appreciate the business problem. We need more control on the process and people to ensure that quality no longer remains a myth.


  • Nalin Goonawardana April 2, 2011

    I would say as with any other business if we do not redefine ourselves as QA professionals it will be the end of our profession. I would not phrase it as responsibility but rather as the common goal of both Developer’s and QAE’s is quality. These two parties should not at least see each other except through requirement walkthroughs in the inception phase, through clarification mails in elaboration and through defect management tool in the implementation. This worked well in the offshore model where the developers see the QA as a challenge rather than a subsidiary service that will take responsibility for the sins that they do. Developers should not have the mind set of presuming “OK the QA will test this and they will become responsible for the defects. So if the QA does not find defects in their testing then it is there responsibility.”
    In the offshore model this effects is some what less where the developers and QAE’s are world apart and the defects have full visibility through out and reflect badly on developers and ultimately the developers put there fullest effort to prevent sending the AUT to the QA team who located in the another part of the world.
    Also the QA professionals should equipped them selves with the value adding competencies to deliver the nontraditional values to the deliverables. This refers to the build engineering technologies, Requirements engineering, Test automation bundle with Continuous integration and using adoptive processes that suites the agile development environment’s ever changing demands.

  • Harish Sasikumar August 5, 2015

    Interesting. What’s your definition and measure for “first time right”? how would you want to achieve this?

  • revathi November 18, 2015

    Great Article..It was very informative..

Comments are closed.