Customers had extreme difficulty in installing and operating their System/360s. So, IBM established the role of “Systems Engineers” with the altruistic goal of helping customers making their installations and applications operational. The bug-laden software resulted in fix after fix, each fix reconciling some problems but introducing new ones. This all produced an enormous revenue source from the selling of Systems Engineer’s services. Communications of the ACM, May 2018. The March Into The Black Hole Of Complexity. Photo by Magne Træland on Unsplash.

I’ve often said that the other guy’s complexity and inefficiency was my job security. That wasn’t actually true, but for a lot of organizations I worked with that notion reflected the reality of the situation.

The most interesting example was the software development organization that thrived on software defects. When we cleaned up development and quit delivering buggy release candidates, the energy seemingly went out of the organization as things now just worked. When I went away for a few weeks I came back to an energized organization because my boss had pushed my team to deliver “fast” and the buggy results had everyone from development to configuration management having lots of exciting things to fix. My boss later admitted that he liked it better when releases weren’t so buggy and chaotic.

See Be Boring But Be Sure No One Knows

When I simplified defect management by characterizing our progress through computing the average (and 95th percentile) time to fix a defect, we no longer needed the myriad meetings to discuss when something was going to be fixed or when we would be ready to release the product. The average and 95th percentile better predicted when any defect would be resolved and when just about all defects would finally be fixed than all the meetings and estimates by managers and even the programmers fixing the defects. A lot of people didn’t like the reduction in complexity, the fewer meetings, the simple numbers to track because the simplicity didn’t seem right to them.

The only legitimate complexity I’ve ever observed was the complex interaction of all the simple rules and concepts we implemented. Once it all came together and we delivered software-intensive systems on time with good quality, it all looked pretty impressive to an outsider who didn’t understand all the concepts we were employing. Balancing and integrating all our improvements became the key challenge, but then they all added value whereas all the complex processes we had used previously often added no value or were reactive activities that fixed things other activities regularly broke.

See Being too simple

Now, was everyone happier in the more orderly, less complex, and more successful, but just as intense environment? No. Many people wanted it to go back to what it had been before. As with the organization that thrived on defects, the chaos made more people feel like they were part of things even when their activities were really no more than random noise in the completion of the project. This, however, was now a better class of problem, fixing the daily motivation and purpose, than was the buggy environments we had before.

Also, see Ya gotta know what is normal

What complex processes exist in your project that are probably unnecessary or counterproductive to the success of your project?