The idea behind this post has been started with a pertinent note from Steve Murawski during #DSCCamp, and ensuing discussions: The preference of an Iterative process against Incremental, and why the difference is important.

As LaoZi said, “a journey of a thousand miles begins with a single step“, whether it’s about knowledge, career, project, or this blog…

As you progress on your journey, you may find that the route taken could be improved, or sometimes you simply realize that you have reached a dead end and need to go back up to a certain point and try a different path.

Whenever you stop and reflect on what you’ve travelled, and analyse whether you should carry on in the same direction or if you need to rectify your trajectory, you are following an iterative process, constantly re-evaluating what you have accumulated and what’s left in front of you.

Should you strictly follow an incremental process, and if the direction you have travelled, end up taking you to an obstacle (imagine a cliff), pursuing on that track will increase your risk of failure to reach your end goal (or add delay, increase effort/cost…).

Applied to IT, the way you’re working should be no different. Instead of piling up on top of the existing (incremental process), you should assess the work done and decide whether to keep it in its current form (iterative). Moreover, you should look for signals that indicates something is not fit for purpose anymore, and plan for remediation before the technical debt becomes too expensive to pay off: you will have to pay it off sooner or later, and usually at the less opportune moment if not carefully planned.

Finding that what you have delivered does not fulfil its goal, is not necessarily a failure, but you must ensure you find out early enough to avoid unnecessary effort, or the need to pay off the technical debt. Short iteration cycles can help you find out sooner, but more importantly can help you fix the problem earlier and respond more closely to the requirements.

A quick-win, like a work around, might seem an attractive solution for reaching a desired goal, but in the long term it often (if not always) results in unpredicted (or unaccounted) adverse effects (such as increased failure of a system, need for support, impossibility to upgrade) and sooner or later you will need to address the root of the problem anyway.

Same goes with this blog post… I should release its first version now, and periodically check if accurate, fit for purpose, and take feedback as indicators to see if it needs to be amended or deleted!