Changing Requirements
- 1 minWednesday is usually the day we have our IPM (Iteration Planning Meeting) with our client to discuss what we achieved the week that passed by, but also make a plan on what to tackle next in the upcoming week. Today’s IPM was quite interesting to me in the sense that I realized even more how difficult it is to predict complexity.
As with most projects, in the beginning it is common to start off by keeping things as simple as possible when adding features and building the end product. Ideally, this trend will continue even further down the line, however this is often not the case at all for one very simple reason. Changing requirements.
Changing requirements means you have to prepare yourself for the moment that all the good work you put into simplifying your program, is now deemed obsolete. You have to prepare yourself for the moment you realize that what was once useful and simple, is now an obstacle. You must prepare yourself to go past that feeling though and seek the best solution possible even if that means throwing away a bunch of code*.
The big lesson here though is that the best guard against a situation like this, which is very common not just in our industry, is to prepare yourself mentally and accept the fact that changes will happen. Reevaluating a situation constantly helps you stay on the right track and by doing so, you’re bound to face changes. Learn to let go and always seek the best solution that you can provide as a response to those changes.
* Less == More.
Personal blog of Makis Otman