These are the same individuals that say it's no problem to fix a bug in production. They simply spend a few hours searching for the bug and then they spend another hour or two and fix the bug. They hand this over to the QA team or someone who has to test the application and it's all done. Just a few hours of waste. It's no big deal, right?
Let's play with some numbers. How much do you make an hour? Do you think this is all that it's costing the company? There are more costs associated with you than you think. For instance, you have to have a desk, paper, printer, pens, markers, notepads, and obviously a computer. If you work at a business that deals in other things besides software then you have to have the Microsoft Office Suite from like XP to the latest. Visual Studio 2005, 2008, 2010, and 2012. Maybe Team Foundation Server. Then you have the test servers (they cost against you), and databases and etc. This list can get quite long.
While many individuals cost roughly 150% of there salary, software developers are roughly around 250% or more. So if you make $30 an hour, your actual cost is $75 an hour. So if you waste 4 hours on a problem, you just cost the company $600.00. How did I come up with that number? $75.00 (per hour) * 4 hours = $300.00 + ($75.00 per hour * 4 hours you could have been working on something else) = $600.00. After the four hours to fix the bug, then you have to submit it to QA or hand it around to people in the office to look at. This takes some of there time and then you have to deploy the fix. So by the time it's all said and done most are around the $5,000 to $10,000 range. This number varies quite a bit and is really based on your company, so take those numbers with a grain of salt until you can figure it out. I'm sure the price will be a lot higher than you expected, though.
The reason I came up with 4 hours for a minimum is because when communication occurs on a bug, your wasting twice as much time. When the bug first goes off or is noticed, the individual must tell there manager what happened. It may only take about 5 minutes, but it's 10 minutes total time wasted. 5 minutes of the individual and 5 minutes of the managers. Then that manager will have to fill out a report or calls up support or someone in IT. A 10 minute phone call wastes a total of 20 minutes. Then the IT person notifies the manger and this just goes on and on until it finally comes to you. It's so easy to jump to four hours even if the bug fix is a simple spelling correction.
If you have QA individuals who manually test your code then that cost rises astronomically. Unfortunately, we don't have a QA where I work, so other developers and sometimes managers would have to help out with the manual testing. They didn't think twice about the cost as it was something that just had to be done. When I came along, no one ever thought twice about the cost of fixing all of those bugs. However, when I tried to teach Test Driven Development to them, they saw the extra cost of <i>learning</i> within seconds. "How much slower is development going to be?", they asked. "So we have to write all of that extra code? This is going to take a lot longer."
How do managers and developers not see the cost to fix the bugs after the deployment, but are so worried about the short additional time it takes to write unit tests? I just don't understand it. Do I need to scream at them? I want to.
Now I'm done with that rant. However, I never answered the question that I started with. The whole reason to do test first is to make you see that your test fails. This seems very trivial, but you would be amazed at how many times developers write a non-failing test. Watching it turn green may also give you a deep warm fuzzy feeling.
The most important part is that you have to stop and think for a minute on what you want the production code to do. You know that you have to keep your classes separated, so they can be easily testable. It's so much harder to untangle the mess just to write a unit test. It also becomes very boring and makes you lose your flow.
If you don't use TDD, you need to at least try it. I don't mean a "check off the box" attempt at using test driven development. You have to REALLY try it. If you don't try it for at least a year then you didn't really try TDD.
You know, the biggest thing I've always wondered about "test driven development" is "what process do you use to develop your tests?"
ReplyDeleteHire PHP Developers | Offshore Software Development
I always use Test First practices. I am a .NET developer and I use the built in MS unit tests. I use NCrunch to see my code coverage and it will run all the impacted tests for me as I'm typing. I currently use MOQ for any mocking that I need.
Delete