Simplicity

When I was a boy, my father taught me that simplicity is beautiful. For most of my life, I’ve tried to ensure my thoughts and actions follow this principle. Of course, at the beginning, I didn’t appreciate the true meaning of simplicity, and many times I chose complex instead.

The actions of people and what I saw, felt and heard, helped my mind develop and appreciate the true beauty of simplicity. Some great minds showed me and others how to achieve simplicity, leaving many to follow the phrase: “Why make it simple if I can complicate it.”

Those great minds were great teachers; they showed me what I did not want to do and, most importantly, why.

When I started DynaWare, Robert, the systems manager of one of my first clients, taught me a great lesson. He was a respected company figure (because he spent long hours doing ‘his thing’ and delivered, from time to time, reports that were used to make very important 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 in his mind, 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, every day.

At the same time, 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 find out why. The firm found several disconnected ‘non-systems’ that made users lives’ miserable. There was no single beginning to end 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, particularly when he had exceeded his bosses’ expectations. 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 evaluations 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, which recorded and shared it with the third computer to read 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 have it running in three months. My focus was on the process – recording and reading the entry time made the process too complex for the technology available at that time. This was 1983.

To simplify it, my solution was to give an initial grade at the end of the exam, then run an end of day collation process and publish definite grades the next morning. My idea was accepted. I created a completely 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 need in a reliable way. By combining industrial engineering process analysis and design with systems thinking, the solution was clear. Writing the code was a major 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 in order to keep their geniuses’ halo, and both sides reinforce it until the organisation reaches breakpoint and everything collapses.

Simplicity became our ‘weltanschauung’, something our new mission statement makes clear “… reliable and easy to use enterprise software …”.