Pittsburgh Years

VirtualPLANT

pittsburgh.jpg

                          

 

 

S

elling remained difficult for me; I never got used to it.  It was not so much that I couldn’t do it; I was in fact not too bad at it when I put my mind to it.  It was simply that I didn’t like it, and for me that made it hard to be consistently good at it; it was drudge work, something one had to do.  My father had said that any job, even the least desirable, could be improved, Thought Of in such a way that it was possible to become better and better at it.  Shoveling a big pile of gravel into a truck comes to mind: start at the bottom of the pile, at the ground, and work a slot into it, then develop a steady rhythm; it works much better than just poking the shovel anywhere into the pile to get a shovelful.  I tried to apply this concept to selling, an endeavor surprisingly close to shoveling gravel.  I acquired the steady rhythm of selling but I didn’t like the one-on-one talking and convincing, the supplication part.  It seemed demeaning. 

Everyone has to sell, but there is a difference in how it works and in what the goals are.  One might sell oneself into a salaried position that could conceivably last a lifetime.  In this case the selling part becomes nominal, a difficult effort perhaps, but in this case the difficulty is amortized over one’s entire lifetime.  But in selling a small product, or even a service, one is constantly selling and the selling effort is a high fraction of the entire enterprise; this is where I now found myself.  I can't say I had analyzed it in this way at that time; it is an analysis I came to only in retrospect.

By now The Simplex Group was a going concern, not wildly successful, but OK.  We were making money, certainly more than I had ever made working at Dravo.  And I was beginning to get used to the unavoidable up- and down-ness of business.  More importantly, with Tricia working with me, I had more time to think about other things than simply where the next sale would come from.  By this time she could pretty much run the company herself, and she had a knack for business that was better than mine.

I asked myself: Since I very much liked designing things, and since I seemed to be in the software business, Why couldn’t I design some software?  Primavera was still a relatively small company (fewer than 200 people), and I had come to know the two fellows that ran it on a first name basis: Joel Koppelman (sales and marketing) and Dick Faris (design and production).  And Joel was a master, a natural, at selling and marketing.  I think he liked it!

Gradually I conceived of the idea of designing some software for Primavera and then, since they had plenty of programmers, they could code it, and since they had a large sales organization they could market it and sell it.  This would leave me free to design something else, just what I enjoyed the most.  With this notion, while I would not completely be out of the selling business, I would only have to make one big sale and that might, if I was lucky, lead to an extended design project.  But what could I conceivably interest them in?

I talked over the idea with Tricia; it would certainly put a bigger load on her shoulders.  At that time she coined a phrase that she was to repeat to me at intervals long into the future, “Bud Goetsch alert!” by which she meant that I was beginning to act like my father.  She had met him, and she had heard me talk of his many inventions, all unique but, money-wise, problematical.  But she voiced no objection; we weren’t going to invest much money in the deal, just my time.  Or so it seemed then.

It came to me slowly.  One of Primavera’s main competitors was Project Software And Development Incorporated who leased the use of Project2—one couldn’t buy it, but had to pay forever for its use.  It was a most elegant mainframe project-scheduling program that I had used for many years at Dravo—but expensive.  P3, Primavera’s Project Planner, which ran on microcomputers, was now beating them up pretty badly in the market: it was much cheaper; it could be purchased once and for all; and it ran on inexpensive microcomputers.  PSDI, seeing clearly that they were being cannibalized by this upstart company, had developed and was now selling a new software product called Maximo.  And it was beginning to make more money for them than Project2.  Its focus was Plant Maintenance.

Complicated factories, chemical plants, refineries, and other such industrial facilities require an unending, and very expensive, amount of maintenance: motors must be lubricated at the right times; filters must be changed promptly; painting must be done on a routine basis; often, piping must be replaced; the list goes on and on.  And that covers only routine maintenance; when something actually breaks down—if it is crucial—it must go to the top of the priority list of things to be done.  All this is scheduling, but of a different sort than building the facility in the first place.

Some of these plants are huge; a large refinery, for instance, can be measured in square miles; and the amount of very expensive equipment in it is overwhelming, so much so that no new plants have been built for years and, as far as I know, none are anticipated.  Doing equipment maintenance on a routine basis has been shown to significantly lower the cost of operating industrial plants because it’s cheaper to perform regular maintenance than to wait until something really goes to hell and the whole plant has to be shut down to fix it. 

PSDI’s Maximo was a product that, among other things, printed out routine, daily work orders in order of priority so that repetitive maintenance work, which could easily be forgotten, was not overlooked.  Another benefit is that in using this sort of software one is required to develop and maintain a current list of all the assets contained in an industrial plant: hundreds, usually thousands, of quite expensive things.  This is useful in a number of ways, not least in Accounting, simply for tracking one’s assets and depreciation.

It seemed to me that Primavera, now that they were beginning to beat PSDI in selling scheduling software, might be interested in maintenance software so that they could compete in that market niche is well.  I began to think about that.

By that time in my career I knew quite a bit about plants of different sorts, complex ones, and since I had been a draftsman, I thought about them as a draftsman might: visually.  I made some sketches on what were then called foils, thin transparencies from which the sketch—drawn using special ink with a felt-tip pen—could be shown, using an overhead projector, onto a screen made for that purpose, or even simply onto a wall that had been painted white.  (PowerPoint presentations had yet to be invented.)  This technique—for its day—was fast and cheap, if not very professional looking, but it was certainly a good way to get ideas across to a relatively small audience.

The Novell computer that I had bought some years back had turned me on to graphics; its screen was a high resolution vector-graphics screen, unusual in those early days.  And now Software Engineering was migrating from textual screens to graphical screens that were supported by windows.  They were not vector screens, but they were graphic nonetheless.

My at first vague idea gradually began to gel into a design for a graphical computer program with which to represent the various major buildings, structures, or equipment-clusters of an industrial plant.  This representation was not to be detailed, simply diagrammatic so that the people at the plant could recognize the various systems and buildings which they knew very well.  Then, just by clicking on one of these major visual symbols a new and more detailed visual that represented the major elements of equipment in that particular building or structure would be shown.  And when a major structure on that screen was clicked, the visual would change to a different and yet more detailed view in which  piping and ducting and major electrical routings could be shown as well.

This step by step expansion could be carried to whatever level was necessary or convenient.  And at all times the plant personnel would understand implicitly, graphically, just what it was that they were seeing.  They weren’t confronted with long and incoherent textual lists of equipment numbers as was typical previously.  I planned for notes and commentary to be added anywhere as well.  It seemed to me that this concept was well-suited for the kind of people that do maintenance: only a little aggravating typing for these boys with big fingers; mostly just clicking into something of significance.

In addition, when needed, one could simply select a visual element of the plant and bring up information about it on a subsidiary, tabular screen, similar to a spreadsheet.  All the time I had spent listening to sets and sets of engineers of different types explain their work now began to pay off, or at least it was instrumental in the fundamental idea of the product.  Eventually this product became named VirtualPLANT.  To my knowledge nothing like it had never been developed before; it was a combination of a scheduler-draftsman’s way of looking at things.  Previously all such information had been only lists of textual information stored in a database of one sort or another.  The visual way of looking at complex processes, including the piping and other elements that connected them with each other, was then new and very intuitive for the people maintaining the plant who were not, in general, computer-savvy.

All this new technology was enabled by the current change taking place in operating systems; new ones, such as Microsoft Windows were inherently graphical in nature and that made it a great deal easier to develop the sort of software I had in mind.

I spoke with Joel Koppelman at Primavera’s offices in Philadelphia on the telephone.  I described the basic idea and offered to come to Philadelphia and discuss it with them.  He was interested, but noncommittal; but he told me that if I came (on my money) he and Dick (Faris) would listen to me.  Here I was, selling again, but this was different: I was selling a concept, and one I could get excited about.

I have always found that business people in general, and entrepreneurs in particular, are usually willing to listen, but not just to anyone.  One needs a certain credibility; they are busy people.  My cred, as it turned out, had, unbeknownst to me, come from a speech that I had once given at a Primavera Users Conference when I had still been with Dravo.  The subject of my talk had been the use of networks of microcomputers for construction sites.  A rather new idea at that time; old-hat now.  I learned later that Dick and Joel had been impressed.  That was in my favor.

This learning to speak in front of hundreds of people had not been easy for me but, once one overcomes a certain stage fright, it gets easier and easier as the audience disappears from one’s mind—while still physically there.  When that occurs one can become interested in the subject one is spouting-on about and seem quite natural.  That is certainly the trick, if there is one, to public speaking.

I flew to Philadelphia.  My presentation, which was to have taken an hour, stretched on to two or more.  They were interested and very direct, no beating around the bush.  Joel Koppelman asked me what I wanted to do next, and what kind of a deal we could make.  Things were moving faster than I had expected so, character­istically, I replied that I hadn’t thought about it and that I would get back to them with a program, a weak answer I’m afraid.  I returned to Pittsburgh elated and thinking about just how to approach this project.

Some few weeks later, after another meeting or two, they accepted my proposal in principle.

I thought the best thing to do at this point would be to go around to a few of the bigger industrial plants and simply interview their maintenance people.  I would show them the basic idea and ask them what features they would like if they could have anything they wanted, a very open ended question.  People generally like this sort of thing because it seldom happens that anyone in their position is even consulted on matters like this.  I was representing myself as affiliated with Primavera which provided me entrée I would not otherwise have had.  Primavera was to pick up the cost of this gadding about, but I would do it on my own time and then finalize my proposal to them.

As I recall, I visited people at Kodak, in Rochester New York, who have a huge plant right in the middle of the city; I also went to a large refinery somewhere near Houston, Texas and to one or two other places that I cannot now recall the names of.  At the end of this sojourning I wrote Primavera a proposal.  I left the money part of the proposal undefined.

I was new to this game; I didn’t know quite what it was worth, or what they were willing to pay, but I knew I didn’t want to do it for nothing and I also wanted a share of whatever money they made selling the software that would result from this design I would make, a royalty so to speak.  They, sensing my hesitancy, proposed to pay me about $10,000 a month with a 10% royalty on gross sales.  This was more than I had ever thought to ask for, which shows that reticence is not always a bad thing.  But I see now that this being flustered at the last moment has been a continuing theme of my career.  Probably not a good thing.

They insisted on having their own attorneys draw up the final agreement, which suited me fine.  I made only one correction to the document that they express-mailed me a short while later: I had a paragraph inserted that said that if they stopped actively marketing the product our positions would be reversed; I would undertake the developing and they would be in the 10% royalty position.  Be careful what you wish for.  But they had no objection and we had an agreement.  I had a solo celebratory drink at the bar in my Philadelphia hotel thinking to myself how much fun this would be.

I had once played the role of structural designer, an engineering position in which condensed specifications are developed, in the form of what are, in structural engineering, termed “design notes”.  They were then handed to a draftsman who worked out the nitty gritty dimensions and details of the design and committed them to paper in a very precise, detailed fashion.  I saw a strong parallel in software development which then had no such standardized system that neatly segregated the two roles: system design, and programming.

I thought to do something similar for this project, where I would, in Pittsburgh, describe in words the function of the system and provide rough sketches of the user interface.  Then Primavera’s programmers, in Philadelphia, would convert that into detailed code that would actually work on a computer.  But I found that software is a different sort of animal; unlike traditional engineering, software was too new and there was no established methodology for doing this sort of thing—and there still isn’t a dominant methodology.

Only recently had colleges and universities begun to offer formal training in information technology or computer “engineering”.  Previously, software design and development had been well,…  informal, the province of hackers and a few scientists and experimenters and “geeks”; it had not been considered fit for serious study as a discipline itself, much less a field for any sort of degree.  Academics then conceived of programming as an arcane trade, not too far removed from carpentry.  That was changing now.

Unbeknownst to me, software “engineering”—as opposed to just programming—was gradually becoming recognized as a necessary element of software development.  And Primavera’s people knew this, even if I didn’t.  So my proposal to feed them “specifications”, a recognizably “engineering” sort of undertaking, struck the technical people at Primavera as cool, something that they would like their dozens of programmers to get to know how to do.  They were anxious to see what I would come up with.  So was I.

One of the things they had insisted upon in their contract with me was that I would have to come to Philadelphia weekly to give them a report on how things were going.  This did not thrill me even though airplane travel in those days was much less stressful than it is today.  But it was understandable and I didn’t see how I could get out of it.  Beyond that, they considered me almost as an employee or, more precisely, as a paid consultant.  And, since I seemed to have some new ideas about software development, they put me on their developers’ steering committee which aimed to improve their own software development methodology.

Among their development management team two schools of thought contended; the younger fellows were into software engineering, while the older guys thought it was a waste of time, if it could be usefully done at all.  As a systems analyst, one becomes used to this sort of dichotomy—adapters and resisters—so it did not completely unnerve me.  But I had little standing on this committee at the time and for many at these meetings, I was probably viewed as a thorn in their side.

At about this time Joel Koppelman and Dick Faris decided to make a change.  Primavera had invested a lot of money writing a completely new, and considerably more ambitious, version of P3 that was to run under IBM’s programming language for microcomputers, called OS/2.  When IBM first went into the microcomputer business they had hired Microsoft to develop their operating system.  It was then a text-based operating system called DOS, very similar to CP/M.  But graphical operating systems, initially developed by Xerox, and later popularized by Apple Computers had slowly come to dominate the microcomputer realm.  So IBM had developed this competitive product.  Primavera assumed that IBM would win out.  Yet suddenly—in a business time-sense—Microsoft Windows had overtaken OS/2 and it had become the dominant operating system for microcomputers.  Primavera had to scrap a great deal of code and start over.  But graphics were now here to stay, which was good for my project.

On top of all that, they had purchased—and this long before having accepted my proposal—another program from another one of their outside dealers.  Primavera was making a great deal of money at the time and they wanted to grow.  They were rewriting up this software for the Windows operating system.  Together, all of these software development activities was more than their programming staff could manage and they could not see their way clear to take on yet another project—mine.  Yet, since they were making money hand over fist, and were very aggressive guys, they still wanted to do my project too.  But no matter how much money you have there are only so many good programmers available.

Pittsburgh has two schools that are now well known for Software Engineering: Carnegie Mellon university (CMU) and the University of Pittsburgh (Pitt).  So they said to me, “Bill, you hire your own development team.  We’ll put them on our payroll, but they’ll work in your office in Pittsburgh, and you direct them.”  Well, I didn’t like it, and I did like it: I had fancied myself a designer, sort of the architect I had always wanted to be.  On the other hand, their proposal for me to do the entire development would also rectify some of the problems induced by working at arm’s length with their programming staff in Philadelphia.  Once again though, it didn’t seem to me that I had much choice; I wanted to do this project, and this seemed the only way they would go ahead with it. 

My self-invented methods for what has now become known as Systems Engineering had given Primavera some new food for thought.  But in truth the notions I put forward did not seem to transfer from structural design into software development as smoothly as I had expected.  In ordinary engineering, similar methods had been used for decades, but software development is somehow different and more difficult, though it is not clear to me yet just why that should be. 

This problem has given rise to any number of methodologies with which to describe a software design for others to code.  These include: data flow diagrams, case diagrams, N2 charts, pseudo-code and hosts if of others.  None of these have ever dominated the discipline, perhaps because software in one domain can be radically different than software in another.  It remains an open issue in the discipline of software design.

I began hiring people.  A lead programmer from Pitt, another man/boy from CMU, and somehow another, a guy from California, Chinese, who was supposed to be an expert in database design.  Besides these I hired a tester and documentation writers.  I bought computer hardware and we rented another building for the overflow of people.  It was close enough to us that we were able to run a direct line to it behind the neighboring bar, the Onyx, a black-bar at which I was well acquainted.  That way we could have everyone connected together on a new server that we had bought.  Of course Primavera was paying for all of this.  In fact they thought it was pretty cheap, considering what they were paying in Philadelphia.

I resuscitated some of the management techniques I had used in a somewhat different form at Dravo: once a day the whole team met for 10 minutes (it rarely lasted more than 20) in our conference room around the big round table where we had a very large white-board mounted on the wall there on which we could draw diagrams illustrating problems or questions to be resolved.  Each person, round-robin, was supposed to say in only a few minutes what had been accomplished the previous day and what problems or concerns or questions had arisen.

All this had several beneficial aspects: it implied, subtly, that progress was to be made every day; and if there were problems, and there often were, the other staff might have ideas for solutions; it also keyed the document writers and the testers into the stage to which the programming had come, and thus kept them integrated with the rest of the team, which I have found does not often occur spontaneously.

We began to mesh, and I found that, with some holes, we had a very good team, small but very effective.  Gradually software began to emerge, really neat software, stuff that to my knowledge had never been done before.  Graphical software was rather knew then, and visual software to which unlimited tabular data could be easily attached was new (and is still unique as far as I know).  Primavera was impressed and I was having more fun than I had ever had in my life before.  At home, at night, before I could sleep, I kept turning new ideas around in my head.  The next day I would explain them to Ernest, the lead programmer, and in a day or two they would be a reality.  It was marvelous.

The software began to be able to be demonstrated, though at this stage there are always bugs, and the software was tender and would easily crash.  Typically, each week when I went to Primavera, I took a new “build” (preliminary version) of the software with me and demonstrated it to them.  They were not unnerved by the crashes, since they were in the software development business as well.  New versions of P3 crashed regularly too, often in front of potential customers, and Joel, who would have been demonstrating it, was a wizard at recovering from such an embarrassing situation with aplomb.  These problems are endemic to the software development business.

There is something about software that is like boys building a tree house; each new addition to the structure seems a cause for celebration of the now visible elemental structure.  This is completely different than ordinary engineering where it is unusual to see any physical thing until long after the design is completely finished.  And that may be one reason why the two disciplines seem fundamentally different.

Joel Koppelman liked to show-off the new software we were developing.  He once took me To Drexel University, his alma mater, the to show our stuff to one of his former professors.  There were, I think, two motives for this: the first was simply the “little boy” syndrome; see what I’m building?  But the second was, I supposed, to get his former professor’s “read” on whether or not this software was worthwhile from a business standpoint.  It must have passed the test.

Another time I met him at Stanford University near Palo Alto where a large convocation of professors and people in the engineering and construction industry had gathered to arrange some conference that Stanford was about to sponsor.  He had somehow convinced them to listen to him as he showed them our new software.

This meeting was at first convened around the largest conference table I had ever seen.  But soon it moved—after a typically Californian lunch of chicken with avocado wrapped in a flour tortilla, common as sin now, but exotic to me then.  Then we moved to a grand auditorium with every audiovisual appurtenance then known to technological man.  Joel insisted on giving the presentation himself though he didn’t know the software very well.  He stumbled through it and, in spite of his being a novice with this new software, they were impressed too.  I had passed another test.

 

N

evertheless there was a serious, yet hidden, problem with the software, and one that would eventually prove fatal.  And it was this: as I designed more and more of this unique software, and became increasingly fascinated with what it would be possible to do with it, Plant Maintenance itself, the raison d’être of the whole enterprise initially, faded gradually from my mind.  I saw grander things that could be done and, though I wasn’t exactly sure what they were yet, I knew that they were very cool.  In a manner of speaking I had a free ticket to doing very fun things; it was like smoking opium.

After a couple of years of this high, other problems surfaced as well; these not on my account.  Primavera had been spending more and more money on more and more things and, sales-wise, had begun to saturate the market with their primary product, P3.  Sales, while remaining good, we’re not as good as before, when they were rising like a skyrocket, as though Primavera was printing money.  And there was more: at Primavera itself I had gradually come to be seen as “Joel’s boy”, Joel being the president.  Yet Dick Faris was nominally the head of design, and while Joel made a distinct effort to include him in decision-making concerning the new product I was developing, there could not help but be a certain tension between them on this account.

One day I was called and asked to come to Primavera in Philadelphia the very next day.  While I had no direct knowledge of what was going on I had an inkling.  And I was right.  I was told that the project would be canceled, immediately.  Both Joel and Dick would come to Pittsburgh the next day to explain the situation to “their” employees all of whom, by now, had become my friends.  But in the entrepreneurial business one has to expect this sort of thing.  So while I was disappointed I was not devastated.

I returned to Pittsburgh and explained the situation to my team.  The next day the two emissaries from Philadelphia came to our office and did what they felt they ought to do.  I thought it was a pretty stand-up performance; they would not have had to do it.  They could easily have Just let me do the dirty work.  I retain my respect for them still.  And that was that.  Or was it…

I remained fascinated with the project, and though I knew the odds against being successful in such an enterprise, Tricia and I decided to pursue the effort ourselves, which is to say on our own money.  She indulged me is the long and short of it, by making money while I spent it.

After several weeks, and after the team had already been dispersed, I tried to reconstitute it in a very nuts and bolts sort of way, which is to say to try to retrieve only the essentials.  Ernest, our lead programmer, had gone to work for large financial company, and hated it; he had been having fun on our project too.  We offered him a signing bonus of $5000 to come back.  If he took it he was to be committed to the project for two years, as I recall.

I wasn’t then quite sure just how signing bonuses worked, so I went to an attorney to have an agreement drawn up and to ask some questions.  I asked “What if he takes the money and then just quits after a few weeks?”  The attorney, probably surprised at my naiveté, said that there’s not much you can do about it; we abolished slavery some time back, he told me; you can’t keep people working for you that don’t want to.  You could ask for the bonus back, he said, but…

So we got Ernest back (he remained nearly as addicted to the project as was I), and then we rehired Chris, the second programmer, who in the interim, and characteristically, had decided to take a vacation on Uncle Sam’s unemployment compensation.  Chris was a very strange guy and it was hard to keep his nose to the grindstone, but he occasionally came up with truly brilliant ideas.  And I think we may have hired another person or two.  I can’t remember anymore.

We now had these people on Simplex’s payroll.  Tricia was now tasked with providing the money for all of this out of the proceeds of our regular business.  Under her direction, and with only nominal input from me, we were grossing well over $1,000,000 a year.  But by this time I was, as a businessman, only too aware of how fast that money can evaporate.

We continued this effort for some years—probably two.  Unfortunately, but necessarily, I was now back in the selling business, and more than ever: I developed literature for our new product; I developed a help system; I demonstrated it to people; we bought materials for a display both and I took VirtualPLANT to large trade shows; and on and on.

Primavera was very helpful in all of this, and not only because they retained a 10% royalty position (the clause I had had inserted in our contract).  I think they simply liked ambitious guys and entrepreneurialism in general, and they freely gave us space at their annual user conference to demonstrate product to their customer base.

The short conclusion to this story is that while we sold a number of systems for $5000 apiece, we did not sell nearly enough to make up for the money we were eating up on developing the project.  Nevertheless, we plugged on, still infatuated.  But then, one day, came The Big One…