This chapter is from the book
This chapter is from the book
This chapter is from the book
Exxon to Oglethorpe
In 1976, after nearly six years with Exxon, I moved to Atlanta, where, after a couple of short-term jobs, I ended up at Oglethorpe Power Company as software development manager.
During a brief stint in an Atlanta bank, where computer operations staff deposited piles of computer printouts on the president’s desk each day, I worked on their first international banking system. This project included a trip to Citibank in New York City to investigate its state-of-the-art international banking system running on a DEC superminicomputer. Combining what I learned at Citibank with the knowledge I had gleaned in my discussions with our international bankers, I wrote a proposal for moving forward with new international banking systems for processing foreign exchange, letters of credit, and other international banking transactions. I liked working with international staff, as they were laid-back as bankers go.
But others were not so laid back, as I learned when confronted about my adherence to standards and procedures in a conservative bank. It seems my travel and proposal costs had exceeded my budget by more than the 10% limit. I hadn’t even known I had a budget, but I received a dunning letter from a guy in accounting. I would have ignored it were it not for the five to six pages copied from an accounting book and stapled to the letter, which suggested I bone up on my cost accounting. I invited the guy to my office for a chat.
“What is that on my wall?” I asked, pointing to a framed document.
“It looks like a CPA certificate,” he replied.
“Do you have one?” was my second question.
“No.”
“Well, until you do, don’t send me more pages from accounting books!”
Although my proposal on developing an international banking system was well received, by that time my nonconformist side conflicted with a banking career, so I quickly moved on to a less rigid culture.
OGLETHORPE POWER was a newly formed power generation, transmission, and distribution cooperative serving power companies in rural Georgia (in my undergraduate program, I majored in power systems engineering). My software development manager job was like a start-up position, as I got to build my staff and implement methods.
My department manager had worked for Andersen Consulting14 in the past, so we adopted that firm’s Method/1 methodology, which was advanced for the times. While Method/1 was intended as a project management tool for software projects, it didn’t include specific development methods. For example, it contained tasks like “Define a file format” and “Complete a file layout form,” but had no methods for actually defining them.
I had taken a few courses in structured techniques from Yourdon, Inc., and wanted to incorporate them into our company’s development process. In a structured techniques discussion with one of the Andersen consultants, he suggested we look at the Warnier-Orr approach in addition to the Yourdon one. Subsequently, I brought Ken Orr in to teach us about his methodology and methods. While these methods were initially created by Frenchman Jean-Dominique Warnier, Ken Orr added to the original ideas and popularized them in the United States. The diagrams showed constructs such as hierarchy, sequence, repetition, and alternation. The methodology focused on starting with the outputs and working out the flows that produced those outputs. This emphasis on outputs rather than inputs was a concept that stuck with me, eventually extending to the concept of outcomes in the Agile era.
My staff embraced the Warnier-Orr approach, and we delivered several applications using it. We also purchased and used Ken’s software package called Structure(s), a precursor to computer-aided software engineering (CASE) tools. One member of my staff got excited. An experienced programmer, he remarked, “This is the first time I’ve ever written a COBOL program that didn’t have a compiler error the first time through.” This system was our first complete life-cycle use of the Warnier-Orr techniques. It was successful and well designed. However, it sowed a tiny seed of doubt in the back of my mind: “It sure took a longer development time than I expected.”
During 1978, my writing career began with a published article, when “Solving Design Problems More Effectively” appeared in Management Information Systems Quarterly. Interestingly, this paper was not about software development, but rather about a process for group problem solving. During the 1970s and 1980s, I published other articles in MISQ, Auerbach Reports, Datamation (Highsmith, 1981), and Business Software Review (Highsmith, 1987).