Simple is beautiful, stay simple.
This week I was asked the question by a new client about the common pitfalls when implementing GRC technology. There are a lot of specific examples but many of them have a common theme.
Every time you ask the system to do something, you trade the simplicity of the system in exchange for the request function. That sounds obvious but it is a trade that often goes undetected.
Lets jump into an example…
“Could the system default a value for particular users?”
A simple request. The answer, with most technologies, is ‘yes’. However there is a cost to this request.
- You will expend resource in discussing, designing, implementing, testing and deploying this change.
- You now have a specific rule which applies for some and not other, so you need to document and train users differently.
- You might also need to add interface cues such as explanatory text so as not to confuse users. This is a change in itself adding visual complexity.
- You have now created the need to manage users and groups correctly as there is am implication as to which group you belong.
- Alternate cases must now be considered. For example is it correct that if the first users has the field defaulted, when the second user (non default) looks at the same data the field remains or should it be cleared.
- Dependent fields or workflows must factor in this rule to ensure it does not break or block other functionality unintentionally.
- You will also effect the habits of the user. When defaulted users are less likely to check the contents of that field and will also resist changing it more.
- You have associated the system to a specific process, if that process changes the system will need to follow suit. The more this is done the less agile the business can be.
- Every future enchantment in the same area must take into account this and every other function as part of it’s design.
The above labors the point. But very few people are considering the implications of each request.
A properly designed system is a careful consideration of all of the requirements and information. The design should do no more or less than is required in the most efficient and effective way possible. Anything introduced after, risks the efficiency and effectiveness of that system.
Entropy is the law that everything in nature moves from order towards disorder over time. A sand castle will over time be reduced back into a pile sand over time. No amount of time will rebuild that castle.
I see a similar comparison in software, the more functions and features are added (and over time they will be) the more the system moves from order to disorder.
If you can’t explain it to a six year old, you don’t understand it yourself.
Some might argue that this goes against the agile software movement generally. Agile development recognises the need to refactor when things get too complex. Refactoring is where a portion of a program is reviewed in light of all requirements, designed and updated in isolation to the rest of the system. Refactoring only occurs within a limited portion of a system and therefore it’s improvement is limited.
Apart from in the case of complete redesign, a system will never become less complex. With each incremental change the system becomes more complex and closer to disorder.
Here is my recommendation, minimum viable product (MVP). Only install the functionality which has the biggest impact in the majority of cases to achieve the strategic aims. Be aware that every additional request comes at a cost.