Ignoring the fact that the word “event” has a special meaning in software development I will proceed to use it in its broader definition as “something that happens”.
Building software to solve a “business problem” can be daunting enough and leave all sorts of cracks in the relationship between IT and Business. But if those cracks were not visible or wide enough from the initial design phase, then start to introduce changes to business requirements and watch the Grand Canyon form between the departments.
Why is change such a hard thing to handle? And especially within software?
One of the big issues is in the title; Software events vs. real life events. Software events are binary of nature. Everything needs to be specified or left out by deliberate choice. Software is built to handle and encompass real life events of the business area or problem it is built to solve. A lot of analysis, decisions and compromises will have gone before the final design of the software. These can be more or less correct (there is no such thing as the correct solution) but nevertheless they are written in code and hence, as mentioned earlier, binary.
They are built on assumptions and analysis of how the world works in relation to the problem the software is built to solve. These assumptions can be more or less correct and even their correctness evolves over time, as the reality on which they are based, changes.
Real life can operate inside binary rules. It can even seem like real life follows these rules. Right up until the point, where they do not. Then they just change.
Small changes are usually okay. You can add a little more information here and there. Perhaps even remove some. The big clash with software happens when the change in real life goes against a “rule” on which the software is built.
When designing software you are always making compromises and opt outs in order to reach the final design. These compromises and opt outs are based on your knowledge about the reality in which your solutions operates. Some of these will be based on “hard” facts and other will be based on “history” or “experience” and lastly some will also be based on assumptions.
Assumptions could sound like the “worst” kind as it seems like the least researched or analysed. But assumptions are not bad per se. If you know that you are basing a decision on an assumption, then you also know that it may change in the future. This hopefully leads to an implementation based on that assumption which is designed for change.
History, experienced, and hard facts are actually potentially worse, as they are things that will be designed as “truths”. Meaning that the compromises surrounding those will probably be more rigid and not built for potential change in the future. This can give serious issues once they do actually change.
The problem with real life events vs. software events is that real life is always fluid. What is reality today will change tomorrow. Software design needs to take this into account and not only think about it but also design for it. D. L. Parnas even proposed having “potential change” as the main driver behind software design. This of course needs to be countered with another important point from a historical figure:
“Premature optimization is the root of all evil” – Donald Knuth
But it is an important point that the ability to change should have high priority in software design. We cannot predict the future, but we can try to make sure we are ready to adapt. The real test of software architects and developers is how good they are at hitting a happy medium of changeability and “hard truths”. Sometimes we architects and developers can be a little too “binary” in our thinking and force limitations on end-users, that seen from the business or end-users perspective does not give much value. We can be a little “too clever” at times.
Of course it is never easy to strike the “happy medium”. We will have times where we end up in the “too rigid” and we will have times where we end up “too changeable”(costing too much to develop). But hopefully with experience and enough humbleness and hindsight to acknowledge own mistakes we can get better and ensure that we improve over time.
Top comments (0)