I want you to think about a development project and consider two scenarios. Imagine each of these scenarios represent a different set of practices you use to develop the solution.
In the first scenario you develop a solution for your customer and it takes time t to produce the solution. The solution you deliver has x bugs and y security issues. This solution costs you $m.
In the second scenario you develop the same solution for your customer and it takes time t+s. This solution has x-a bugs and y-b security features. This solution costs you $m+n.
The values of s, a, b and n are critical for you to decide which scenario you use.
The question in your mind should be; is the extra cost and time of fixing x-a bugs and y-b security issues worth more or less than $n in s time.
Now here is an interesting thing to consider. How do you budget for your software development project? Is it:
i) from the beginning of the project until you ship the code (bugs and all), or
ii) from the beginning of the project till that code is decommissioned and never is run again?
Think about what you are doing when you budget for software using the first option. You are actively encouraging poor quality. If the cost of fixing issues is not taken into account in the development budget then why spend time and money worrying about it?
The only sensible answer is to use the second option to budget for software development. So why don’t companies do that? Maybe you should suggest your company does!
Now what would happen if I told you that I could show you some practices that help you obtain the following values in your variables for the second scenario.
s tends towards 0 (or even a negative number)
a tends towards x
b tends towards y
n tends towards 0
How much will you pay for those practices? Write a check to Dr. Neil and send it to me now!
Now which scenario do you chose?
What if I give you a list of practices to choose from and tell you that with each of these practices you implement you will get:
s closer to 0 (or even into the negative)
a closer to x
b closer to y
n closer towards 0
You want to see the list?
Ok here it is (in no particular order):
Test driven Development
Automating the build-test-deploy process
Breaking the solution down to tasks that each take less than 4 hours to complete
Small iterations – ship early – ship often
Does this list look familiar?
Good – so you know where to get started.
Of course if you are developing in .NET the best resource to learn the practices in the list is eXtreme .NET.