Did you know that Wednesday Wisdom is also a podcast! Find it on Apple Podcasts or on Spotify. Did you know that there is also a custom GPT called Midweek Muse that has access to all of Wednesday Wisdom? Did you know that all Wednesday Wisdom videos are also available on YouTube?
Note: This week’s article started as a larger and rambling article touching upon a variety of topics. After numerous starts and stops, followed by some more thinking, it dawned upon me that I was trying to write down a holistic vision on what AI coding tools will do to the software engineering profession. Over the next two to three weeks, I hope to be unfolding that vision in successive articles. This week we start with the ground work: How we always wanted to make software development accessible for non-engineers, but instead made actual software developers more productive.
A friend of mine is trying to make her way as an independent software engineer. She recently came in touch with a potential customer through an intermediary who wanted a bunch of features for automating various processes in the customer’s backoffice. The intermediary thought $5,000 was a good price for the work they proposed because, surely, with AI coding tools, developing all this software would be faster than ever before. Both my friend’s chief advisor (an experienced and retired software engineer) and myself told them that we have seen this happen with shocking regularity since the dawn of time. Therefore, I thought it would be instructive to explain to younger software engineers what happened since the Earth cooled and the dinosaurs came and then went away again in order to provide us with cheap oil.
Ever since computers were invented, everyone but the software engineers has been annoyed by the slow pace and high price of software development. This became such a constant annoyance that it even has its own Wikipedia page, which describes the so-called “software crisis” as “a term used in the early days of computing science for the difficulty of writing useful and efficient computer programs in the required time.” Consequently, everyone (but now including the software engineers) has been looking for ways to make software development faster and cheaper, typically by providing better tools and by inventing ways to require fewer expensive people.
As early as 1959, COBOL was designed as a programming language with a syntax close to English, so that non-programmers could read and maybe even write computer programs. Obviously, this effort failed; not in the sense that COBOL did not become a very popular language for business applications (it did), but because English majors with a business degree still cannot write software.
Interestingly enough, one of the statements I frequently read about AI coding tools is that the programming language of the future will be English. But, I am running ahead of myself.
Since then, we have seen a variety of other “solutions” to the software crisis. In the 1980s, the hip new thing was “fourth generation programming languages”, which were coined as a concept in a book aptly called “Application Development Without Programmers”. The preface of this book contained the following sentence: “The number of programmers available per computer is shrinking so fast that most computers in the future must be put to work at least in part without programmers.”
Well, at least they got that right, because I got a dozen computers in my house and, the lovely Mrs. Wednesday Wisdom’s prowess with SQL and SAS notwithstanding, there is really only one competent programmer around to keep all these computers going.
But let that statement sink in for a bit. Before the advent of the personal computer, there were apparently more programmers than computers and people were worried about who was going to program all these computers once the ratio dropped below 1:1, which started happening in the mid-late 1980s.
I can personally vouch for the “more programmers than computers” phase of our industry. In my first job, I was part of a team of about 25 people who cared for four computers in the company’s datacenters.”
In their day, fourth generation programming languages were such a hype that some people advised me against studying computer science, because they expected that business analysts and other non-engineers would be writing their own software any moment now.
Interestingly enough, one of the statements I frequently read about AI coding tools is that non-engineers will soon be writing their own code. Where did I hear that before? But, I am running ahead of myself again.
The 1990s saw the rise of no-code and low-code programming environments. This trend was started by Visual Basic 3.0, which did indeed give us a whole new paradigm for writing GUI applications by dragging and dropping UI widgets to a canvas, connecting them through events, and either configuring objects or sometimes writing small amounts of relatively simple code to respond to these events. Now non-engineers were surely going to develop software because now that didn’t need typing in long and complicated programs anymore!
Time for an anecdote: I once taught a Visual Basic (VB) 3.0 programming course to the IT people of some company in the Netherlands. They weren’t developers per se, but anyway. The students thought it would be a cool idea to forgo the standard exercises of the course and instead work on an application that they had been asked to build for internal use. I thought this was a splendid idea.
The application was for the administration of incoming mail and controlling its distribution to the right recipients. Sometimes, the mail had to be processed by multiple departments and in that case they stuck a little preprinted note on the mailpiece with the names of each department that needed to see it, after which it would start a journey through the office, with each department signing off that they had seen it.
VB 3.0 offered features to connect to databases through ODBC and I taught the students how to use this feature for data persistence. For the traveling mailman problem, the students proposed adding five columns to the “MAIL” table for the names of the departments that needed to see a piece of mail. The columns were aptly called “DEPARTMENT1” to “DEPARTMENT5”. I asked what would happen if a piece of mail should be seen by six departments? They agreed that this would be a problem, but that this happened very infrequently. Always the optimistic teacher, I made a counterproposal: Why not give each piece of mail a unique identifier and then have a separate “DEPARTMENTS” table with the name of the department and that unique identifier? Then at runtime, we could use something called a JOIN to get all the information we needed.
The students were flabbergasted. This was brilliant! Wow! Inspired by this feedback, I took it one step further and proposed that maybe the “DEPARTMENTS” table should only have a unique department identifier and the name of a department, and then a third table would keep track of which departments needed to see which pieces of mail through rows that contained only a mailpiece identifier and a department identifier. By now the students were convinced that their trainer was an absolute genius.
Apart from being a fun anecdote, this story also illustrates a fact that many people either forgot or never realized in the first place: An awful lot of software in the world is already written by people without a relevant computer science degree. I assume that a lot of Wednesday Wisdom readers are professional software engineers who are working in Big Tech or in Big Tech adjacent organizations, but really, there is a huge amount of software development going on by people who have only a limited clue about what they are doing and they need all the help they can get.
No and low code environments stayed with us for a while, but I think it is fair to say that they never lived up to their expectations. I sat through quite a few demos where the speaker would throw a calculator application together using standard widgets and a few lines of code, to which my response invariably was: “But I don’t want to write a calculator app, I have five already.” In response I was sometimes asked what I did want to write, to which I usually answered: “An application for creating and managing invoices for law firms” (something I wrote about here). This relatively simple business application idea always defeated the features of the no/low code environment being demonstrated.
In the meantime, lots of things had happened that made me more productive. The list is long and detailed, but it includes better programming languages, better compilers, free compilers , better editors, better libraries, more libraries, free libraries, and better debugging tools (hello Valgrind!). Most of these improvements can be credited to the open source movement, which from very humble beginnings managed to get a complete and free professional software development suite, from the operating system upwards, in the hands of everyone who wanted to develop some code.
It might be hard to imagine now, but when I started out as a developer, getting started was an expensive and/or difficult proposition, because you had to buy or steal all of your software and probably photocopy the manuals. In my early days, I wrote applications on my PC using a stolen Norton Editor and using a stolen Turbo Pascal and an equally illicitly obtained Turbo C compiler.
Aside: Let’s hope the statute of limitations has run out on these crimes.
When I started getting a bit more affluent, I went legit and would shell out about $2,000 (in today’s money) for a Microsoft Visual C++ compiler.
The open source movement changed all of that and through their combined efforts they allowed many people to become incredibly productive software engineers by providing all the development tools one needed and amazing libraries for pretty much everything one wanted. Again, maybe hard to imagine, but when I started coding professionally, none of this was available, which made developing software cumbersome and slow. For one program I was writing I remember I wanted to process glob-like filename patterns. No library was available, so I had to code that, by hand, in assembler. That is challenging and therefore fun and rewarding, but as you can imagine, it does not do wonders for velocity. Even before AI coding tools became available, I would routinely write something in a day using open source languages and tools, that would have taken me weeks, if not more, a few decades ago.
All this goes to show that since the dawn of time there has been a desperate search for something, anything, that would bring software development into the realm of “normal people”. So far that has failed, but what has happened is that other improvements in the field have made the new and existing software developers more productive.
Enter AI coding tools.
Again, we are seeing outsized claims that software engineering is doomed as a profession and that, really, this time non-engineers will be able to develop their own software. I beg to differ, and here is why: The AI coding agent is helping me with the part of my job that was never a problem to begin with!
Let me say that again for clarity: AI coding agents are doing things that are extremely helpful and that are making me much more productive, but they are not doing anything that I couldn’t do myself.
In the whole process of developing a piece of software, writing the code was always time consuming, but it was never problematic. It just took a long time. Same for debugging, writing documentation, refactoring the code, and all the other things that I have Codex do these days. The AI agent is doing stuff that I already know how to do, but it does it faster and in parallel, which is extremely helpful. It’s a tool with incredible power, because I can now do more things in my day, deliver more working code faster, but it is not doing anything that I wasn’t able to do before, much like all the previous improvements in software engineering.
That doesn’t mean that there are not going to be impactful changes to the profession, but my current bet is that there will stay a profession that understands how computers work and that specializes in solving problems with computers.
One thing is certain though: These professionals will spend considerably less time typing in the code...
Stay tuned for next week’s article which might investigate what a software engineering profession that does not type in code could look like. Then, the week after that I might talk about the economic consequences of it all.
