How I Did Agile Long Before It Was A Thing

Sometimes when I talk with younger developers they think that all anyone did before Agile was Waterfall. In reality the process of developing software was never just one thing.

My first job in 1981 started with a project that operated basically what you might consider waterfall, though of course that word didn't exist until later (as a poor description of an article written back in the 70's). That was pretty much the last time I ever did anything like that. Most of the work I did at General Dynamics was in one person projects and rarely had any kind of development process.

With my startup in 1985 which I founded to develop and market the Trapeze spreadsheet program, and the subsequent startup that worked on Persuasion 1.0 and then spent 5 years on Deltagraph, we had to figure out how to build all these Mac applications. Trapeze was built by me and 2 friends, we had a team of 4 assist the primary author of Persuasion, and then continued as a team of 4 for Deltagraph until the final version where the publisher added a couple more, ending in 1993.

I can say for sure that back in 1985 none of us were even aware that people studied the process of developing software. Back in those days long before the internet or even common email, you only learned about stuff from magazines, journals or maybe the occasional conference. So for those first two years we operated in a fairly democratic way: as needed we just talked every day about what we needed to do next. We figured out quickly that it made sense to pick an area of the app to specialize in, and agree on a "contracted" API as the means of exporting functionality to the other two. We wrote in C but the compiler didn't even support prototypes at first which made life interesting. There was no product manager and the functionality was a group decision although I did operate somewhat as the leader since it was my original idea.

After we released Trapeze and sold it for a bit less than a year we wind up selling it to a company in Boston which then split and turned into Deltapoint in California. We would continue to build versions of Trapeze for them until 1989 but by then we had a product manager there.

In the meantime we were put together with the author of a drawing program who wanted to turn it into a presentation application, an idea which had just appeared. We worked as a team implementing charts and data for Persuasion. I was the primary interface to the author and made sure the team was organized around his needs. Of course all designs and implementations were done as we figured out what features made sense. Other than the first week I spent with the author where we basically laid out the general feature set, everything was done in a back and forth manner. There were no iterations but we traded source every other day via Fedex. Eventually he made a deal with a publisher and then Aldus had some input into the completion of version 1.0 which shipped (I think) before Powerpoint did.

During these two projects we got a lot of experience in designing and coding on the fly keeping everyone working together but without any official process. I basically acted as the leader and since I generally did the UI I also became the integration point. Again everyone focused on specific parts of the work and negotiated the API.

When work on Deltagraph 1.0 (Charts and Graphics focused on print output) started I had a lot of confidence in the team and how to make this work. Deltagraph was an ambitious project that would eventually rival the application size of other apps like Excel and Illustrator but we had a very small team, 4 programmers and a tester plus the product manager and QA at the publisher. Basically we started each version (ultimately we would build 5 major releases) we started with a simple list of features the product manager thought might be good. Each feature wound up being discussed by us and then partially implemented, at least enough so that the product manager and the other folks at the publisher could try it out. Then we would modify it, drop it or possibly wait until later. At first we didn't even have email and in general it wasn't easy to get versions out quickly. Again the back and forth "iterations" made building features that the public would like was fairly easy.

We often came up with ideas on the fly. One time General Motors said they would buy a lot of copies if we added a Radar (also called Spider) chart so I found some references and we added it in a couple of days since that was a lot of money. In the end they didn't buy it but it turned out the Japanese liked the chart. This is how Deltagraph came to have so many features, people asked and we just added them. Change was an expected thing.

The other important processes we had was we built versions every day and our tester tested the entire application all the time, not just what was new. The QA lead at the publisher did the same though we rarely were able to send more than a couple versions a week. This way the entire application, the UI, the features and functionality were heavily investigated, leading to much better quality once we shipped it.

I doubt at any time I thought I was doing something "agile", it just seemed like a practical process that took advantage of a small talented team and a flexible publisher team. But the important parts of the process, back and forth feature development, continuous deployment and continuous full application testing, turned out to be similar to some of the key features of Agile. Today this might be called Lean, though I recently read of a new idea where programmers self-organize (Programmer Anarchy) that might be more like what we did.

No where in these nine years did we ever do any big upfront design or develop in rigid phases. We also didn't do fixed iterations but operated in a more or less continuous phases. I acted as the lead making me kind of a spider in a web where I kept up with whatever everyone was doing and made sure everyone was in sync. This made keeping the project going successfully easy.

Deltagraph especially dominated its category and became the standard for printing charts and graphics for newspapers, journals and other print targets. Oddly enough it still exists today in barely unchanged form after a series of owners. Trapeze ceased by 1989 (yet I still get emails from former users who remember it fondly) and Persuasion ultimately was killed by Adobe because it couldn't compete with the "free" Powerpoint.

Today I recognize a lot of Agile in what we did back then long before it was a thing. When I first saw the Agile Manifesto it made plenty of sense to me as it was pretty much what I had been doing. The harder you try to make developing software be the less success you often wind up with. Good people need just enough glue to make things work but not so much that everything gets stuck. That much is just as true today as it was 25 years ago.