There has been quite a lot of fuzz lately regarding Test Driven Development (TDD) - I have seen a number of posts where poeple are asking if the maturity of the tools on the market make old-school TDD obsolete. I have also seen posts where Ben Hughes asks if TDD really ensures quality.
That made me think about the term "quality" - what is software quality seen from a customer's point of view and how can we convince them that the software we produce are better than the one of our competitors?
I don't really think you can measure very much out of TDD in a sense of software quality seen from a customer's point of view. I mean - do you really care how Microsoft develops Windows XP and Windows Vista? I couldn't care less - neither do our customers as long as our sh** works every time. Even when our customers have a negative experience because they are unable to fulfill whatever task they were set to do because we as software engineers have failed to deliver - do they start to ask questions? Not really - they start looking for the products developed by our strategic competitors on the market to look for a replacement of the crap we have convinced them to install on their harddrive.
The principles and paradigms on which a software product has been built upon can and should never be a quality metric for our customers. They will never care anyway. TDD is just one (very useful) tool out of many when we develop software. In terms of quality it should only be a metric inhouse whether or not our software has a certain degree of code coverage for instance... We must not be mislead to believe as developers that anyone else but us really care what tools are in our toolbox!
This blog contains reflections and thoughts on my work as a software engineer
mandag den 28. januar 2008
Test-Driven Development and the quality issue
Indsendt af Kristian Erbou
Etiketter: how to measure software quality, software quality, tdd, testdriven development
Abonner på:
Kommentarer til indlægget (Atom)
Opslag
3 kommentarer:
In my experience, I've always found that the 'process' used to build software has a huge effect on the final product. An big overly bureaucratic organization produces fugly over-complicated systems. A small group of programmers in the 'zone' produce smaller, lighter-weight systems that are usually more elegant and consistent.
Microsoft, for example, favors huge brute force development teams that pound the code into something sort of usable. So, Word has millions of functions, but they are often hard to find and utilize. Big teams tend towards huge code bases with awkward interfaces.
You see it outside of software as well, the 'culture' of the company effects their products. Lots of examples, but these days Apple is probably the best. They focus on sophisticated high-tech solutions that are inherently cool, and it shows.
Paul.
http://theprogrammersparadox.blogspot.com
Agreed - software quality is about people and culture. We must always remember that our customers probably doesn't love technology as much as we do - they just want to be get their job done smoothly :o)
I agree that the tools used should be an internal concern only. Furthermore, I always find "suspect" when companies are bragging about what they are using, because I know that internally there is often a difference between the real practices and the one used for the outside marketing discourse.
Send en kommentar