When the computer creates the code

When your computer becomes your lead developer

Ignoring solar activity and acts of God, you can safely assume that every single security hole and bug you have ever had in your software systems, originated from a human being, doing something wrong, often somewhere deeply hidden within your codebase. Hence, creating perfect code, is literally as easy as eliminating the “human equation”. And in fact, if you think about it, there’s nothing magical about code that doesn’t allow its creation to become automated, the same way code has a tendency towards automating everything else. In fact, not having automated our creation of code a long time ago, is arguably pathetic, and hypocritical, since we are after all in the business of automation …

Once you start thinking in this direction, you realise that if you could create one single tiny piece of code, that perfectly automates the creation of code, you can reuse that snippet of code, creating code, over again, and over again, and over again, to produce perfect code every single time you use it!

Automating the process of automation

So instead of creating code every time confronted with a problem, like we software developers have a tendency towards ending up doing, we should rather ask ourselves how we can create code that creates the code we need in the end. This is the very basics of “problem solving 101”.

Don’t solve your problem! Rather create a solution that can be applied to solving all problems – Including those problems you might have in the future

If you believe this is science fiction, think again. I have just released a new version of Magic, which actually is a software system that creates code. Highly useful code too I would argue, since it solves arguably 80% of 80% of our largest problems as software developers – The creation of HTTP REST backend endpoints, allowing us to do CRUD operations towards our database.

Although it’s still not extremely mature, and only supports MySQL for instance, it’s already easy to imagine how these same ideas could be leveraged much further, to permanently eliminate (more or less) the need for human interaction (in the code), to produce computer systems, of immense complexity, built on hundreds of thousands of automagically created lines of code.

Advertisements

The process of industrialising software creation

As I hinted to in my previous blog, software creation can easily be industrialised. Today creating software is considered too hard, and having to many cognitive challenges to be industrialised – That’s one of the reasons we call it “information society”, because even though it is the ability to handle information, it is also a problem that requires huge amounts of information for a human to be able to adequately solve it. But that’s just a problem like everything else, and problems exists to be solved. And if we can reduce the requirements for information needed to create software, we can simplify and optimise the creation of software. And if we can simplify and optimise the process, we can reduce the costs. Reducing the cost, increases the profits.

In order to industrialise software creation, we first need to standardise its components like I said in my previous blog. However, more importantly, we also need to create reusable components, that are prefabricated smaller pieces of logic, that we can later assemble to a whole, using an assembly line production mindset. When Henry Ford industrialised the creation of cars, his workers would simply pick components from his storage, and simply orchestrate these components together, which of course is why he could optimise the process to such a degree as he accomplished. These components could be for instance the car’s gearbox, its lights, the seats, etc. If you picked any one of these individual components and looked inside of it, it would contain complexity that from an individual point of view, would dwarf the capability necessary to assemble, for most of his individual workers. For instance, changing the lights of your car today, implies taking a prefabricated box, containing possibly 100+ different parts, with 100+ different chemical components. However, the casing that contains the lights, have been preassembled together, such that it can simply serve as a drop in replacement for your old light casing. This allows a technician to treat the lights to your car as a single object, ignoring the facts that there are Wolfram and hundreds of other complex parts inside of it.

Software can just as easily be broken down into such components too. For instance, how many times have you implemented a piece of logic that allows a user to be authenticated and authorised towards your website? Authorisation and authentication requires hundres, if not thousands of different components to work together perfectly.  It requires at least two different cryptographically secure hashing algorithms, such as BlowFish and Sha512. It requires a secret salt, in addition to a per-user based salted storing mechanism of passwords. It requires the ability to do CRUD operations towards a database, etc, etc, etc. If you know everything related to auth, you could easily consider yourself a “computer scientist” – And acquiring knowledge about everything related to auth, would often imply almost a decade of university classes before you could confidently implement a secure auth system.

The above authentication and authorisation example can easily be componentized however, into a reusable authentication and authorisation component, serving all the auth requirements for all of your apps. Facts are, any individual organisation only need one authentication process and one authorisation repository. So why do most apps have their own solutions to these problems? If you created such a component, none of its consumer would need to have even the faintest idea about what neither Sha512, nor BlowFish, or even salts for that matter even are. This auth system simply produces a simple JWT as its output, if the authentication is successful, for then to allow the system having auth requirements to consume this simple token to verify the user is who he or she claims to be. Either the auth “ticket” is valid, at which point the user should be granted access – Or it is invalid, at which point the user should be denied access. We have now “componentized” the auth problem, and can reuse the same auth component, for an eternity, without ever having to even look into its internals for as long as we live. The cognitive requirements of creating a secure software system, has dropped by one order of magnitude.

When we are done with auth, we can move onto the next problems; Email for instance. How many different email components does an organisation need, really? How many times have you written new SmtpClient() in your apps? How many times have you retrieved configuration settings from your configuration file to configure your SMTP server object? Having more than one piece of code doing this within any organisation, is arguably madness – Because it adds to your organisation’s technical debt.

When you are done with auth and email, you can simply proceed forward, until you have created reusable components out of every single individual problem – At which point your task as a “software assembler”, becomes simply to orchestrate components together, that in their combined results creates your end products – Whatever that happens to be. You have eliminated somewhat 90% of your coding and cognitive requirements to “create software”, possibly even 100%, and the task of creating software implies simply orchestrating together prefabricated components, resulting in your end product.

Really, understanding this isn’t rocket science exactly …

Creating software without coding

Henry Ford once famously said “If I had asked my customers what they wanted they would have said a faster horse.” Henry Ford of course reduced the time required to assemble a car from 2 years to some few weeks – And in the process he became ludicrously rich, and according to some arguably the “father of the modern age.” In fact, his goal was to make cars so inexpensive, that all of his factory workers would be able to afford one. He accomplished his goal, and in the process increased the size of the market for cars by several orders of magnitudes. In fact, the only reason why there are more than 5,000 cars in America today, is arguably due to Henry Ford and his ideas of using the assembly line to construct cars.

There is nothing magical about creating software. Software creation can also be subject to the same processes that resulted in making cars faster to produce – And in fact, the process is interestingly very similar to the process that made us able to industrialise the art of creating cars.

One of the things that made Henry Ford so successful, was his ideas about standardisation. Everything was standardised in his factories. He used the same types of bolts everywhere he could use them. This resulted in that his workers could use the same set of tools to assemble the parts that resulted in the final product. It also implied that any worker in his factory could move from one part of the production line to another part, without even having to change tools, or needing to learn a new skillset. There is nothing prohibiting us from taking these same ideas, and applying them to software creation.

By standardising your production of software, you can optimise the process by orders of magnitudes. Then ask yourself what the value of being able to assemble software in weeks instead of months and sometimes years would be to your company’s profit? In fact, I am working on a product that allows for doing such a thing. If you want to have a look at it, you can find it here. Unfortunately, it’s not some magic pill you can simply eat, and optimise your company’s ability to create software 10x – Since it’s also a mindset. It’s a change of habits, and an idea that requires changing the way your company thinks about software. However, I have been thinking about these ideas myself for more than a decade, and I would love to apply them to a company, willing to optimise its process of creating software. If you’d like to talk to me about it, you can use the contact form below.