Technical Decisions Series - Riskiest Thing First and Architectural spikes

Dealing with the Riskiest things first

Niccolo Machiavelli was excellent at risk management- in his own unique way- understood the importance of taking action on problematic situations as early as possible. He writes :

"All prudent leaders, have to regard not only present troubles, but also future ones, for which they must prepare with every energy, because, when foreseen, it is easy to remedy them; but if you wait until they approach, the medicine is no longer in time because the malady has become incurable; in the beginning of the malady it is easy to cure but difficult to detect, but in the course of time ... it becomes easy to detect but difficult to cure."

When time passes by, the problem becomes obvious, but the cost of dealing with it becomes extremely high. This is all about the increasing Cost of change as examined in Decision Reversibility post, in Complex evolving systems

It is important to Determine the Riskiest component first and then deal with this as early as it is possible. If  there is a decision that you manage to deffer commitment and finally should be included in the solution but you find out that it is difficult to implement, then there will be a high negative impact. It is important to identify the decisions in a design process that  1)are going to impose a significant problem and  2)that are most likely to be included at the final solution design and then assure their feasibility.

As a general principal this can be stated as "Explore the riskiest thing first".  Also known as Worst Things First. There is debate about this principle in software development world.

Architectural spike

Agile Architecture embrace the principle by including spikes

A spike is an experiment that allows developers to learn just enough about the unknown elements in a user story. Architectural Spike is not only about the feasibility of a solution, but also should be used in order to get a better estimation of the time and resources that will be needed in order to be implemented a solution.

Spikes may be used for a number of reasons:

• Spikes may be used for estimating upcoming Features
• Spikes may be used to perform feasibility analysis, and other activities which help determine the viability of Epics in the business and architecture portfolio kanban systems
• Spikes may be used for basic research to familiarize the team with a new technology or domain.
• Some features and stories contain significant technical or functional risk, spikes can be used to gain confidence in an approach

Business Design Spike

Ash Maurya in his blog post explains in detail the need to identify the riskiest assumption in the business model.