About: Andrew Rendell

Website

http://www.rendell.org:80/pebble/software/

Profile

Andrew is a principal consultant with Valtech UK. He is a hands on technical delivery consultant with over twelve years of professional experience in delivering new media and mobile internet applications in the telecommunications industry. He has experienced many of the negative aspects of large, complex software development projects and therefore never ceases to be refreshed by the practicality and effectiveness of the agile approach. He has used various agile techniques in his work with Valtech in the United Kingdom over the last five years. Andrew has presented at Agile 2008, Agile Edge and other conferences and seminars.

Posts by Andrew Rendell:

Dangers of executable examples over dry documentation

This post was originally published here by Valtech UK consultant Andrew Rendell.

Tweet

My team is responsible for several web service APIs that are used by external parties. The standard pattern for educating users about these interfaces was to provide an API document which listed the calls possibly with the occasional example. I have always found this approach to be less than useful and not particularly accessible.

I prefer an approach where the API specification is very much example based. This is makes more sense for RESTful web services than a programmatic API as there is no accepted mechanism for declaring such an interface. The same is not true if you are declaring, for example, a Java interface.

We supplement the document with JMeter projects pointed at a reference system which allow these interfaces to be exercised by the consumer and provides a step by step demonstration.

This has been an excellent mechanism which has resulted in very quick uptake of our interfaces but yesterday I was provided with an example of a potential pitfall:

We provided an API which upgraded widgets. Version was supplied with the manifest of the software package being supplied and was used again in the query string to the upgrade service. The reference data supplied by the system put the current version into a title metadata field so that testers could easily see that the upgrade had been formed. The version in the title matched exactly the title in the manifest.

Weeks after delivery and demonstration it stopped working. Why? The client was using the title rather than the metadata it was supposed to. Since we had used the same value for both the end to end use case appeared to work. As soon as they started using real data where the title was no longer equal to the version everything broke.

A valuable lesson here for me to relearn (I have hit it before in similar contexts). Always make sure reference and test data attributes are not interchangable with each other without an error occurring (and being detected). I should have made the title attribute ‘The version of this widget is <x>’. That would have steered the client developer away from error and would have caused a validation error then first time he tried to submit it to our application.

Agile != anarchy, disiplined, structured organisations do agile well

This post was originally published here by Valtech UK consultant Andrew Rendell.

Tweet

My current client is a major telco. They have been developing high qaulity software for decades (literally). They have heavily entrenched waterfall process. They are used to doing everything to the letter of their methodology. When I first came on site two years ago I used to dispair of them ever doing anything agile.

Today, they seem to be doing agile pretty well. Its not been a universially posiitve experience and there are plenty of non-agile values and practices still floating around. On the whole though I have been impressed that rather than seeing Agile as an excuse not to write documents, they have embraced the disipline required by a leaner software process.

I have worked with clients who were much more reactive and used to being at the cuting edge. They embraced agile becuase it appeared to legitmise the lack of structure in their approach. They produced poor software when they produced up front designs and they continued to produce poor software when the developers were ‘let off their leashes’.

Upon reflection I think my current client, with its long history of rigour and application of best practice has made far better use of the agile techniques. Maybe its becuase they continue to apply disiplince. Possibly its becuase they are very aware of the dangers of a less formal approach and are always trying to mitigate any risk that not having the waterfall in place might bring.