Saturday, 8 November 2008

Agile theory versus agile practice

After 17 years working as a lecturer, I have returned to industry as a developer. I return having endeavoured to encourage students to use test-driven approaches to software development and having completed research on the ways that software practitioners express their understanding of object-oriented software development. My knowledge of the implementation stacks is more theoretical than practical although in developing my teaching samples, I endeavoured to follow agile practice. The bulk of my code is has unit tests.

In the process of obtaining this contract, I had to do a programming exercise. While doing that exercise, I learnt again about doing small incremental changes with your tests. If a test does too much then it becomes too difficult to implement. If you find yourself going to the debugger to determine the cause of the problem then the test is probably asking for too big a change. Small incremental changes can be implemented rapidly and tested quickly.

One week into my assignment and I am thinking about the challenges that lie ahead. This week has seen me learning about the system that I am to work on and installing the development environment on the computer I am to use. The development environment uses the Maven build tool and a source control system, and the appropriate testing frameworks are installed. Having the tools installed doesn't lead to an agile process. One of my first observations was that for the code that I am to work with, there are no tests. I will primarily be working with Flex on user interface issues but there is a lot of functionality in these user interfaces and I see no tests.

As I look at the physical environment with its individual workstations, I wonder whether an agile process will work in this environment. Agility is a mindset and not an environment. Why don't programmers write tests first? It comes down to the way that they perceive or understand the programming task. For me, an upfront test or behaviour specification isn't about proving that my code works. It is an executable specification of what the code is expected to do. The first part of any programming exercise is understanding the requirements. If I can turn those requirements into executable tests then not only am I showing that I understand what is required, I am also showing that I understand how I will verify that I have satisfied those requirements. Whether I use TDD or BDD to drive the development of software, the key thought is that I am writing executable specifications that will verify that the code I am about to write does what it is supposed to do.

To write an executable specification, I have to make design decisions about the implemented solution. I have to decide what objects I will need and what behaviour those objects will implement. I need to think about the architecture of the system and how that architecture might change as new requirements are specified. The executable specifications will help ensure that my changed architecture still delivers what is required.

I don't see the writing of executable specifications as that different from what I might have done thirty years ago when I was COBOL programming. When I wrote code, I was always thinking about how I was going to test the code. Some time those tests where automated but there was always a need to ensure that the data was there in order to test out the required features of the software. What I see different about my practice now is that I am creating executable specifications at the first opportunity rather than leaving things until I have some code to test. I am not so much writing the specifications to test my code as writing them to reflect my understanding of what is required. I hope that this is reflected in the names or descriptions that I give my executable specifications.

Although the TDD or BDD tools might help me create the executable specification, it is really the mindset that I bring to the task that determines whether I apply agile practices. My conception of the task will dictate how I approach the task. If I want agility in my practice then agility has to drive my thought processes.

No comments: