My First “Agile” Experience in the Early 80s

Of course, it wasn’t actually Agile according to any currently understood practices and techniques. But it did have aspects of some of the ideas now viewed as Agile and was the experience that came to mind when I first read Kent beck’s 1st edition of eXtreme Programming Explained. I’ll describe the working environment, the product (a bit) and how we interacted. You can judge for yourself where the experience fit on any scale of being or not being Agile.

We were doing a commercial 4GL product (non-procedural language and associated database) known as RAMISII. It was written in FORTRAN and IBM 370 assembler so, of course, ran on IBM mainframes. There were 9 of us in the development group. Two focused mainly on the database code (and an access module to IMS DB/DC so the “language” could do reporting from those databases as if they were our own database). Two did “support” and non-development (regression) testing. So five of us worked on the language/reporting side. There were also a couple documentation folks who worked under the Marketing group which had 4-5 other folks in it. Marketing was our internal “customer,” though we never used that term or really thought of them that way formally.

Once year, after relational databases started catching on but before DB2 was big in the IBM environment, it was decided we would redo the reporting/language side of the product to add substantial functionality, including language constructs to allow relational operations for reporting extract purposes. Since we were going to change some 70% of the system, it was also decided we’d get rid of all the FORTRAN and replace it with Assembler. That’ll give you an idea of the technical scope of what the five of us would tackle over the course of 9 months or so. The 9 month target was because it was early summer and the next major customer gathering/conference was the next Spring, so we needed to have a major release ready then as we did each Spring.

[An aside on why assembler and not C, Pascal, even PL/I. We had to stick with languages that IBM was currently supporting on mainframes and an IBM C compiler was many years away at that point. But we could have used PL/I except that, at least back then, there were dynamic libraries associated with it that the customer would already have had to have, i.e., they had to be using PL/I, to then run our delivered system. Or the customer would have to license those libraries separately from IBM. Or we would have had to license them and pay IBM for each copy of our system that we released with them. Company senior management did not want to get involved with any of these concerns. So no PL/I.]

As to our environment, besides just saying it as assembler and IBM mainframes. Our (two) machines were mid-sized mainframes running VM/CMS (a virtual memory system that allowed each of us to feel like we had a machine all to ourselves). We worked on, wait for it, TI Silent 700s, i.e., thermal printer terminals. No CRTs as it was before even 3270s were widely used. (A year or so later, we had to get into supporting 3270 full-screen, but, at that time, it was command-line interfacing.) Each of us had our own private office in a nice building in the suburbs of Princeton, NJ. Of the five of us, 3 were relatively new to the company (<1 year), one was just a bit over a year, and I had been there between 2-3 years. (The database access and support folks were more senior than I.) Everyone, save one very junior person, had several years of experience at that point (i.e., 5+ at least) in IBM or Honeywell mainframe environments with assembler (and other languages).

Our immediate bosses were really fine folks with development experience from an operations research background. There was no obvious hierarchy among us. (Indeed. while I was there, I was "promoted" 3 times and never knew it.  It never affected how I related to or was noticebly viewed by anyone, at least as far as I could see.) We each, and our managers, valued good ideas and enjoyed one another’s ideas as there was always lots of room for people to contribute. The product was thousands of lines of code.  I can’t remember exactly how big but we had some 50-60 uniquely named FORTRAN and assembler modules that ranged from a couple hundred to a thousand lines each. Back then, it was a large footprint product that employed dynamically loaded overlays to limit memory use.

That summer, those of us in development spent a month or so determining every module we felt we’d have to touch based on some very high-level specs from Marketing. These specs came from the last Spring’s meeting where customers would annually “vote” on the features they wanted from a long list compiled from everything they all had been submitting for the 6 months before that. As this was pre-32 bit addressing, we also had some decisions to make about how to restructure our pointer approach for our report record sorting. One of the features desired was the ability to print summary data before all the data actually printed on the page, so we had look-ahead selection and calculation issues to deal with so we could create, carry and sort summary data records within the detailed records.

I have no recollection of how this started, but near the end of the summer, we started having regular meetings with the Marketing and documentation folks to flesh out functionality in more detail. We never had a formal requirements spec, but the user/support manuals became our “spec” as were interactively decided on features, new language syntax, etc. We would not have new functionality to show at each meeting, but we had ideas to present and questions to cover so Marketing and documentation knew, throughout, what we were up to and what it was going to look like. (Being syntax and command-line focused helped a lot since we did not have GUIs and full-screen formatting to worry about.)

After a couple months, though, we did have features to show since we had updated/rewritten enough to have threads of functionality able to work. We could also start testing functionality, at least within development, though we were also sharing what we were doing (as was Marketing and documentation) with the support group so they could work on tests at their level to incorporate into the test suite. (We would give them ours, but they’d always enhance them and then move them into their large test suite where they thought the new tests would work best with existing test cases.)

As we saw how our design ideas were working out, we began to offer to Marketing ideas we had on features, related to ones clients had requested, that we felt could “fall out” of work we were doing with little or no additional effort. If Marketing liked them and management accepted our evidence that it would not impact the Spring client meeting demo date, we’d put them in. An example of this were various summary calculations and totals we saw we could add if Marketing felt they’d be useful to clients. In some cases, we suggested ideas the clients had literally suggested but which were lower on the voting list than ones the Marketing identified as committed to the release. So, as we began to announce what features would be in the release, end customers were really happy to see everything they had voted for making it as well as other things they had not expected we would deliver.

A couple months before the meeting, all the functionality was done as was all the user documentation. Actually, the documentation had been settled upon a month before that. The doc folks were just doing their own formatting and example insertion work. Examples often came from our test examples.  In deed, tests we used often came from ideas Marketing had for typical user request streams. During the last two months, we started working more with performance improvements and internal structural changes. No new functionality was being worked. All defects found during that time were due to internal issues and had no functionality impacts, i.e., no missing or misunderstood requirements.

At the Spring meeting, customers seemed really excited by the work we had done. They loved all the functionality as well as hearing, despite all that was added, that both memory footprint had been reduced and performance had been improved. There was also an explosion of functionality ideas from clients coming out of the meeting. (As the formal release date was early summer each year, we were able to incorporate a number of these successfully before the actual release, so clients did not have to wait a year for them.)

In the process of making all these changes, we introduced no major defects and, in fact, found two serious defects that had been plaguing us on large reports and on customer system configuration changes, i.e., whether they allocated dynamic memory above or below the base load address of the main system modules.

We never had a name for how we operated. It clearly wasn’t “Agile” in many aspects, but I think we hit every Manifesto Value dead on and several of the Principles.