A month ago, a talented member of our project team (no, not me) got the business people, developers and everyone in between to agree to a simple, elegant solution to a business problem. This week, all that hard work was undone. We’ve now got signoff on a much more complex solution – we need to do four calculations and one of these calculations is not like the others. So why does this bother me so much? Not because it creates more work (this is one time where laziness cannot afford to win out), but because it sets alarm bells ringing in my head.
Inconsistency
When your solution in one area is inconsistent with every other area in a domain, it’s a clear warning sign that you may be over-engineering. This is a problem because software users rely on consistency to make sense of what goes in the black box that is their computer. When they hit a button, they know an action will be taken. When they go to a new page, it will have the same layout. When a calculation is done, it will be done in a similar way to other calculations. Inconsistency has its place, but you should be aware that it may leave your users in confusion.
One scenario focus
Often these complexities are the result of only looking at one scenario in detail. One of the most useful skills of an analyst is the ability to look at all the scenarios a piece of software ’should’ cover, then to abstract a way of covering 80% of them. If one calculation is much more complex, then it most likely gives priority to one scenario above all others. In my example, the solution solved a scenario that happens once in a year – it’s an important scenario, but it has overshadowed slightly less important, but more frequent situations.
Harder to work with
In my example, the ‘different’ calculation requires additional processes and integration points to the other calculations. Firstly, this creates much more work for the developers. (We’re lucky to have smart developers, so it’s all possible). It also makes the system harder to work with once development is over – special consideration is required when you are adding, changing and maintaining features. Even with a range of super-automated-tests, the fallability of humans (magnified by the fallability of my memory) makes errors more likely in the future.
But what if all this extra complexity is required and just wasn’t thought about enough to begin with? I agree that this is completely valid, just that you need to be sure that the impact to users, developers and all others is considered.
Tags: requirements, simplicity