The changing role of IT

The original focus of IT was efficiency and accuracy. Today, the expectation still includes efficiency and accuracy, yet adds increased revenue and expanded capabilities for customers.

IT has been with us for more than half a century, if you count IT as not only PCs and servers but also minicomputers, mainframes, and batch processing systems for accounting and finance.

Computers were originally large, expensive, and fussy beasts. They required an whole room to themselves. Computers cost a lot of money. Mainframes cost hundreds of thousands of dollars (if not millions). They needed a coterie of attendants: operators, programmers, service technicians, and managers.

Even the early personal computers were expensive. A PC in the early 1980s cost three to five thousand dollars. They didn't need a separate room, but they were a significant investment.

The focus was on efficiency. Computers were meant to make companies more efficient, processing transactions and generating reports faster and more accurately than humans.

Because of their cost, we wanted computers to operate as efficiently as possible. Companies who purchased mainframes would monitor CPU and disk usage to ensure that they were operating in the ninety-percent range. If usage was higher than that, they knew they needed to expand their system; if less, they had spent too much on hardware.

Today, we focus less on efficiency and more on growing the business. We view automation and big data as mechanisms for new services and ways to acquire new customers.

That's quite a shift from the "spend just enough to print accounting reports" mindset. What changed?

I can think of two underlying changes.

First, the size and cost of computers have dropped. A cell phone that fits in your pocket and costs less than a thousand dollars. Laptop PCs can be acquired for similar prices; Chromebooks for significantly less. Phones, tablets, Chromebooks, and even laptops can be operated by a single person.

The drop in cost means that we can worry less about internal efficiency. Buying a mainframe computer that was too large was an expensive mistake. Buying an extra laptop is almost unnoticed. Investing in IT is like any other investment, with a potential return of new business.

Yet there is another effect.

In the early days of IT (from the 1950s to the 1980s), computers were mysterious and almost magical devices. Business managers were unfamiliar with computers. Many people weren't sure that computers would remain tame, and some feared that they would take over (the company, the country, the world). Managers didn't know how to leverage computers to their full extent. Investors were wary of the cost. Customers resisted the use of computer-generated cards that read "do not fold, spindle, or mutilate".

Today, computers are not mysterious, and certainly not magical. They are routine. They are mundane. And business managers don't fear them. Instead, managers see computers as a tool. Investors see them as equipment. Customers willingly install apps on their phones.

I'm not surprised. The business managers of the 1950s grew up with manual processes. Senior managers might have remembered an age without electricity.

Today's managers are comfortable with computers. They used them as children, playing video games and writing programs in BASIC. The thought that computers can assist the business in various tasks is a natural extension of that experience.

Our view of computers has shifted. The large, expensive, magical computation boxes have shrunk and become cheaper, and are now small, flexible, and powerful computation boxes. Simply owning (or leasing) a mainframe would provide strategic advantage through intimidation; now everyone can leverage server farms, networks, cloud computing, and real-time updates. But owning (or leasing) a server farm or a cloud network isn't enough to impress -- managers, customers, and investors look for business results.

With a new view of computers as mundane, its no surprise that businesses look at them as a way to grow.

GUIs considered harmful

It's tempting to create a solution that uses a GUI program. Most people are comfortable with GUI programs and uncomfortable with command-line programs, so they prefer the GUI solution.

The problem with GUI programs (most GUI programs) is that they are not automatable. You cannot drive them to perform a task. GUi programs cannot be (easily) plugged in to other programs. The GUI is the end of the line, designed to be used by a human and nothing else.

The ability to use a program within a larger system is a good thing. We're not omniscient. When designing a program (and thereby automating certain tasks), but we also choose to leave some tasks to the human in from of the GUI.

For example, the task of deleting files (in Windows) can be performed in the Windows Explorer program, a GUI program. I can select a set of files, or a directory name, and instruct Windows Explorer to delete those files. For normal files, Windows Explorer performs the task with no other action from me. but if any of the files are write-locked (that is, flagged as read-only), Windows Explorer will ask me about each file before deleting it.

The folks at Microsoft added a button to the "are you sure about this read-only" file to tell Windows Explorer that I was sure, and that I was also sure about other files marked as write-locked. But this is an after-the-fact behavior, and only comes into play after the first write-locked file has been encountered. (Also, there is no way to tell Windows Explorer in advance that I want this behavior. If one of the files is write-locked, Windows Explorer will trip over the first one.)

The command-line command in Windows to delete files (DEL) on the other hand has options that can remove write-locked files, and you specify them in advance. With one action, you can tell the command-line shell that you are serious about deleting files and don't ask you any silly questions.

Command-line programs can often be used within larger systems. In Windows (and MS-DOS), one can use batch files to execute a series of programs. Unix and Linux have similar (although more powerful) concepts with their shell programs. And all of the major operating systems support redirection to accept input from a file instead of a keyboard.

Not all GUI programs are evil. Microsoft has done a rather good job of usable GUI programs. Their programs are often designed with two layers, a Gui layer and a lower layer that can be used by other programs. Sometimes this layer is a command line, sometimes it is a COM interface. But the work has to be done, the design has to allow for "bimodal" use.

It's all too easy to design a GUI program for the moment, implement it, and lock out any future increases in automated capabilities. A GUI program prevents others from automating tasks and often freezes the developer at a specific level of automation. A developer of a GUI program is in a comfortable position, with some (perhaps most) of the work being automated, and an expensive proposition for additional automation (changing or re-writing the GUI program). Once in this position, the developer ceases to think about improvements to the program -- the program is "good enough" and the developer convinces himself that the remaining work isn't that onerous. This is not a good place to be.

I don't advocate the elimination of GUI programs. They can be effective. But they can also lead to a stifled mental state.