In the early weeks of my first real software development job for a proper software house, I was handed the remit to develop an address book application that looked like a real-life address book. Click the edge of the “page” and the “page” turned to reveal the next address – it doesn’t sound exciting now but, if you can forget your iPhone for a minute, at the time it was absolutely state-of-the-art user interface.
I was given a code library that provided the developer with the look-and-feel user interface elements that would deliver the appropriate “user experience”. The amount of time I spent on the project could be roughly divided up thus: 10% calendar functionality and 90% wrestling with the user interface library. The library had clearly been released before it was usable: pages would randomly turn themselves over, “closing” the “book cover” would leave an address showing on the front page and, for good measure, once in a while, the code library would cause my application to crash completely.
After working day and night on the project – implementing various hacks around missing code library functionality – I managed to deliver right on the deadline. After a little bit of testing, the product was demonstrated triumphantly to representatives of the client.
Post-demo, after the assorted bigwigs had duly filed out of the demonstration room, I was left with the client’s project manager, a straight-talking Zimbabwean; he confessed, “mate, I only wanted something to put our addresses into”. He had a point. It was a massively overblown piece of functionality that could easily have been a lot less showy, a lot less costly and delivered way ahead of schedule.
Sometimes it’s not the producer that’s to blame. WordPress has entered the popular consciousness to such an extent that I was recently asked by a client to provide a content management system (CMS) that would contain a five page website. The client was adamant that the CMS had to be WordPress.
“Sure, I could deliver that for you or instead I could get the designer to provide you with five static pages and you could have those almost immediately.”
“No, that’s no good, what if we want to expand the site?”
“You didn’t mention this originally. You have plans to expand the site?”
“Not at the moment, but you never know”.
The temptation in IT, and software development in particular, is to provide overblown solutions; often to provide solutions where no problems actually exist. As with all things information technology, it has an acronym: YAGNI, or You Aren’t Gonna Need It, or alternatively the more easily memorised DTSTTCPW (Do The Simplest Thing That Could Possibly Work). But it’s no hard-and-fast rule (although that could be debated) and arguably it could be seen as diametrically opposed to my mother’s motto: a stitch in time saves nine. And you do not want to mess with my mother.