Phases of the Software Development Life Cycle

You’re probably familiar, to one extent or another, with the Software Development Life Cycle (SDLC). You may not, however, be familiar with the SDDC approach to software development. Although, I can almost bet that every person reading this blog has either used it or has purchased software from someone who does.

1. Develop the software.
   
   
2. Carry out minimal testing on the code during development to maximise production time and meet predetermined deadlines. This is critical!
   
   
3. Perform final testing with anticipated inputs on pre-configured hardware.
   
   
4. Release to the public, deliver to partnered businesses or roll out to staff.
   
   
5. Sit back and await anticipated feedback from users.
   
   
6. Release patch after patch after patch until no one is using the software.
   
   
7. Find a new job.

For you see, SDDC stands for Software Development Death Cycle, and it is the worst possible method of releasing software imaginable.

Its most basic premise is to let the end user do 90% of the software testing, and then respond to their feedback in a lacklustre and infrequent method as possible, ideally by releasing buggy patches.

If you were to scan all of the apps I’ve ever installed on my phone, you would find a handful of apps that I installed, used for 5 minutes, then uninstalled. This is because they were so buggy, they were unusable. But I may have liked what the app was trying to accomplish, so I probably did a search and found something similar to download that actually worked.

I imagine you’ve done the same.

This is the end result of the SDDC process; your customers will go somewhere else if your software is too buggy. And these customers will never return, even if your version 1.1 of the software is flawless. Because by the time you’ve removed all of the bugs, they have become accustomed to using the competition and won’t want to change.

The old adage is as true for software as it is for job interviews; first impressions are the most lasting.

1. ‘This is a fantastic April Fool’s joke, because SDDC isn’t really a thing.’ Which is correct, it’s not a formal process. I made it up. Happy April Fool’s Day.
   
   
2. ‘Software testing is an obvious and vital step in software development, everyone knows that.’
   
   
3. ‘This really only happens to teenage app developers dreaming of producing the next big hit, like Angry Birds.’

If only 2 and 3 were true.

And what’s worse, is the SDDC methodology, real or not, does actually get used, to some extent at least. That is to say, you can never kill all the bugs.

This is in part, because bugs like complexity just as spiders like dark corners.

I once read an estimate that said there are between 5 and 50 bugs per every 1,000 lines of code. (Grey Hat Hacking, The Ethical Hacker’s Handbook, Third Edition, page 20).

If you’re creating something big, like an operating system, or a fully integrated office suite, or a massively multiplayer online role-playing game, you’re likely going to have millions upon millions of lines of code. Even a conservative 10 million lines of code could conceal 10,000 bugs, lurking in dark corners and dust covered subroutines.

You’re never going to find them all before the big release date. NEVER.

‘So, what do we do?’ I can hear you asking your computer screen. ‘We have to test, but don’t have a hope in Hell of finding all the bugs. However, if our customers find too many, they’ll leave us?!’

I know I said earlier that if a customer downloads your software and it’s too buggy, they’ll go elsewhere. And this is likely true, especially if they’ve just installed it, haven’t coughed up any money for it and there are other options to pick from.
But ultimately, a customer has three options when they find a bug, and which one they pick largely comes down to loyalty and investment.

Option 1 - they leave. They uninstall your software and go somewhere else. This is the option we most want to avoid, for obvious reasons.

Option 2 - they persevere on with the software in spite of the bugs.

Maybe they’ve come across one or two, fairly minor bugs that don’t impact what they do very much, and they learn ways to work around them. They’ll get frustrated, don’t have any doubt about that. And they may eventually choose Option 1 or 3, but for now, they’re going to keep using your software as it is.

They may even, if they are tech savvy, do a Google search on the bug and see a patch for it is coming out soon. This is a great way to encourage them to stay. Pretending bugs don’t exist will probably lose you more customers than you’ll ever know.

Option 3 - they’ll tell you about the bug.

What you do with that information may be the most important thing you do in regard to customer loyalty.

Option 3 is where loyalty and investment come in. If a customer has invested quite a bit of money or time in your product, they are likely to alert you of any problems in hopes you’ll fix it.

Loyalty is a two-way street. Customers may feel loyal to your software and company because of time or financial investment, but you also have to show a loyalty back and take action when they highlight a bug.

I’m glad you got my April Fool’s joke in that SDDC isn’t a real process. I hope you liked it.

However, the philosophy behind it is very real; 100% of any software produced by anyone, is ultimately tested by someone.

The question is, are you doing that testing in-house, or are your customers doing that testing for you?

And when your customers do come across a bug, what is your policy for dealing with it and improving customer loyalty?