Theory and Practice

Starting with our considerations about design it should in fact be no problem to implement even a complex development project successfully and future-proof: Based on prototypes we first clarify all open issues and can then construct modularly. Questionable constructs are avoided a priori at best - any need for them will not arise yet because we are developing in compliance with "agile project management" and thus will have all options open at any point of decision.

Common practise, however, often requires to reach important goals much earlier and especially with lower costs as it would be the case for the described solid approach. Out of the understandable but at the same time risky endeavour of saving as many steps in the development process as possible, among others, the following questions will arise:

• Where can we start immediately with a modular construction, where, on the other hand, do we better go for a prototype in order to gain important insight?
• For which subareas we directly can construct monoliths without running the risk of having to start again later?

• How shall we handle those requirements that have not been cleared adequately, simply because not all important informations were available at project start?

We have to keep in mind that even an "agile project management" will not be helpful in these situations, because what we are searching for is a shortcut versus a solid approach (regardless of the process model)

Quite often we are producing significant costs somewhere we would not have expected only after a failed attempt to save work somewhere else. This dilemma seems to be well-known, at least there is a Zen-saying addressing it: "If you are in a hurry, go via the roundabout." Nonetheless developers are frequently confronted with the following situations:

• Evidence for important design decisions sometimes is very poor.
• Due to a tight schedule for the project, design decisions turning out to be wrong at a later date cannot be withdrawn anymore.

• In previous projects we might have made the experience that despite of a tight schedule it would have been better to change a bad design as early as possible. In practise, however, nobody will dare to take responsibility for a radical redesign, because this actually right decision would turn out being vulnerable in any case of failure. Hence, the statement above applies in general: A bad design decision at the very beginning cannot be withdrawn afterwards anymore.

Searching for Water

The challenge is to reach the project objectives even when available time and informations actually do not provide a trustworthy base for long-term design decisions. Immediate technical skills will not be sufficient, at least not under such circumstances. Instead the question is which solution path to go for among the possibilities at hand. In the following sections we will exemplify the underlying abstract problem by means of "searching for water", showing by means of analogies what should be especially payed attention to in our opinion.

Tried Everything

The illustration at hand shall express the following:

• In order to save effort for search, a standardized approach has been chosen, which may be easily replicated at different spots.
• Though test drillings have been performed everywhere it was seemingly expedient, no water has been found.

• Finally, the site was abandoned, because it seemed to be evident that there was no water - at least "everything" had been tried.

From a fully-informed point of view, the failure can be assessed as follows:

• The limitations of the chosen approach (shallow drilling-depth) obviously have been underestimated.
• Successive flops should anyway have sown the seeds of doubt about the approach.

• Whenever we have been successfully using certain technologies and approaches sometimes earlier, we tend to resume former best practice without re-assessment of its suitability.

Thoroughly Worked

The illustration at hand shall depict the following:

• Presence of the tree has been rated as certain sign that there must also be water.
• According to this, no time has been wasted on testing drills. Instead, a final drilling rig has been mounted instantly in order to drill deep.

• When all resources have been consumed, the site had to be abandoned, because despite of deepest possible drilling, no water could be found.

From a fully-informed point of view, the failure can be assessed as follows:

• We never should abstain from verifying important basic assumptions.

• Our approach should include handling of worst case scenarios such that we even can react in case a strategy fails that actually had been considered as reliable.

Worked to the Utmost

Our last example shall illustrate a successful but nonetheless problematic case of searching for water:

• We started on base of a proven approach (vertical drilling) without verifying, if this is most suitable for the current conditions.
• After noticing that the goal will not be reached that way, we changed direction in order to make the best of the first drilling. We also overlooked that we already were too deep.

• Finally, we ended up very close to the target with only a short vertical drilling still missing. Although just this last part of work provoked severe technical difficulties, we carried it out finally.

From a fully-informed point of view, the failure can be assessed as follows:

• Even the first approach based on a vertical drill was actually wrong, because obviously it would have been much easier to drill horizontally at the foot of the mountain right above.
• Even after reaching the horizontal ending point below of the lake it would have presumably been much easier to abandon the whole previous drilling and rather restart at the foot of the mountain going in horizontal direction.
• Apparently it has been underestimated how much costs the seemingly "last 5 percent" of a solution can cause.

• Compared to the simple alternatives that would have been feasible, the construction in total has evolved unnecessarily complex and thus will entail high maintenance costs in the future.

Conclusion on "Search for Water"

The comments on the exemplified scenarios are based on a "fully-informed point of view" that will never be reachable in reality:

• If we are failing like shown in the respective scenario, we typically will never know how close we were to a possible solution or rather, in which direction we would have had do search for one.

• Even for the last example, when the goal has been reached, we hardly will find a project team which will devaluate its success in hindsight and, for example, will admit: "We could have done it much simpler instead!" Rather the team members will refer to their exceptional performance, by which they finally accomplished the last vertical drilling, in spite of all troubles.

Biased Perspective on Solution Paths

In a real project situation, when we want to assess possible solution paths in advance or rather rate the results afterwards, we normally will be confronted with a wide range of diverse opinions:

• Decisions on the approach when searching solutions are mostly based on incomplete information and thus leave much room for personal interpretation.
• As soon as we have to enter uncharted territory in a project, we typically will try to choose solution paths in the style of already exisiting positive experience. The range of choices here naturally depends on the know-how already present in the project team.

• Last not least the organisational environment of the project aims to directly or indirectly influence on which solution paths at all are shortlisted.

Thus the search for solutions will develop a strong momentum of its own depending on the respective project situation, where it is almost impossible to decide in advance, if a pursued strategy is the best one, or even if it will be successful at all.

Even in hindsight, in most cases it is not possible to determine, if a different solution path would have yield a better result, or which other strategies would not have failed. Under these conditions there will be no learning effect leading to benefits in later project situations, at least.

Compensating Missing Information

This dilemma may be addressed best by neutralizing those consequences that are caused by missing information at project start:

• Quantifying in general is better than estimating. No technical decision that will entail significant costs should be made without adequate basis of information. Relating to our example with the drillings this means to set up the test drillings as sophisticated as necessary.

• Dependent of the application case we should be open for a wide spectrum of technologies for approaching the solution. For our example concerning the overpriced success this could mean for instance to actually perform the horizontal drilling, or even to abstain from any drilling and instead lay a pipeline over the mountain.

Consequences for Development

Naturally every gained certainty comes at its price in terms of addictional costs incurring at the beginning. These expenses, however, are considerably put into perspective due to the following reasons:

• The term "quantifying" used above can in software development be seen as a series of prototypes. Especially in a partially uncharted area it should go without saying to create prototypes of predictive power at first to avoid later costs caused by unexpected obstacles.

• Narrowed down to the essential of an issue, it is mostly surprisingly simple to yield reliable prototype results. Insofar it will not really be a problem of costs if we want to check out several diverse approaches. Last not least, a prototype may be reused to extract the quintessence for a final modular construction, and be it only in terms of exact knowledge about actual requirements.

From a developer's point of view there is the chance to even out the uncertainty when searching for solutions by means of constructional-technical skills. In order to keep the costs low, the following technical skills are most important:

• the ability, to quickly create reasonably reduced prototypes, even for complex issues;
• high quality of the prototypical implementation such that it will be possible to take over essential elements into the final construction with little effort;

• having a feel for dealing with different technologies in order to choose the most appropriate one for the project environment and application case at hand.