Twice today I’ve seen references to the benefits of iterative improvement, and I found that the topic resonated with me. At the moment I’m halfway though a pretty lengthy software project in which it’s sometimes hard to see the wood for the trees. The backlog is substantial, resulting in a hefty set of tasks for our team. In these situations, where the to-do list doesn’t seem to change day to day, it’s easy to feel crippled by inertia. However, these two references illustrate that we can succeed provided we ensure we’re making healthy, gradual progress.
One might expect that the references I’m alluding to originate from a tome of software development, like “The Pragmatic Programmer“, or from one of the many celebrated development gurus of Twitter, but in fact they are not directly concerned with software at all. The first comes from a talk discussing the pros and cons of iterative improvement , linked to by my colleague (and all-round good chap) Owen Phelps, by Tim Harford at last year’s Wired UK conference:
If you put together enough marginal improvements, in enough areas, you get something that’s truly outstanding.
Give it a watch – it’s entertaining and informative.
The second reference came from an altogether different source – an interview with renowned mix engineer Alan Moulder in this month’s issue of Sound on Sound magazine, in which he discusses his approach when applying VST plugins to his music projects:
All the things I use do something to make the sound a tiny bit better, and if you add everything together, the end result will be a lot better… It’s simple: better is better, whether it’s a tiny bit better or a lot better.
Through never-ending sprints, features and tasks, iterative improvement is something all development teams should strive to achieve.