Hypocrites That We Are

In Ring One, here, we have The Cowboys.  They don't need specs or a test plan, let alone daily builds or release criteria.  They don't even bother finding out what the user needs to do, really, but instead prefer to make things up as they go along.  Since the applications aren't really planned but rather accrete over time, and The Cowboys always have some new bit of functionality they need to add in order to keep their users happy, their code quickly turns into a morass of impenetrable mystery that generates two regressions for every bit of new functionality, and four regressions for every bug fix.

In Ring Two, there, we have The Craftsmen.  The Craftsmen always start by talking with the customer to get past what the customer thinks they need to do and find out what tasks the customer is really trying to solve.  The Craftsmen plan, design, test, and code the application in multiple series of iterations, constantly checking back with the customer to verify what they are building is what the customer wants.  The Craftsmen integrate their changes into the main source tree on a regular basis, and some of them are agitating to start building the app twice a day rather than just once.  They are constantly on the lookout for code that doesn't quite work right anymore, and their massive suite of tests protects them against regressions.

Most people would agree that The Craftsmen create software The Way It Should Be Created.  Testers whose teams bear some resemblance to The Cowboys bear the brunt of this bad behavior; smart testers in this situation do everything they can to help their team become more like The Craftsmen.  No process is ever perfect, so smart testers continue to pursue improvements in the product development process regardless of how closely their team resembles The Craftsmen.

So why is it that when testers go to build their own applications and frameworks to support their testing they more often than not turn into The Cowboys?  All that lovely process that helps ensure the right product is built is thrown out the window, and whaddayaknow but a steaming heap of unmaintainable code that doesn't quite solve the problem results.  This is just plain wrong.

My team has a goal of having higher quality code than our developers produce.  We iterate on user scenarios, design, implementation, and testing -- not just internally but with our customers (Dev and Test) as well.  Ditto for test cases.  *Every* checkin is code reviewed.  We build several times an hour.  We aren't quite there yet, but we're getting close.

If your test team isn't already composed of Craftsmen, what are you doing to help them along?

*** Comments, questions, feedback?   Or just want a fun job on a great team? </g>  Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need testers, and my team needs a data binding developer, program managers, and a product manager. Great coding skills required for all positions.

Comments

• Anonymous
  April 14, 2004
  People often talk about programming as scientists vs engineers or art vs science.
  I am glad to see people calling it a craft, I've seen it that way for years.
  
  I'm still new to unit testing, but all my tests look like Cowboys, they break the rules; they have the connection string, they talk to the tables, they trust no one;)
  
  The result seems to be that all the Cowboy code is now in the test and the product code is getting cleaner.
  
  
  ps. It was strange how hard it was to make the decision to have a base class for my tests when it is so obvious in other contexts.
  
  
  http://weblogs.asp.net/andrewseven/articles/Ramblings.aspx
• Anonymous
  April 14, 2004
  "I am glad to see people calling it a craft..."
  Andrew Hunt and David Thomas' "The Pragmatic Programmer: From Journeyman to Master" and Pete McBreen's "Software Craftsmanship: The New Imperative" are excellent books if you're interested in other people's view of programming as craft.
  
  "The result seems to be that all the Cowboy code is now in the test and the product code is getting cleaner."
  So now you get to refactor your unit tests. <g/>
• Anonymous
  April 14, 2004
  May I ask a question?
  
  For the Cowboy, what do you mean "their code quickly turns into a morass of impenetrable mystery that generates two regressions for every bit of new functionality, and four regressions for every bug fix."?
  
  Thanks.
• Anonymous
  April 14, 2004
  Doh, you forgot "The Designers". They are lost in the world between Cowboys and Craftsmen. They design and create code for code itself not the customers. They go to the great lengths to make their life more complicated by reasoning that solution will solve world hunger and bring peace to earth. They love to write and design but they over-design everything that they write, they are never on time, and final design is so complex that it is :-)
• Anonymous
  April 15, 2004
  The comment has been removed
• Anonymous
  April 15, 2004
  Software engineers create software. Test engineers create ... TestWare. If you treat what you are doing as a development practice itself, you change your approach. I have yet to truly apply CMM practices to our testware shop, but I have thought about it (and there is that TMM thing I need to read about someday).