Developers who historically would have used one programming language and one set of tools now look to multiple development languages, tools and techniques. The age of developer populism is upon us, where developers are like other craftsman bringing their own tools into the workplace. Developer populism is changing ALM, Dave West, Software Development Times, August 2012.

How Did You Do That So Fast?

“How did you do that so fast?” That was the question from our systems programmer and acknowledged most talented programmer in the organization. All I had done was written a simple utility to compare files (source code, logs, test output, etc.) in a time when file compare programs and their ilk were not well known and people just wrote their own when they were needed.

The environment we worked in was a batch computer system. That means when we had our programs ready to run, they got submitted to the system and some hours later or even tomorrow morning we would see the results of our program’s execution (or a compile of a new or modified computer program). So his question was not so much centered on the complexity of the program I wrote but on how I got it working so fast, when we had such horribly slow turn around time for doing compiles and executing the resulting program.

This was a classified military environment where the standard programming languages were assembler, COBOL and FORTRAN. I say standard because they were what we were allowed to use to develop and maintain the military system we worked on. However, they were not the only languages that were available. We also had this fairly new language, at that time, called PL/I. It was specifically prohibited to use this language in the operational system. However again, there was no prohibition against using PL/I to develop utilities and any one-time programs that a developer personally used to do their job. Well, at least I’m pretty sure there was no prohibition. I didn’t ask.

But using PL/I to write my utility didn’t explain the speed in which I developed, tested and implemented my program which then solved a bunch of problems we had been having for years. PL/I still had to be coded and submitted incrementally to the this very slow batch system. The development of a utility like this should have taken weeks and probably months in this environment. It was one of the reasons few people wrote these kind of utilities (or could get approval to go off and do something like this — again, I didn’t ask, I just did it). It simply took too much time for the benefit. We could manually compare, however error prone, what we needed in a few hours or a few days when necessary — such as for verifying complex test results — it was a task often given to the new programmers. No, it had only taken me about a week to get my program up and running and to be put to use to phenomenally speed up other things we were doing, and to let the new folks program rather than pour over listing to compare and find issues!

I Cheated – By Innovating

What did I do differently? I cheated. We had just purchased a few of these newfangled “toy” computers called “Apples.” Senior management had great misgivings about wasting money on these, but they surrendered to the notion that we might be able to analyze statistical data faster if we had these expensive calculators than if we continued to do it by hand calculators. What they didn’t understand, was these were real computers. I used these “toy” computers to develop my utility.

We had gotten UCSD Pascal on these computers which was another programming language along with a far superior and advanced interactive programming environment. Compiles and test execution took seconds or minutes instead of hours (or overnight!). I wrote the moderately complex compare program in Pascal and got it working in a few days, keeping a low profile and not spending too much time on the “Apples” which was considered borderline “playing” by management. I then spent an evening (no management about), translating the Pascal program into PL/I which was fairly easy as the languages were similar enough that I could translate as fast as I could type. After a few days of very slow turn around compiles of PL/I, I had a working program.

The system programmer knew I had been working on the program and he had not done one himself, because it was just not worth the time. We had gotten use to all the manual work, had that down to its own science and trusted the results. When my simple compare program got it done faster and highlighted the errors in the manual compare, it was all over. We had a new process and years of “this is how we do it” just vanished.

Developer Populism Is Not New

Developer “populism” and craftsmanship has been at work for a long time now. I now have enough experience that I’ve seen the trends and how they vary over the years. I always find it humorous but comforting that we humans follow consistent patterns even as we dress them up or apply them to new technologies and the like. We also consistently tout new innovations and breakthroughs in how we work, but as we look back through history, there is little truly unique except for the details. I attribute this to the fact that we are humans doing this stuff, and we’ve not changed significantly in centuries.

History Shows Us How To Innovate

This is no way lessens the innovation’s significance or impact in the workplace. But when it comes to managing and leveraging these trends, an awareness of historical technology and management movements will help us as a project managers to manage these changes successfully and not repeat the mistakes of the past. We can learn these lessons by studying our history and by, eventually, being part of that history. History is a great project management tool.

Can that new exciting innovation your project is implementing be helped by studying how similar innovations were successfully achieved in the past?