Last week I was in Canberra doing some development work for the Department of the Environment, Heritage, Water and the Arts on a species observational records loader. We’ve been working with the guys there on this project for few months, beavering away over here in Perth, and as we’re now in the closing stages of the project, the intent was to get onsite and iron out all the final issues, install the software and do some testing.
Developers often say that the worst projects to work on are the ones where there aren’t a fine enough list of requirements before the commencement of development. Well, I don’t necessarily agree, having been a fairly strong proponent of agile methodologies for a while now. Requirements are important, but more important is communication and expectation management. The requirements will be pretty clear if you understand what it is that your customer does, how they do it, and you take the time to work through it with them.
When you work alongside your client, in the same office, even at the same desk, you have access to a unique resource that you’d be crazy not to make the most of. That resource is instant feedback. You can write a line of code, and get instant feedback as to whether it’s inline with the client’s expectations and requirements. Naturally, you can’t run an entire project like this, as it’s both draining on the developer and the client, however, I think it’s a really valuable exercise to very quickly ensure that you build a product that your customer wants.
Naturally, of course, there are a number of critical pieces to the puzzle that need to be sorted out before a developer runs off to perform a massive code sprint with their client:
- An agile framework – If it’s going to take the developer two hours to put a button on a screen in an interface, then rapid development with client involvement probably isn’t going to work.
- An indepth knowledge of the codebase – I wouldn’t run out to do this sort of thing with some code I wasn’t familiar with
- Version control – After all, you’re going to need to bring all the rapid cranked code up to production standard, and version control is going to tell you what actually happened. (And allow you to roll back should things go pear shaped).
- A clear understanding of the scope. The developer really should know what’s in scope, and what’s not… and for things that aren’t, well, there is a discussion to be had before making those changes.
During the week, the species loader codebase increased by 25%, there were about a dozen new screens added and various other requirements that would have otherwise been missed were implemented. The important thing here, however, is that the work performed was really in the critical areas of the software – the parts the client would be using most frequently and needed to work flawlessly. Now I’m sure some of you developers out there are thinking that this is cowboy coding and in some respects it is… except that when you get back to homestation, the use of version control, bug tracking and other software development tools allows you to review in depth all the work performed and ensure that quality is maintained as it’s checked back into the main codebase. Much refactoring is being undertaken this week to ensure code written during the sprint is of high quality and maintainable.
It was really a great experience to sit alongside the guys to continue development and the data loader we’ve built is a much better product after the exercise too. Working closely with your client is the difference between a product that matches the specification but ends up on a shelf somewhere, and a product that focusses on what the client’s problems are, and does the most important things well.
Comments are closed.