Fighting complexity in the real world
The past few days I’ve spent on fighting complexity. This time however, it wasn’t software I had to fight with but.. humans. I found it amazingly hard to deal with human individuals infected with desparate fear of taking responsibility. This fear combined with buerocracy resulted with ridiculous problems that should had never happened. Notice the “should never happen”. Sounds familiar?
It just came into my mind that our software faults reflect nothing else than human inability to handle problems. It isn’t computer’s fault to fail fulfilling what we expect from it, it’s the self-contradictionary reality humans create that prohibits computers from dealing with it successfully. We want machines to solve problems we produce but since they deal with numbers of them, they run very quickly into stuff that cannot be handled. This is why we point at software to be broken - it just seems it always fails sooner or later. But the core root of the problem is that our reality (society, law, processes, ways of getting things done) is broken, its parts are incompatibile and many things we want to achieve just cannot be done as planned. Neighter by humans, nor machines.
I had to provide some paperwork that everyone assumed should be a matter of no-time. But I got stuck when individuals started sending me one to another for providing more required paperwork. Eventually, one of them wasn’t available for long long long and the problem got unbearable. Classical deadlock applied to human reality. Eventually I succeded - but it costed me a lot of time and even more effort of thinking for others. What helped me was I came up with two parallel strategies to reach my goal of getting right paperwork done, in case one fails I had backup a plan being incrementally completed along. And that rescued me since the main plan was one to fail miserably.
When we develop software handling business logic, do we ever consider serveral strategies for achieveing the same goal? Do we consider alternatives? Bob calls Alice, Alice calls Marry. But can’t Alice call Bob and Marry in case Bob has empty account? Normally we don’t bother. A typical chess program does - it evaluates a number of strategies and picks one that has the highest factor for success. But in our everyday struggle we don’t even think about it. We always pick one way of doing particular thing and discard other ways even if they are all equivalently correct. We always assume things work this right way and in case they don’t, we just throw exceptions. Those exceptions escalate to higher levels capable of making desicions but in all cases either an error report is issued or another identical attempt is made automatically. We do nothing to increase probability of success, we only avoid failure at best, by retrying. So, if there are few ways of reaching a business goal, how about doing them in parallel, and letting only one to finish, in case all survive? We could have a few Bobs, Alices and Marrys set in different situations (reflecting problems that moght arise on the fly). In case no one fails, only one instance of them would report the solution, while other instances would be discarded. In case most of them fail, there still could be some instance left capable of providing results. It would spoil performace, it would make things more complex, but it would make our software more successful.
OK, I just wanted to write about how tired and frustrated I was past few days but instead I went off-topic and came up with some unprecised, insane idea, again.
