How a Single Whitepaper Killed a Programming Language
The worry hit me hard and didn’t let up as I read more.
That’s not the feeling you want as you read an industry whitepaper making the rounds, one about the programming language you use every day to make the money that pays your mortgage.
It was the late 1990s and the language was PowerBuilder. (Yes, not exactly a language, but you get my meaning.) The big competing product was Visual Basic. PowerBuilder was doing well despite running counter to behemoth Microsoft, mainly due to the innate power and flexibility of the DataWindow object.
“What’s the best tool for building client-server apps?” another freelancer asked me at some gathering. He was surprised I said PowerBuilder and insisted it was Visual Basic.
“Nope, I make a lot of money using PowerBuilder and haven’t made a dime on Visual Basic. To me, that’s the best.”
The whitepaper was written, as I recall, by a PowerSoft employee. It was speculative piece about using PowerBuilder in an enterprise setting, almost certainly with an eye toward competing with Microsoft for the biggest dollar customers. It proposed introducing an “enterprise layer” into their recommended layered approach to building apps that was working so well.
PowerBuilder got a lot better around version 4 when PowerSoft published their PowerBuilder Foundation Classes (PFCs). The idea was that they provided a library of classes, not dissimilar from the .NET Framework. Then they included an extension layer (PFE) that was a shell of classes that simply inherited from the PFC layer while adding no functionality.
A team would build apps using the PFE objects and if they needed reusable improvements, they could put that code in the PFE layer. So PFCs were designed as a global standard and teams would have customized PFE layers tuned to their needs.
The whitepaper suggested that a sufficiently large development organization in an enterprise setting could insert one additional layer between the PFC and PFE layers to provide common functionality to smaller teams, who still might have their own PFE layers.
It sounds so clever. It is actually so terrible.
Developer teams don’t (and didn’t) work like that. The amount of coordination required to have some kind of “core team” controlling and distributing one more layer in the model that was keeping PowerBuilder a significant player in the market wasn’t going to happen.
My worry was that coming from a PowerSoft employee and looking like such a cool, shiny new object, teams were going to rush off down this path without the ability to follow through properly. It was going to add overhead to development, which translates into more time and meetings and less coding. That means shipping later and at greater expense, for vague, hand-wavy benefits.
As it turns out, I was correct. I got to experience first hand. I got onto a team as lead developer at IBM. We owned one application that was part of a much broader Department of Defense initiative. Probably 90% of the entire project was owned by EDS, Ross Perot’s company.
Someone at EDS had read this whitepaper and loved it. So EDS injected an enterprise layer and pushed it top down to all teams working on this DoD project. That meant hundreds of developers working on many separate apps, mandated to use an enterprise layer where touching that code, no matter how broken, was verboten.
It was indeed broken. Whoever it was that was working on that was effectively inaccessible. Building a PowerBuilder app went from something pleasurable and efficient to a constant exercise in frustration and repeatedly missed deadlines. Desperate to deliver something that worked at all, our team added code to our PFE layer to completely bypass everything added in the mandated enterprise layer so we could work using the tool and language as intended.
For a brief time, our team was the shining star of all the teams. It turns out a new client I got in 2018 is a retired Lieutenant Colonel and he had been part of that DoD initiative. He specifically recalled how there had been a point where one of the apps was really coming along great for some months, creating hope the project would be successful.
Unfortunately, government projects are plagued by politics. I was a sub of a sub at IBM, and the intermediary company started playing games with paying my invoices, sometimes two months after I submitted them. Words were exchanged, things got heated, and I moved on. My successor promptly ripped out everything I did and decided to go an entirely different direction. My client tells me the app dropped back into the same lethargic progress as all the others.
This experience was not a solitary one. EDS had its fingers in everything and their development people tried to do this in many, many projects. They weren’t alone, plenty of other companies were trying it.
The results were inevitable: the cost in time and money to build apps in PowerBuilder, on average, increased noticeably. PowerBuilder lost market share as Visual Basic, unhampered by similar problems, grew. PowerSoft reacted by trying to shift to the Java market and turn PowerBuilder into a web application tool. It still exists and with the 2019 version is trying to do a reboot, but its heyday is long gone.
I took the hint and shifted to web development, with Cold Fusion at the time, itself now supplanted by more generations of new languages and tools.
Today, I’m doing a lot of work with AWS services and React for front-end. Our industry is prone to damaging itself with the desire to jump on the latest shiny new thing. Many developers, particularly those that have never done any project management, have no deep understanding about how badly too much pursuit of the new can impact the bottom line.
We need to embrace a lot of change. I’ve had to go make dramatic changes in my skillset at least six or seven times since I started as a professional programmer in 1992. I expect a few more before I give it up and learn fishing or something.
Let’s be careful how we adopt change. We should choose the change rather than be forced into it because we lose our jobs and have to.
