Quite some time ago, around 1998 to be precise, I was learning about the wonders of C programming and the joys of what could be done with void * pointers if you were careful and if you knew what you were doing. You could (with a lot of testing and double checking and scratching your head) write highly optimized execution libraries with an entirely dynamic call structure (void * pointers to functions which accepted void * input and returned void * output). A little more thought and you could use a data driven pipeline to automate the invocation and through data (rather than code) control the execution sequence of tasks.
This very idea opened my eyes to the possibility that maybe one day, we could build software that could build itself. It was an idea that sat running around the back of my mind for a while but sadly it was more of a solution looking for a problem than anything actually useful.
Fast forward a few years, and I was working at a small software company with a brilliant team of people, and we had heard about .NET (just about to come out of beta) and we decided to give it a try. Now languages are languages and although I remain a fan of C# to this day, that was not what was exciting. Neither was it the idea of a virtual machine (after all we had had Java for a while and I had already had my fill of that with the first alpha Oracle drivers, and beta versions of the Swing library). No, there was a fascinating piece that came with this. It was a (perhaps unintended) use of the maligned and subsequently abandoned .NET remoting that allowed a rather neat thing called Aspect Oriented Programming.
About AOP
Aspect Oriented Programming supports a pretty powerful way of programming, where you separate the “infrastructure” of the code from the code itself; and thus we wrote some delightful code which would intercept calls to our business logic, and centrally handle all the nitty gritty items which are tedious but important. Bits like parameter validation, parameter completion, datasource connections, error handling, logging and the like. It was not too difficult to remember back to my C built data driven pipeline, and think that this too could be data driven. We also could use the metadata around this to automatically build the UI and so that aside from the initial investment most future code written would be implementing new logic – i.e. new features. Therefore fostering the belief that Software Teams who can spend most of their time creating direct end user value are Loved Teams.
However, that niggling thought at the back of my mind started to resurface. This whole writing code thing was problematic, since even the best coders introduce bugs every few dozen lines, and while using another human by your side to cross check the compiler can help (you know you are good when you spot syntax errors before the background compiler has the time to put the red wavy lines under it), it is fundamentally slow, complex and subject to interpretation. In order to write good code, a programmer needs to be able to translate from what the human wants to what the computer needs. And yet, oddly enough, we suck at translating. I mean that in the nicest way but programmers are by and large dreadful at this. And of course that is when the human specifying the need is even able to express themselves clearly, which to be honest we humans can not. As my daughter put it, why can not the computer just pluck the half formed incomplete misty idea out of my head, fill in all the details and give it back to me in a way that I want.
A Systemic Problem
So this is not just a small problem, it is a systemic one. Following the old adage of garbage in, garbage out there was no way this was going to work. Or could it?
For well defined grammars we have managed to make code which emits code tailored to a specific purpose. Regular expressions are an example of this that has been around for years. So surely if we were able to describe what we needed in a well-defined grammar we would be able to translate that into automatically generated code.
Time rolled on and slowly small pieces of this began to emerge. ORM toolkits nibbled away at the interface between the well structured database and the code needed to connect to it. Workflow toolkits ate away at the code needed to control execution flow. We saw some different architectural patterns weigh in like Service-Oriented Architectures and Microservices to eat away at the orchestration code.
And the result? Well in 2016 the answer was – More or less about where I was in 2001 with our custom AOP implementation.
Fast Forward To AI
So that brings us to the last couple of years. Lots of things have happened in the last couple of years. More programming languages were created, more frameworks and libraries were created; in fact we have an awful lot more. So much more that it can be difficult to tell what, if any, of the more is really helpful. One area which has stoked the fires of the IT hype cycles is that of AI. AI for many years was the much ridiculed poster child of a failed utopia. AI that is now, once again, full of such promises from self-driving cars to self-programming computers. This time however the pundits have carefully framed the conversation – this is not intelligence but machine learning. Strictly speaking its not even learning either, there is no understanding imparted by the processing of the data, but rather the establishment of selectors on a set of data. At first glance, underwhelming, but in such simplicity lies power.
If we had a huge source of programming code freely available (thanks Github, GitLab, BitBucket and all the others) and could rate that code in some way (issue lists, bug fixes, code updates, followers, etc.) then we could theoretically teach a program to recognize what “good” code looked like. So, we can well imagine a near future with ever increasingly sophisticated code grammar and code smell analysis. I can also see these kinds of repositories feeding code translation from one language to another (including framework/library references) and arriving at better more contextual code completion in editors. Not just for developers; we already start to see this in the design world with the Adobe Sensei features which have been integrated into their product lines where they use, for example, AI powered content understanding to power smart transforms.
What About Programming?
Well that is nice but were not we talking about automated code writing?
As Dr Lanning said in I, Robot – “My responses are limited. You must ask the right question”
Automated code generation when users are able to clearly define what they want, such as in a constrained WYSIWYG tool, already exists. We have had this in web development for several years, and more recently also for chatbots and even for form-based data driven applications. Now also consider cloud platforms like Azure, and Google (as well as several smaller providers) are offering extensive APIs which provide the possibility to write less code to achieve what you need. Even Office 365 is getting in on the act with Flow, PowerApps, Forms and other out of the box services which can reduce or even eliminate the need to write any code at all. So, do we really need to write software?
Once again – “My responses are limited. You must ask the right question”
We write software to do something, to solve a need or a problem. Even a moment’s thought will tell us that no prebuilt library, framework or service will ever provide a solution to every need. So back to the core. The real problem is how do you get from that “half formed completely misty idea” that is in someone’s head to a formal language specification that we can turn into code? The answer is talking to them.
“Everything that follows is a result of what you see here”
It is only a matter of time before someone writes a chatbot which can tease out from a human what it is that they actually need. It is only a matter of time before the combination of that bot and the extensive cloud hosted services trigger a fundamental shift in the software development industry. What that shift will bring however is not something I would care to speculate upon. There are already startups looking to position themselves on the wave this will generate, if they will be successful is anyone’s guess. And of course we cannot ignore the influence of the estimated 2% of the worldwide population who know how to code. The world is complex, with so many factors (economic, political, societal) that the establishment of a technology offers no guarantee to how it will be used. It will be up to us to decide on that future and how it should look.
“That, detective, is the right question.”
