[DRAFT]
Often software development projects go off the rails or deliver a low value end-product. Budgets are not getting any bigger and teams are trying to deliver more efficiently using various techniques. One of my favorite technique is to find the things that you don’t have to do before it’s to late (and we have already lost time and money doing it). This is based on the premise that most if not all software development projects include a number of things that do not need be done at all, and many that can be simplified or adjusted and still deliver the same business value. I have yet to find a project where there were no features, sub-features or technical tasks that could be avoided. One of the reasons this happens has to do with how most software requirements are defined: they are defined without much critical dialogue between business and technology. Therefore, in many cases we end-up missing on the opportunity to shape a product that is technically simpler with high business value. Developers that at some point receive the “spec” feel far removed or simply don’t bother to question a requirement that is complex to implement and just go ahead and develop complicated solutions that are not necessarily required by the business or could be easily adapted to suppress or significantly reduce complexity. Multiply this again and again during a project and you have a lot of missed budget saving and complexity management opportunities.
As a developer using this approach, I remember that one of the things that surprised me was the cumulative effect that simplification can have. Once you save a day or two by not doing something, all of the sudden you have that extra time (or part of it) to “freely” analyze other tasks to find more efficient ways of delivering them or perhaps avoiding them altogether. The later has the potential of giving you back large amounts of time/budget but are not always evident and often require that extra bit of time to allow an insight to surface or a new idea to be tested. We normally don’t have that time, so we need to create it ourselves. Furthermore, finding these opportunities to save time is very important particularly because the opposite is guaranteed to happen: you will always find things you did not anticipate or have budgeted for that you will need to deal with. Most projects have contingency buckets that are designed to help with this problem but those are also getting very modest.
Unfortunately, this avoidance strategy is underestimated or ignored by many as they think this is the same as simply cutting scope – which they are afraid will not be well received by their customers or stakeholders. This is a misconception, as the process of identifying, questioning and negotiating complexity will often lead to better software. In many cases the time we save by not introducing unnecessary complexity can be applied towards enhancing the product in high value areas.
