Bad/Mad Practice

Alfred Thompson had a good post in his blog about software testing. Alfred and I are around the same generation (I hope he won’t mind me saying this) and we’ve both written software for money in the past. When I was writing my largest projects I didn’t make use of any kind of tester particularly, I just make sure that it worked before I handed it over. Alfred was the same.

Nowadays it seems that there is a trend towards developers handing stuff over which they haven’t really tested, on the basis that the test people who receive it will find any mistakes they made. Alfred (and I) hate this idea. I put quite a verbose response to this effect on his post you can find here:

http://blogs.msdn.com/alfredth/archive/2009/01/27/how-not-to-develop-software.aspx

I’ve since talked to people in the business and was appalled to hear that this practice is not uncommon nowadays because developers are pushed to meet deadlines and the only way they can do this is by skimping on the testing they do. Ugh. I reckon this really goes back to Bad Management, in that a manager will get a good feeling if they are enforcing a strict regime with tight deadlines which the programmers are all hitting.

The end result though is that the testers keep sending stuff back for re-working because it has bugs in, the developers lose time on the next phase because they have to fix all these bugs, so they send the next version out (in time for the deadline) with more bugs and so on. The words Vicious and Circle spring to mind. Along with Bad and Product.

It turns out that one of my heroes, Eric Brechner, has written a lovely post about this that sets it out really nicely:

http://blogs.msdn.com/eric_brechner/archive/2009/01/01/sustained-engineering-idiocy.aspx

Comments

[Andrew B]

I love Test Driven Development, I know the benefits, I know the cost saving.

But unfortunately at many companies, management still have a hard time understanding that if they allow a bit more time for TDD and Unit testing, then their 'UAT Analyst' phase will be shorter...less bugs...less cost in fixing..etc.


Again, unfortunately 'management' seem to have a hard time grasping the idea, even when you show them the massive potential cost-savings from "not having to fix bugs that shouldn't be there or could cause the client to loose, literally, millions of pounds".


A recent team I work with, when asked if they used TDD said "Yes".
It turns out, their 'idea' of TDD is that they "think" of some tests, click the application, then change the code when they find a bug....oh dear.

[JDog - Joel Parkey]

I'm using test driven development at the moment, my current Tester friend is extremely helpful and as a result the product so far is above and beyond what i'd imagined!

[Garth]

I worked at a software company where the number of people in the bug department was almost as large as the number of programmers. Why? Programmer turn over. Keeping qualified programmers was near impossible at the wages they were offering. So almost every fix was done by a new programmer who had nothing to do with the original product. Hence a really big bug team. I only lasted 6 months in that place.