Posted on May 30, 2017 3 mins read
Developers love consistent ways of solving repeating problems, but the most consistent problem of them all is never solved repeatedly. Every time we sit down to solve problems with software we apply design patterns to overcome situations that would be contentious if we hadn’t already solved them years ago. There’s no point in reinventing the wheel, right? So why are we sitting here planning development of software for months on end still?
Iterative development isn’t really a design pattern but it is a pattern nonetheless. It’s a pattern used to overcome the hang in project velocity. Nothing sucks more than getting excited about your next project coming up other than trying to suck your own soul out with a vacuum while you plan every little piece of it three months in advance of even writing code.
There’s a myriad of excuses for this behavior. Let’s review and refute a few:
Iterative Development is simple. First, quickly build a completely crap, fundamentally working prototype. Get the major features working, maybe it’s an API, or functions hooked up to a CLI - who cares. It may be totally unusable by the average person, but as long as someone can use it that’s what matters. Next, recognize what you learned and what direction you can go from there. Steadily build on features but take time to revise your existing functionality. Rinse and repeat.
The key here is discovery. The team members involved are able to get very intimate with how the application should be developed. They can actively discover and fix pain points, or even prioritize a rewrite of certain aspects of the codebase while maintaining a forward velocity of major features. This way there is no individual sprint dedicated to maintenance and refactoring, because it’s done on the fly, as needed, with the participation of the rest of the team.
The day development becomes a chore, innovation and creativity die.Opinions Iterative Development