The Code Whisperer

It’s often said that people don’t know what they want until they see something, then they realise they don’t want that.

If it’s a software development project then finding this out at user acceptance testing is far too late in the development cycle. Enter the prototype. A survey in Rapid Prototyping and Software Quality: Lessons from Industry by V. Scott Gordon and James M. Bieman carried out in 1991 revealed that prototyping can lead to better designs, better matches with user needs and improved maintainability.

Accordion Hero started as this prototype

If you’ve not come across prototypes before, they are a cheap, hacked, dirty (in terms of not worrying about coding standards) and disposable representation of what how the software will look and what it will do. The prototype is not a full working system - it can be a series of screens without any functionality, or can mimic some functionality with hard coded values. For example a list could be populated values, but these would be hard coded not derived from the database.

The First Golden Rule of Prototypes

Don’t use the same code for the real development of the application

Why? It introduces potentially poor quality code into your application. I’ve seen it many times, and six or seven years on, some poor developer new to the company and application is really struggling to understand code simply because it was prototype code and didn’t confirm to the standards. In addition it may be inefficient and just plain ugly and inadvertently may form the standard for the application.

The Second Golden Rule of Prototypes

Don’t make it look too good

Why? People that don’t develop software generally have no idea what goes on behind the scenes to make an application work in the same way I have no idea how a car is manufactured. In the same way I can see a concept car at a motor show and expect to be able to buy it from the dealer the next day, users of a system see screens and expect the application to be up and running in no time at all. The more perfect the prototype looks and behaves, the greater this expectation.

One of the first website I developed was for the local primary school. I took along a design containing a section of text from their prospectus. The aim of the meeting was to agree on a design, but having understandable text diverted their attention away from the layout. Interestingly the school picked up on several grammatical errors in the text and were horrified when the source was revealed.

The Third Golden Rule of Prototypes

Be aware of feature-creep

Feature-creep is the blight of any software development project and can be added by the development team or users. One of the dangers of prototyping is that the users and development team start to think more about the application and the surrounding processes. This can lead to features being added that have little benefit, sometimes at great cost. When additional features are requested look at the cost-benefit of adding the feature - there’s little point in spending four weeks developing a function that saves one person 10 minutes a year, unless there’s a substantial risk if the work carried out in the 10 minutes goes badly wrong!

If I sound negative about prototypes that really isn’t the case. I believe it is a beneficial tool that can lead to a much better application, provided it’s managed correctly and the three golden rules are followed.