Home > Uncategorized > Risky practices:

Risky practices:

August 28th, 2008 Leave a comment Go to comments
I was having some correspondence today with someone I met at Agile2008. At conference we were talking about the role of (TDD) tools to enhancement communication and the nature of relationships. He wrote:
I feel an urge to look less at automated acceptance testing (AAT) and more how the communication between customer and developer team functions. And then how AAT relates to this. AAT has gained some attention, and has been praised as a tool to enhance communication between customer and developers. As were Use Case diagrams back in the last century. And we all know that worked well … What is it with AAT that makes it (supposedly) a good tool for development? What kind of requirements cannot be described in this manner? It is about the learning of the proper requirements, it is about learning that the code can be trusted (as you say), and perhaps also about increasing the trust within the team that they will make the right decisions.
I have quoted this because from this email extract, it started to get me thinking about pulling together some themes I am working on. There is one comment in there that I find both telling and a risky practice: “It is about the learning of the proper requirements”. There are so many assumptions going on the words “learning”, “proper” and “requirements”. For example, in agile would we askew the word requirement in favour of story/scenario, and why? If there is the notion of the proper, what is it? Can proper be determined before the start of the a project or outside of the people on it? If so how is proper related the agile manifesto’s goal of  individual and interactions over processes and tools?

More telling, is a shift into trust – or as some might say, a discourse of trust. Throughout the language seems to be the new benchmark of success – trust of the code, trust between people. Is this the new silver bullet? We know that requirements – a discourse of requirements – has failed us.  We should be careful to assume that trust is any more of silver bullet than requirements. Perhaps, it is no more or less than the current trend to label practice. If that is the case, what are the assumptions and practices which underlie it? Rephrased, then. Perhaps we should trust that we will never get proper requirements; or trust that are requirements are never proper.

Learning is for me is the most interesting word out of the three. I am writing a piece at the moment that is setting the stage to focus on learning. I think that we need to establish in our SDLCs where and why learning is important. Most models still cannot incorporate where the individual and interactions fit in. I have a circular model of development. That model links simple activities with lots of lines. It is those lines which make up the individuals and interactions of the manifesto. I have compared ithe circular model with a model of small batches in a recent white paper by Kent Beck written for Microsoft on Tools for Agility.

What do we mean by learning here? It seems that the current trend is a focus on cognitive psychology forms of education. For example, Drefus’ skills acquisition model (talked about by agile coaches in sessions and also Andy Hunt’s latest book yet to be published from Pragmatic Programmers). There is much more to learning theories that these approaches: radical, feminist, poststructural, postcolonial, kaupapa maori theories of education/learning. But before we can do this we need models of software development that actually provide space for learning inside them. The current trend on process (and tools) occludes and assumes the learning. Given then we have a focused model on interactions, what is it that goes on in these interactions. For me that where I want to think about the metaphor of software-as-pedgagogy. I haven’t written this paper but have sketched out some ideas. It is based on a model by an educationalist in NZ. That is the next month or so of work.

Categories: Uncategorized Tags:
  1. No comments yet.
  1. No trackbacks yet.