Fact; 50% of development time, on average, is spent on bug-fixing and rework. That means 50% of time is spent on work that isn’t generating a return on investment at all, but it’s there to enable the work that is generating a return on investment to actually perform as it’s supposed to.

Conclusion; 50% of development time can be considered to be wasted money from the business point of view. It’s time spent not working on or delivering value to the organization or to the end-user. Now one of the things we’ll always endeavor for here is forthrightness and honesty. So let’s be honest with ourselves.

Time Is Money.

And the investment spent on any sort of technology development isn’t, and can’t, be realized until that technology is in a production environment and we are able to get feedback on it. And it has to be working. Ultimately, it has to be technology that is working in production. So in order to realize any return on the large investment that is technology, that software needs to be used by end-users. Feedback needs to be gathered as quickly as possible. And then we need to work to address new challenges and functionality so that we can ‘strike while the iron is hot’.

It’s important to make sure that my readers and I are all aligned on that premise, because in this article we’re about to get radical and start addressing solutions to challenges and problems that continue to exist throughout IT organizations throughout the world.

Back to our above example – stop and think about the astronomical figures there for a second.

With a burdened overhead of roughly 125$/hour PER DEVELOPMENT TEAM MEMBER (125$ seems to be the rough average of burdened overhead as of this writing from my own experience and it’s a great round figure for demonstrative purposed) and a 7-person development team, the blended burn rate for the example team is 875$/hour – roughly $1.75 Million or so per year.

And of that $1.75 Million our theoretical company is flushing half of it, almost $900,000/year, down the drain on rework and bug-fixing.

That number comes uncomfortably close to approaching $1,000,000/year – and that’s just one team.

AND That’s not counting for the cost of delay in delivering to the business including any sort of opportunity costs that might be accruing in the background.

When we take the larger picture view, a small-cap company with maybe 150 people working in the Software Development/Information Systems department(s), causes that number to quickly inflate to reach nearly $19,000,000 a year.

So we already seem to be establishing a key goal, and that key goal is already beginning to become clear, that any IS/Software Department should be driving to tackle this monstrously large, glaring elephant in the room as quickly as possible.

How do we focus on reducing defect leakage?

As the chart above shows, right now we’re losing 25% of development time to just fixing existing bugs. Whether it was caught in QA, or in UAT, or in Production – it’s all a time sink as far as driving value from our area is concerned. And the further down the chain it is (QA to UAT to Prod), the more it actually ends up costing to fix it. We need to figure a way to test the functionality of the software, not only now but that there’s a framework in place to continually test the software and alert us of any breaks as quickly as possible.  

You’ll notice that depending on where the defect was found will actually affect the cost in an almost exponential fashion. We can also quickly identify where we absolutely want to start addressing possible/potential defects in the software development process – and where we absolutely do not.

Making the code work.

How do we ensure the code is clean, separation of concerns is enforced, and that the integration/merging is painless? That’s another 25% of our development time gone in just making already written code integrate, compile, etc without throwing errors out right and left. We need it clean, elegant, and easy to work with. Code that is simple and clean enough that anyone in the development team should be able to work with it with a minimum of orientation.

The business case isn’t solved.

How do we ensure that the business case is solved? This is why we’re here in the first place- to enable the Business to operate. We must be able to demonstrate to our business stakeholders that their business scenario is solved within the system, and variations outside of the solutions are handled in some fashion. We need to show that we’ve delivered the value that they need in order to keep operating and releasing new products of any type.

Luckily, there is an answer to all three of these questions –

Test-Driven Development (TDD)

Test-Driven Development (TDD), or Test-First Methodologies (TDD, BDD, ATDD) is the use of tests to drive our software and system design. Not just at the code level, but in full ATDD we also let the business scenario/case itself drive our development efforts.

In this series we will be exploring the use of TDD, or Test-Driven Development, aka Test-First Methodologies at various levels. From the Unit Testing, to the Behavioral Driven Development (BDD), to the full Acceptance Test Driven Cycle (ATDD), and even Data Driven Testing (DDT) and how they all fit together to help us deliver Value to the Business 15%+ faster, how we can reduce our Defects by 60%+, and how we can build that trust between Technology and Business to deliver functionality quickly and efficiently into Production so that a Return on Investment can be realized rapidly.

DevOps

And then we will move to covering DevOps in-depth, including Continuous Exploration, Continuous Integration and Continuous Deployment (CI/CD). From the delivery by the software teams of incremental, valuable software – and how they can work to achieve that – to the delivery of those incremental pieces into the artifact repository and how it’s orchestrated within the system – and then into the pipeline of automated deployment throughout the entire DevOps tool chain.  

From inception at the business case to delivery to the end-user, we’ll focus on how we can minimize that time in order to harness speed as a competitive advantage across all platforms to enable a seamless system of development and deployment, cradle to grave, across our ecosystem.