Knowing what to build
Too much of a developer’s life is spent implementing features that nobody uses or needs. This has sadly been the case on many of the projects I have worked on. The problem isn’t a technical one but rather the mindset instilled by ‘waterfall‘ methods of software development. These methods promote the rarely correct idea that you can know, plan and design up front everything you need to build. Requirements are often just poor speculative solutions to half understood problems. By compiling and committing to a huge list of things that you will build at the beginning you create huge administrative overhead and waste for the project. Where possible development teams should use approaches that maximise learning and feedback in order to build only what is needed. Such approaches lead to less costly and more successful projects.
Recently we tried a new approach to tackle this problem when building call centre software at my employer uswitch.com. The business manager came to the development team with a detailed specifications of what the call centre team wanted to build and a long list of requirements. A lot of this specification work did turn out to be helpful but we had a few problems:
- we knew it would take months to build everything and what would the business do in the meantime?
- the business area was new so there was a big risk we would end up implementing unneeded functionality
- nobody had a deep enough understanding of the problem domain yet
Learning what to build with Access
Instead of building any software we asked the call centre team to use Microsoft Access to create a database. At first they were nervous at having to do this themselves and feared they would be stuck with an ad-hoc solution. We committed to start building a real application for them once they were up and running for a few weeks with Access. When we did start building the software the Access database turned out to be hugely helpful. The call centre team had an in-depth understanding of the domain and could answer our questions immediately. We had great opportunities to learn by sitting in with them on calls. The Access database served as a prototype application and set of sample data. Best of all this new area of the business was up and running and making money fast.
Having the Access database in place helped reduce the scope of our first delivery. Some of the fields they added to Access database turned out not be useful and were unneeded. The users were happy if what we built was just enough to replace the Access database. This was less then we had originally thought we would need for our first delivery.
The approach was not without its drawbacks however:
- Access had usability and scalability issues, so we set a time limit for its replacement by a custom application
- Additional work to write data migration code from Access to our custom application was needed
- When designing the custom application we were often asked to mimic the behaviour of Access. We had to educate the users about the more advanced possibilities available in a custom application (although some of the ideas to come from Access – such as the use of the Calibri font were good)
Credit and thanks to Mark Holdsworth for coming up with this approach.