Re-Work or New Features, which do you prefer?

December 15, 2016 — Posted by Maurizio Mancini

Most consulting engagements start with assessments of an organization's current state. Very often, the interview’s that you conduct reveals a lot about the current state of the organization. Once in a while you come across a statement that an interviewee makes during one of these interviews that make you think. During a company testing assessment, an interviewee said:

“Quality and Testing is something everyone wants, as long as it doesn’t cost anything.”

Isn’t that the truth! While it seems that everyone understands the need for quality, it is always the first thing that is sacrificed in some organizations.

Why is the discussion of software quality so divisive? For some, the cost of bad software is obvious and yet for others, their focus is to deliver the software at all costs. Logic would dictate that delivering quality software would be an essential criteria for all organizations.

In some organizations that deliver life dependent software, there is no discussion on quality. Quality is top of mind for everyone on the team because everyone knows what is at stake. Once you move beyond these industries, the software landscape is littered with examples of failures due to software problems. Here are just a few examples:

Not to mention how many software projects just get canceled and never go live despite hundreds of millions of dollars having been spent to try to deliver the software.

Deliver Software Faster - But at What Cost?

One of the common reasons that get cited on why software problems occur is the need to stay ahead of the competition. Software teams are being asked to deliver faster so that businesses can compete. Smartphones and the Internet of Things (IoT) have made that competition even fiercer as software is now in almost every corner of our lives.

The proliferation of smartphones has not only increased competition but also made software companies more adventurous when delivering software. The everyday use of smartphones by the general public has trained most people on the need to update their software. Even the most basic user of a smartphone knows about software updates. Software updates can be pushed to millions of users at the push of a button. This has lulled many software companies, regardless of the application, into a sense of comfort by thinking “we can just release a patch if we get it wrong”.

On the other hand, companies that develop software also know that whenever there is a problem in production, there are many indirect costs to that problem on top of the direct costs of productivity loss, and the re-work that has to be done to fix the problem. How many companies actually measure the indirect costs? In my experience, not many. Most companies just don’t worry about it because they want to fix it as quickly as possible so that they can work on delivering the next big feature.

Building a Culture of Quality

Adding new features to software is usually a fun creative time for a software team. The team wants to develop the best quality software possible. However, the excitement of building new software quickly gets tempered by the reality of having to deliver by a given date.

The pressure of a date often leads to a discussion about quality. This conversation occurs daily in many organizations. It goes something like this:

Mr. Get it Out: We have to cut the quality on this project because we are running out of time.

Ms. Do it Right: Yes but if we cut the quality, then there are risks that it will blow up in production and we will have to fix it later.

Mr Get it Out: We just don’t have the time to do it right….

Ms. Do it Right: But we have the time to do it over and over again?

Inevitably the software gets pushed out at all costs and a problem happens in production which leads to budgets being wasted on re-work and the many indirect costs that are incurred by the company. Some organizations actually track re-work with a budget line called “Break and Fix”. However, the purpose is not to use it to analyze what went wrong and look for ways to improve, but purely as a CAPEX/OPEX budgetary exercise.

In many engagements I have advised organizations that “eventually bad software quality will catch up with you”. The costs may not be evident but everyone knows the costs are there. Therefore, rather than looking at software quality as an expense, look at it as an investment.

If software quality is done right by using techniques of building in quality rather than trying to test in quality, then the investment will more than pay for itself. You will be able to deliver more features because you will have more capacity from the reduction in re-work. More importantly the company’s reputation will be seen as one of quality and that has been shown to be a differentiator in many of the top software companies.

Build a culture of quality in your organization. Your customers, employees and your bottom line will thank you!

If you want to know more about how to build a culture of quality so that your engineering teams are building in quality rather than struggling to test in quality, please​ ​contact Exempio or Net Objectives​ for a consultation.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Maurizio Mancini

Maurizio Mancini is a leader in the quality and process industries with a sixth sense for Agile, quality, and business process. He is best known for cutting through the noise and getting to the heart of any organizational problem whether that problem consists of choosing the right software development process, implementing modern quality approaches, or just finding the right balance between people, process and tools. Maurizio’s approach consists of empowering people and teams so that the team's talent and creativity comes through naturally. This mindset favors the adoption of Agile values in any environment.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban