When I was a boy, my father taught me that simple is beautiful. For most of my life, I’ve tried to align my thoughts and actions with this principle. Of course, in the beginning, I didn’t appreciate the true meaning of simplicity, and many times I chose the complex path instead.
People’s actions, what I saw, heard and felt, helped my mind appreciate the true beauty of simplicity. On one side, great minds showed me how to achieve simplicity. On the other, some seemed guided by the “Why make it simple if I can complicate it.” principle. They showed me what I wanted and what I did not, and, most importantly, why.
When I started DynaWare, Robert, one of my first clients’ systems manager, taught me a great lesson. He was a respected company person because he spent long hours doing ‘his thing’ and delivered, from time to time, reports that were used to make crucial decisions. Almost no one understood the new field of computer software, those who did were considered geniuses, and they were.
When Robert presented his report results, he explained what he did, yet no one understood, but everyone praised him. This reinforced the idea that complexity was highly valuable, so he increased the complexity of his reports and presentations without realising he was reducing his productivity and wellbeing day by- day.
Simultaneously, the C-Level maintained their belief that computers were for geniuses and ‘they were never going to understand them’. They accepted such complexity was inherent to ‘that thing’ without realising it was damaging business processes and profitability.
A few years later, the organisation suffered financial problems, so they hired a productivity consultancy to determine why. The firm found several disconnected “non-system’s” that made users lives’ miserable. There was no single beginning to end business process, and data had to be reprocessed in an attempt to build usable information.
Some roles were cut, one of those being Robert. I remember his expression of total disbelief; he simply could not understand why he was being fired, mainly when he had done everything to exceed his bosses’ expectations in complexity. Weeks later, the CEO and CFO were also fired. They, too, could not believe it. They knew computers were complex and relied on the experts to do their thing’.
In contrast, I remember visiting my dad’s office. He was VP at a Fortune 100 Mexico subsidiary and the area responsible for computer systems was named Processes and Systems. Such details make the whole difference; processes first, then the systems.
At the time, I was half-way through an undergraduate Industrial and Systems Engineering programme at Tecnológico de Monterrey, working part-time developing software and teaching computer programming at their high school.
New Mathematics tests were undertaken using computer-generated and graded exams. There was a 60-minute limit where one-hundredth of a point was taken off for every additional minute taken. The systems director and his team developed a three Apple II computer system connected via 9-pin serial cables.
The first computer registered the start time, sending data to the second computer, which recorded and shared it with the third computer, which read the data later. The third computer graded the exam and calculated any additional minutes taken by the student. Every time computers one and three collided (when simultaneously sending, saving and retrieving data from computer two), the system crashed, and a reboot was required, losing data and time. It was not working.
I was asked if there was an alternative solution. I answered yes and committed to having it running in three months. My focus was on the process – recording and reading the entry time made the process too complicated for the technology available. This was 1983.
To simplify it, my solution was to give an initial grade at the end of the exam, then run a lot of day collation process and publish definite grades the next morning. My idea was accepted. I created an entirely new solution in less than a month. Needless to say, the experts who complicated the process were upset with my simple solution.
‘It is not fair’, they said, ‘the goal was to solve the challenge as it was defined’. They didn’t get it. The real goal was to satisfy the client’s need in a reliable way. By combining industrial engineering process design with systems thinking, the solution was clear. Writing the code was a significant challenge, but a huge unnecessary obstacle had been removed.
I learned first-hand why enterprise software is built for complexity. It follows a viewpoint or ‘weltanschauung’ as Cecil Rhodes and Peter Checkland called it. Many enterprise software designers and builders embrace complexity to keep their geniuses’ halo, and both sides reinforce it until the organisation reaches the breakpoint, and everything collapses.
Simplicity became our ‘weltanschauung’, something our purpose statement makes clear: “Deliver powerful and simple solutions to complex enterprise problems”.
Rafael Funes
Chairman of LOVIS
