Erik Meade's Blog

Kent Beck's Future of Developer Testing

I saw a link to Kent Beck's Future of Developer Testing from Nov. 17th, on scene's clips. 60 minutes of Kent talking about Developer Accountability, Software Health and a few other things.

One of those other things Kent expressed, and I have long been to scared to say, is that one of the driving forces behind development job off-shoring, is business looking for more accountability, not necessarily lower developer cost.

David Vydra has a Report from the Developer Testing Forum at PARC over on Test Driven.

Comments

• W.r.t. the teaser about Kent not being interested in software quality... That's only because the notion of the health of software subsumes the notion of quality. Health accounts for software as a dynamic, living system whereas traditional views of "quality" tend to view software itself as a (series of) static snapshots. For those who weren't there, I suggest listening to Kent's presentation even if only for the story of Microsoft and Jello. :-? :-)

  W.r.t. "off-shoring", check out my comments to Keys to Debugging. In terms of accountability, offshoring gives managers a whole 'nother level of redirecting blame. Unfortunately, as the mainstream is starting to learn, that doesn't remove any of the underlying responsibility.
  

  Posted by: johnm on December 13, 2004 at 12:34 PM

• Keys to Debugging is at: http://weblogs.java.net/blog/johnm/archive/2004/12/keys_to_debuggi.html

  Posted by: johnm on December 13, 2004 at 12:37 PM

• While I agree that, outsourcing your staff and moving on before the project fails is a way to look good on paper. I wonder if so many jobs would be getting outsourced if so many of our projects haven't been failing for so long? Would upper management really let you fire a whole development team that was meet or exceeding buisnesses expectations? Of course you can't just blame the failure on the developers, but they are the ones who are paying the price with the outsourcing of development jobs.

  Posted by: emeade on December 14, 2004 at 08:13 PM

• Indeed there are a lot of facets involved in the ecology of software development. A big part of the problem is the disconnect between the expectations of the business side and reality of what is actually delivered. So, if the team was really, consistently exceeding the business side expectations then it would certainly seem to be irrational to nuke the team. Of course, there are rational cases where it would still make sense to do so but much more often it's a question of poor managerial decision making (in terms of the best interests of the company rather than the manager).

  Posted by: johnm on December 15, 2004 at 12:43 PM

• The concept of health addresses a bit of that disconnect better than quality, no doubt. Sooner or later sick code dies, but as long as the features keep getting put in (more or less depending how you count bugs) business seems content to run projects right into the ground.

  Posted by: emeade on December 15, 2004 at 05:42 PM

This work is licensed under a Creative Commons License.