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.
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.
Recent Comments