Mark Needham wrote a recent blog post on the subject where he describes a kind of “Spike Driven Development”: Coding: Spike Driven Development at Mark Needham.

I tend to think of this as some sort of experiment-driven development. I start by choosing a goal. Typically this is either finding out about some murky or unknown aspect of a system such as interfacing with a third party, or improving a variable quantity such as performance. This in turn leads to thinking about ways to assess whether we have done enough to meet the goal and how much time to allocate to the exercise. Finally, a period of playing, following where each trial leads. The important bit is to repeatedly check progress against the goal – that’s what links it to the aspects of TDD which work well.

Jez Humble has put together some interesting thoughts on how to deal with this issue. Read more at Deployment pipeline anti-patterns.

One of the results of the Oracle purchase of Sun has been an increased focus on testing — not that we didn’t test GlassFish before, but it was mostly manual in my area of the server.

from Jason Lee’s blog Coming Up for Air.

InfoQ: Testing is Overrated.

I will admit that for some (very narrow) fields there can be a common understanding of the one best way to do something, but this is often so well understood that it does not even get a name. Walking on your feet is generally better than walking on your hands or knees, for example, but I have never met anyone who referred to foot-walking as “best practice”.

In my world of software development, where the landscape changes at a moment’s notice, naming something as “best practice” is tantamount to declaring it obsolete. Yet large numbers of software developers still numbly follow the its lead.

James Bach tackles a similar issue in testing James Bach’s Blog » Blog Archive » The Great Implication of Context-Driven Methodology.

ThoughtWorkers on Open Source: Announcing ChromeWatir release 1.0.0

DanNorth.net » Monkey business value

This impatient monkey – dancingmango

I wish I knew an answer to this, but at least it is encouraging that others are also considering and writing about these issues.

InfoQ: The Correct Ratio of Agile Testers to Developers? It Depends.

This year, though, I face a different problem – my disappointment with the attitude of the society, particularly as expressed in two recent articles, published on their web site and notified to members via an email “magazine”.

The two articles in question are:

• Employee-driven Corporate Change – Reverse Ludditism?
• ‘Strictly Testing Only’, please – Agile doesn’t work!

I urge you to read them and make up your own mind.

My problem with both of these articles is that they seem to express a one-sided attitude which I had hoped had been banished from the BCS many years ago.

When I first encountered the BCS (during my university time in the mid 1980s) it was seen as the bastion of IT middle management, and in particular middle management in large corporate environments. There seemed little or no representation of or for the people actually doing the work of producing and maintaining information systems, and an almost pathological ignorance of the concerns of contractors and people working for small businesses.

Over the years, my concerns waned. The society seemed to re-invent itself to become more in-line with its charter and thus more inclusive of software developers and contractors. It still struggled with the idea of small IT businesses, and of small departments or lone IT workers in other organisations, but I had hopes that this would improve, too.

But then I received these two articles, and all my concerns about the emphasis of the society came flooding back. Both articles appear riddled with the view that developers are lazy and selfish creatures who will always choose to produce rubbish unless forced by managers or testers. This is an appalling stereotypical slur, and completely at odds with the stated, inclusive, intent of the society.

I understand that both these articles were published through the society’s “blog” initiative, and thus have not had the editorial oversight that one might expect from a more formal publication. However, this does not exempt them from reflecting on the BCS. Since reading these articles a few days ago I have already had one forwarded to me by a colleague. The damage has been done.

Maybe I won’t be upgrading my membership this year, either.

“Agile In Action” has a nice summary of an approach to software development. Most agile practitioners won’t find anything to object to.

AGILE IN ACTION: The Energized Way

Our first problem is with the second bullet “Work with clients every day“. As a team we would love to work with clients every day, but there seems to be a thick layer of representatives and proxies in between us and real customers. This is made especially difficult as we are currently serving the needs of several customers with a single product, and resolving customer differences is proving tricky.

Our second problem is with “Fix defects as soon as they’re discovered“. In principle this seems obvious, but the trouble we are having rests on the definition of a defect. As an agile team we keep up-front specification to a minimum, and in-effect treat every delivery as a prototype ready for customer feedback. Plenty of people in the company have opinions on such prototypes – things they think it should do, things they think it should not do, and things they think it does wrong. Any of these could be considered as defects (and indeed many of them are raised in our bug tracking system.) If we stopped new work to make all these changes we would (a) greatly reduce our feature velocity, (b) bypass the prioritisation process used to “Deliver the client’s highest-value stuff first“, and (c) leave us stuck in a mire of conflicting opinions.

We certainly do not ever want to deliver “broken” software, but its a fact of life that some “bugs” are lower in priority than others. Some “bugs” are also lower in priority than new features, but this is more of a business decision than a development decision. Working out how deliver prompt, appropriate and minimal software in the face of such a slew of opinions is proving contentious.

I’d be interested in reading any suggestions or answers to these problems.