People ask me what I do for a living. It's a fair question, one I certainly feel comfortable asking other people, and, yet, one I can't easily answer for my own career. I tell them I'm an "industrial mathematician."

     A business operates some set of processes or activities within a set of limitations or constraints and realizes some kind of outcome, revenue or profit, from it. (How is that for a general definition of a business?) In its operation, a business makes choices or decisions that affect the outcome. The process of selecting the best decisions that stay within the business limitations is called "constrained optimization."

     My education is in a field called "Operations Research," so named because it started as the study of ways to help the U.S. military after World War II. It is also called "Management Science" with similar fields called "Industrial Engineering" and "Engineering-Economic Systems." In one form or another, these fields specialize in constrained optimization, finding the best solution amid a vast array of choices, maximizing a given objective within specified limitations.

     Those who specialize in these fields are typically academic professor types who teach courses and publish papers. I have taught a course and published a book, but neither of these are what I do for a living. Business organizations that do what I do are sometimes called "Decision Support."

     For twenty-five years I have worked in an office (nine years) or a cubicle (sixteen years) with a desk and a computer. My job has been to find ways to make things work better for somebody else, better in some quantitative way. My work usually helps somebody make more, spend less, or save time.

     An airline can decide which routes should be flown with which airplanes so most of the seats are going where most of the passengers want to fly. They want the biggest airplanes serving the biggest demand. When this is done years in advance to decide which airplanes to buy, it is fleet planning. When it is done months in advance so the central reservations system (CRS) can manage seat inventory, it is schedule planning. When it is done weeks in advance to respond to shifts in demand, it is demand driven dispatch. And when it is done in the last few hours to respond to unexpected events, it is systems operation control. All of these stages can benefit from mathematically sophisticated optimization models.

     Several business, including airlines, hotel chains, and railroads, have a limited supply of seats, rooms, or cargo space with demands at different prices. The mathematics of yield management determines which inventory is sold to which potential customers to maximize revenue.

     A company selling and leasing used automobiles bases its lease buyout price on what a car is going to be worth in four years. The more accurate their forecasts are, the more money they can make.

     Mathematical models can estimate the revenue impact of price changes, in a competitive environment or a local monopoly. Some models calculate the revenue impact of customer loyalty. Other models forecast market demand to maximize sales.

     A cellular telephone system is a complex network of radio towers (base stations), telephone switches, and communication links (trunks). Mathematically planned deployment of radio and telephone equipment can serve a given demand with fewer base stations and switches. Lower equipment cost can be used for increased profit or to lower prices for competitive advantage.

     The railroad industry in the United States has shifted from passenger service to freight transport. We think of Amtrak and feel sorry for the dying railroads while the rail freight business continues to grow. In the United States building a mile of new rail costs several million dollars and maintaining it costs tens of thousands of dollars per year. Figuring out where to add new rail to satisfy increasing demand or to reduce shipping delays is a hard problem.

     Mathematical models can estimate the costs of various components of business activity. Those models can help business determine what they really need to spend to serve their customers.

     A printed circuit board designer spends a great deal of time designing a circuit, placing component parts, and laying out the routes or traces that make the electrical connections. Sophisticated printed circuit board autorouting software shifts the designer's role from carrying out these tasks to managing the board design process. Software helps the designer work with the bigger picture, making sure the resulting board serves customer needs.

     Every mortgage in the United States requires a certification that the property is insured for flood damage or is not in a designated flood plain. These flood plain certifications involve hours of manual labor rummaging through government-issued maps. Image processing algorithms can convert a computer-scanned picture of a map into a database of flood plain regions by latitude and longitude. Time formerly spent sorting and searching through paper maps can now be spent evaluating the cases where a property is close enough to the edge of a flood plain that human judgment is required to make the determination.

     Airline planners dilute their expertise spending hours and hours comparing schedules and cataloguing changes, matching departures and arrivals in a weekend schedule, counting connections in a competitive market, and tallying unplanned jet engine maintenance events. Computer programs can perform these tasks so people can use their time figuring out how to run the airline.

     Mathematical models can perform repetitive tasks and can make basic decisions so experts can use their time being experts.

     A central theme in all my work is that it helps a community of people who do real work. In my professional life, I have never installed any telecommunications equipment, booked airline tickets or hotel rooms, flown or maintained an airplane for an airline, dispatched a freight train, bought or sold a used car, designed a printed circuit board, done a flood-plain certification, or worked in a factory. Yet I have been helpful to people in all these capacities.

     When I was a graduate student, I thought I might be able to run my own business. I designed, patented, manufactured, and marketed a phonograph tonearm for high-end audio systems. I learned enough about machining to build two or the four prototypes in the Stanford machine shop. The LOCI tonearm was terrific sounding, great looking, very innovative, and not a financial success. I learned that there is a lot to running a business besides sounding terrific, looking great, and being innovative.

     I come to work with a healthy respect for the people doing real work. My contribution to mankind's existence on this planet is making these people able to do more.

     It is the people who make things, who move things, who put things together, and who install those things who create wealth. The rest of us are along for the ride. A friend of mine showed respect for these real-work people when he said, "If you don't ship, you're overhead." If you're going to be overhead, then add value to the people who are not overhead.

     There is an old generation of "academic people" who study intellectual pursuits and teach students. While some of those students become academic people, others take their knowledge out into the world and use that knowledge to improve the work of making, moving, and installing. Many members of the academic community lack respect for the work that pays their way, but many professors and research laboratory engineers understand the importance of contributing to the work of making, moving and installing.

     There is a new generation of "process people" who create project plans and documentation. Much of this planning and documentation is for work that the process people, themselves, do not understand and do not care to understand. When a few dozen process people get together to decide how I ought to be doing my work, their contribution should be measured in how much more is accomplished by the people I work for. They are twice removed from actual work.

     While I produce plentiful computer software and acclaimed decision support systems, their value is measured in the uplift of wealth produced by others, in my case, in the telephony, airline, hotel, used car, flood plain, printed circuit board, and manufacturing areas.

     I used to tell people I was a mathematician or an engineer or an analyst or a programmer or a computer scientist or a consultant and all of these elicit stereotypes whose mold I just don't fit. I'm not sure that the term "industrial mathematician" fits, but at least it avoids these stereotypes.

     I'm not a mathematician. Over the last two centuries, the role of the mathematician has been increasingly an academic one. The mathematician explores the universe of axioms and theorems and teaches college and doctoral students about that universe. If there was a time when the primary role of a mathematician was answering questions to make industries run better, then that was a long time ago. Today, they produce papers for publication.

     I'm not an engineer. People who design new technologies are engineers. They typically work in labs with sophisticated equipment, creating, building, and testing new things. I have done this kind of engineering in my hifi hobby, but little in my professional life.

     I'm not an analyst. Working with pencil and paper, and perhaps a few computer tools, analysts primarily produce papers for production rather than publication. I have done this kind of work on several occasions, but my primary medium has been computer software rather than expository presentation.

     I'm not a programmer. The picture of the computer programming profession has changed in the last forty years from a mathematically-knowledgeable expert in computing to a person who carries out the specific instructions of an engineer. Then and now, the programmer is carrying out the vision of another while my software is written to support my own vision.

     I'm not an computer scientist. By the time the term "computer scientist" was invented, I had already figured out I was not really part of this crowd. The computer scientists seek a holy grail of computing, a unified theory of problem formulation and algorithm coding that brings engineering insights to software fruition. I believe that traditional methods from 1970 work as well as anything since then and the same effort would be better spent writing better software.

     I'm not an consultant. While my job title has had the word "consultant" in it and I have even worked for a small consulting company, I work best when my role is closer to the work than a vendor can be. Once a relationship is formalized and deliverables are planned in advance, my ability to find and to do small jobs that make big improvements is diminished. Over the last few decades, consultants have mutated from being mostly excess baggage to being costly parasites in American business.

     There was a time, as I recall from my youth, when the frontier was rugged, the going was tough, and programmers were real pioneers surviving on a rugged, frontier diet of Hostess Twinkies and late-night Chinese food. The computer center was a special place inhabited by a select few who could think in binary, octal, and hexadecimal and who could sit at a keypunch all night thinking deep, programmatical thoughts. From 1955 to 1975, these people built the software and databases that run our financial systems, our bookkeeping systems, and our communication systems.

     At the top of this rugged-frontier, tough-pioneering pyramid were the decision specialists who could program a computer. They were mathematicians, engineers, analysts, programmers, computer scientists, and consultants, and they were the real thing. On the glamorous end, they wrote the software that got spaceships to the moon. Less well known were the huge optimizations for selecting oil well locations and the small analyses for planning factory work. Along with the scientists and technology engineers was a team of computer geeks building the decision support systems.

     As I have said elsewhere, once the financial, bookkeeping, and communication systems were in place, the true value-added of the digital computer has been better decisions.

     On the one hand, the computer community has been obscuring this basic truth in building tools such as Microsoft Office to simplify, and to "dumb-down," documentation, visual presentation, and data organization. On the other hand, there is a growing community of charlatans riding the gravy train of the computer's association with smart decision making.

     A generation later, the descendents of these charlatans actually seem to believe that what they do is useful decision support. A host of simplifying and dumbing-down tools has grown up around this pseudo-technical community in the form of simulation, animation, and project-planning packages. When a gang of consultants works hard to build an animated simulation instead of working hard to figure out what the mathematical models should be, I don't know if they're sincere, but I do know they wasted somebody's time and money.

     I am the descendent of those pioneers. I have come to think of myself as the final descendent, the last of the buffalo one life away from extinction. I really do mathematics in an industrial setting.

_