I’ve been asking the question to myself, why rewrite? From a personal level, when refactoring code it’s either to drive to an optimal solution, or an opportunity has been identified to take advantage of existing functionality for reuse. The benefits of refactoring are substantial to aid maintainability and reuse, but why do organisations believe that technology stacks should be rewritten in their entirety. The evolving nature of technology is reflected within enterprise by ‘The Re-write Anti-Pattern of Two Years’. Why is there a need to undertake a substantial risk and cost to perform this task that will not provide any new functionality? Is the focus for change driven by technology instead of the business? Are employees trying to justify their need to the business? Is it a political game of self-fulfilling prophecy? With all these, distortion is evident.
Humans do the following: –
- Observe a pattern
- Create abstractions and generalisations
- These generalisations form a framework
- People begin to subvert the framework
- Simplicity grows out of adversity.
Seeing structure is a primal instinct. The methods of how this is then perceived differ between individuals. When structures are deleted and generalised the results can greatly differ due to this; thus leading to distortion through over complicating the original structure. This distortion can be taken advantage of. Marketing companies develop strategies that take advantage of this by defining a proposition aimed at making things easier i.e. you have got yourself into this mess, we will get you out of it. A similar strategy is used by individuals within organisations to drive their status, or simply to provide them with a purpose within it (as identified by Cyril Northcote Parkinson “Work expands so as to fill the time available for its completion”).
Controlling distortion
How do we combat these primal behaviours in humans? History sets out the use of faith and regimes to align behaviours to the common goal. The same must be followed within IT. Dan North advises that the best way to deal with this is by enforcing rules such as ‘Five Whys’, or time boxing. Examples of the use of these could be around the design of a trading algorithm, or to a project where a result must be achieved either through completion or identifying as waste. If the latter occurs, lessons must be learnt to understand why. Was the correct problem identified? Was the problem articulated to ensure that different solutions were identified and evaluated to identify the simplest solution?
Identifying the correct problem
Problems can be too large for a human to conceptualise. To enable the problem to fit, the problem is changed/distorted into another. To get around this problem every dependency is questioned. Questioning like this helps to identify where the problem really is, and also helps view the problem from different perspectives. This helps in pulling value rather than pushing a solution into a distorted problem. An example of this is an IT project driven by IT and not by the business.
Simplicity is the art of maximizing the work done
By identifying and eliminating waste, we produce more by doing less and being more agile. Staff members become more agile and are able to adapt to change; therefore less inventory and craft is required. This provides focus on delivering an optimal solution to the correct problem.
Simplicity is the key to success
In short, if your problem is large or small a limit should be placed on the time taken to solve it. A distorted view of a problem will lead to an over complicated solution to it that has been recognised by IT but not by the business. This over complication leads to an increase in complexity. Some would say that simplicity is the key to success within IT, this proves to be true.