Thinking Patterns

(Photo from Free Images Live)

It has been a good while since I did computer programming or database development as my main focus. It has become subsidiary, only a part of a larger purpose. But in the past few days I had occasion to do some in a language I hadn’t used for many years. It’s a language especially well suited for engineering purposes.

It’s well suited for people who need to know how things work so they can monitor and analyze what matters, then adjust and control it in the right ways, even when the equipment they need to manage runs very fast.

Old programming languages are not popular these days. The most prominent of them are sequential procedural languages, which means they are intended to do operations in a specified order. Their job is straightforward, so the executable programs they generate can be streamlined and run very fast.

Prominent languages now tend to be object oriented, in which they are intended to do operations in chunks that don’t care about running in any particular order. The cost of that flexibility is high overhead. That causes object oriented languages to generate executable programs that run slower.

Machinery tends to work in well defined ways and can run very fast. This is an obvious natural match for sequential languages. People are notoriously unpredictable and slow compared with machinery. This is an obvious match for object oriented languages.

Ideally, companies and programmers should choose the language that best fits the purpose of the software they want to create. Unfortunately that isn’t usually what happens.

Why?

Initial Answer

People use what they know to make decisions and can’t use what they don’t even recognize.

When I went through university studies, computer science degrees didn’t exist. I took courses about building circuitry (yes, building primitive computers with AND, OR and NOT chips and wires) and about software, but they were only a small part of a degree in electrical engineering. Because I went to an especially rigorous university, for the introductory programming course my main project was to write a program that emulated an entire DEC computer within a larger IBM computer. This meant I had to learn how an operating system works in order to imitate it. I worked in engineering for a few years before switching to developing software.

Although I didn’t realize it at the time, this meant I learned the way things work on the inside of a computer before I started writing software. That was crucial.

For several years I worked intensively with large complex near-realtime mission critical systems alongside others who got there more or less like I did. Then I set up as an independent small business, often still working with such systems.

My projects began to be with teams of younger programmers, some of whom had university degrees in computer science.

They didn’t grasp what I regarded as fundamentals. One of them responded to the news that I had put a large (by the standards of the time) new hard drive into my portable computer by grabbing its handle and bouncing it on the table while it was running. I’m lucky that he didn’t cause a head crash and ruin the drive. It turned out he had no idea how hard drives work and didn’t know how easily drives at the time could gouge the delicate platter surface if they were bumped while running.

I began occasionally asking questions of the young computer science graduates I worked with. They rarely knew the strengths and weaknesses of the programming languages they had learned, or the operating systems they knew how to work with.

How Platforms Are Chosen

When their employers wanted to build a new IT system, managers asked technical people for recommendations. The young CS graduates recommended whatever they had become familiar with at university, oblivious to whether better options were available.

I saw systems that cost orders of magnitude more than necessary to build and maintain because they were built on operating systems and with languages that did not suit the purpose of the system.

Sometimes this was aggravated by code that was written the way a professor would like to see it, not the way a business would prefer. For example, one of my professors at university gave the highest grades to programs that used obscure tricks. In the commercial world, the slang for that is slick code and it is much loathed. As a general rule, for every dollar you spend to develop a software program, you’ll spend at least four dollars on maintenance and enhancement during the life of the program, more if the software isn’t very well designed and managed. Obscure tricks are hard for subsequent programmers to understand, maintain and modify to add new features to a program. Companies hate that because it makes the lifetime cost of the software higher.

But at the heart of it, breadth and depth of knowledge limits the recommendations anyone can make. A lot of information technology systems are built based on choices made by people who do the best they can with what they know, but they aren’t aware of enough information, so their recommendations fall short.

A Little More Depth

For years I thought choosing the most familiar platform without knowing enough about the way computers and software work explained why so many projects choose a poorly suited platform. For years, maybe that was true.

Then object oriented languages became so popular that they shoved sequential languages to the background. Another factor stepped in.

The way a programmer needs to think in order to write excellent code depends upon the type of language being used.

Sequential languages fit nicely with concrete analytical thinking patterns. Such patterns are common among engineers, for example, and many of the old-school programmers came from engineering like I did.

Object oriented languages thrive on abstraction, so they fit nicely with abstract intuitive thinking patterns, which are the opposite of concrete analytical patterns. Abstract thinking is common among quantum physicists, for example. The financial sector is all about the erratic nature of people combined with the abstract concept of money, so in retrospect it makes perfect sense that the financial sector hires a lot of physicists to develop its elaborate modeling software.

Your thinking pattern is part of how your brain is wired. Concrete analytical thinkers like me have immense difficulty with abstraction, and abstract thinkers have immense difficulty with concrete analysis.

I can read object oriented C++ code, as one of my employees discovered to his dismay when he didn’t check his code well enough before asking to submit it to our client. Twice in a row, I found bugs in his code by just reading it. (He was more careful from then on.) But after a few months of trying, I found that no amount of study and practice would make me better than mediocre as a programmer with it. I needed to leave that to him.

He could not wrap his head around an arcane language our client had developed for a special purpose. It was a clunky, cryptic sequential language. I’ve done excellent work in a few sequential languages. My mind picked up that weird one readily.

So this is a factor now, too. When a manager asks a technical team to recommend a platform for a new computer system, the team has to recommend something their thinking patterns can handle. Anything else would require them to use tools with which they cannot produce excellence. At best, their jobs will be harder, their performance will lag, and they won’t get as much of a pay raise as they want. At worst, the boss could be so frustrated by their lagging productivity that they lose their jobs.

Where they are abstract thinkers, they need to recommend an object oriented language, even if it’s an automation system for a factory or a telecom system where achieving enough speed with a slow-running language will require spending more on heftier hardware.

Where they are concrete analytical thinkers, they need to recommend a sequential language, even if it’s for a system that mostly interacts with highly unpredictable people or events that would be less cumbersome to handle in an object oriented language.

A big company may be able to afford to have both types of thinkers on its staff, which eases that pressure on the choice. But whenever yours doesn’t have both types of thinkers, making such choices in-house brings this pressure into play. Even if people know enough to recognize that what they work with best isn’t a well suited platform, they dare not say it, because either they would end up struggling to turn out substandard work or they would end up replaced by someone who naturally thinks the way the right platform demands.

Patterns of thinking matter. It isn’t that either pattern is right or wrong. Each has its strengths… and weaknesses. The smartest companies recognize that choosing the platform for a computer project is about more than the technical options. It’s also about the people available to do the work, and it may require adding to the team so they have the range of thinking patterns needed.