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.

New release of Magic

I just created a new release of Magic. One of the primary features, is to make its codebase completely modularised, and creating NuGet packages for every single module in the project. This implied creating more than 20 NuGet packages for the record, so it was a substantial job for me. This allows you to use Magic in existing (legacy) code bases, by simply referencing the “magic.library” NuGet package in your project, and including the “files” folder from Magic in your own existing ASP.NET Core Web API. Read more about how to accomplish this here. Although I want to emphasise that I would encourage you to download the entire code base, since it contains the necessary frontend parts to “crudify” your database.

I’ll probably end up creating some more instructional material over the next couple of weeks, but for now I’m heading to the beach 🙂

Anyways, have fun!

Neither for Free, nor for a Fee

So I have been thinking a lot about prohibiting usage of my software by vicious governments, and other organisations being in violation of United Nation’s Universal Human Right declaration – In fact, I have thought about it for a very long time. So here is my current proposal for a software license, that arguably gives me the best of three worlds. First the ability to share my source code with the world. Secondly it prohibits vicious governments to use my work in any ways. Thirdly, it must create the possibility for me as an individual to create a sustainable income, by making me able to charge people using my software commercially in closed source applications. My intentions are to create a Dual License, that prohibits usage of the software unless two criteria are met: 1. The user creates Open Source software. 2. The user does not work for an organisation that is either directly or indirectly working for a government or organisation that are in violation of UN’s declaration of Universal Human Rights. Neither as a direct employer, or as an independent sub contractor.

The first point (forcing the user to create Open Source), is a demand I will wave for a fee, for users wanting to create closed source applications. This allows me to “Dual License” my software under “Quid Pro Quo” terms. However, the second demand will not be waved, resulting in that I will not sell closed source usage rights to individuals or organisations if they are in violation of Human Rights according to UN’s definition, or working for an organisation or government violating Human Rights. The idea is to keep it as simple as possible. I wanted to use an exception to the Affero GPL, but the Affero’s wording is simply too complex. I want something I can explain to a child, while still fulfilling the above intentions of mine. I am not sure if I have succeeded, but you can see my current working draft below.

Before you object; Yes! I do realise that this does not make the software “open source” or “free software” according to the OSI and FSF’s definition. However, I quite frankly don’t give a shit! Sorry, I will not work for your fascist government, neither for free, nor for a fee. OSI and FSF can quarrel about the semantic differences between Open Source and Free Software – As for me, I am creating Freedom Software … 😉

Freedom Software license version 1.0


Permission is hereby granted, free of charge, to any person obtaining a copy of this software and its associated documentation files (the “Software”), to use the software for any purpose, subject to the following conditions:

1. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
2. The entire source code for your own work that builds upon the Software either directly, or indirectly, should be published such that it is easily available for everyone.
3. All copies of the Software should clearly display a hyperlink/URL whenever it is interacted with by a human being, that allows the human to easily obtain the entire source code for your entire application, and use it under the same terms as you were given the right to use the Software.
4. You or your employer are not in any ways participating in activities that violates the United Nations Universal Declaration of Human Rights (https://www.un.org/en/universal-declaration-human-rights/).


The Hippocratic Affero GPL addendum

Some time ago Coraline Ada Ehmke created a Hippocratic MIT style Open Source license, and the Open Source Initiative explicitly commented on it, and said “it is not open source”. For me personally, Open Source and Free Software is not a goal, it is the means. The means to accomplish good things, and our reasons to create Open Source software, is because we (developers) wants to contribute positively to the world. Hence I don’t care what the OSI thinks about the Hippocratic Addendum to Open Source licenses to be honest with you, I intend to use it for my own software regardless of whether or not technicalities makes it an “open source license” or not.

The next release of Magic will therefor be released under two distinctly different licenses; One “quasi open source” license, the Affero GPL license with the “Hippocratic Addendum”. And another commercial/proprietary enabling license. I allow you to use the first license because I want to contribute to the world, and do my part in making it better. I sell the right to use Magic under the seconds type of license, because I need to pay my rent like everybody else. I also do not sell proprietary enabling licenses to governments or organisations who are in violation of international human rights, by for instance having a military presence in a country without a UN resolution underneath backing their presence, etc. Sorry, you can use something else do – But you cannot use Magic. If you don’t know what the Hippocratic Addendum is, you can find it below.

The Software may not be used by individuals, corporations, governments, or other groups for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of individuals or groups in violation of the United Nations Universal Declaration of Human Rights. Read more here – https://www.un.org/en/universal-declaration-human-rights/

You can read the UN’s Universal Declaration of Human Rights here.

Thank you Coraline for a great idea!

Adding more developers to an already late project

This is a variation of the Mythical Man Month, and probably equally unintuitive. However, the research in this area is bulletproof and has been verified thousands of times by independent researchers, and its conclusion is “Adding more developers to an already late project only makes it later.”

The reasons of course includes that you’re forcing your only productive resource to spend precious time teaching the new developers to understand the existing codebase, in addition to that now the project requires overhead, coordination, and collaboration, adding to its overhead – So while you believe that you’ll be able to finish faster, the exact opposite is the result.

If your job is to move 1000 bricks from A to B, and you’re late, adding more manpower to the job obviously results in finishing earlier. Hence, human experience have taught us that adding more manpower to a job, results in finishing the job faster. Therefor, when a manager is faced with the prospect of not finishing the software project in time, his intuition is to add more manpower to the job. However, you’ll only make it later. Understanding this though, and believing in it, requires huge amounts of experience – Experience most software development managers don’t have. In addition it requires courage, courage to say “NO” when your investors and CEO are telling you to add more resources to your team. However, a mature and experienced software development leader will easily be able to explain this fact to his managers, allowing for the project to finish as fast as possible, without adding to the cognitive load of his team, by adding more manpower to an already late project.

There exists many reasons to hire more manpower, but making the project faster, is not one of those

Recruiters, you’re doing it all wrong

I just declined my “dream job” in Norway. A really great company, with an awesome idea, promising me large autonomy, for doing things “my own way”. They were also going to pay me €150.000 annually. My reasons for declining it? I couldn’t afford it. Now for the record, the base salary was €120.000, but knowing myself fairly well, I’d probably bring in at least €150.000 annually after bonuses and overtime was calculated.

Before you start objecting to me being an a$$hole, all greedy and such, please let me inform you about that I currently earn only a fraction of the above salary. Accepting the above job would imply me raising my salary at least 3x compared to my current salary. However, I live in Cyprus, and adjusting for a completely different set of taxes, and an entirely different set of living costs, the €150.000 in salary I’d be given in Norway, would effectively have resulted in that I’d have to significantly decrease my living standards, to the point where it would hurt badly.

Hence, the end result would be that I’d be forced to move from 9 months of summer to 9 months of winter. Dark and cold most of the year, living in a one bedroom apartment,  instead of living in my 4 bedroom dream mansion in Cyprus, on the middle of the square, of the most beautiful village that exists in Cyprus, only 25 minutes outside of Limassol with a car. I’d have to shave my living costs to the point where it would hurt every time I went to a restaurant, since a visit to a restaurant in Norway, easily would cost me some 3-5 times as much as it does in Cyprus. For a third of the above salary, I can easily go to restaurants 3 times a week in Cyprus, after having paid my expenses, without really noticing it even. And yes, my wife doesn’t even have to work – Her job is basically to make my life comfortable, serve me dinner when I come home, and make sure the house and yard is tidy – In addition to feeding our cats 🙂

In case you don’t understand why, let me inform you. I am from Norway, and I’ve lived most of my life in Norway. If I go to a bar in Norway and buy myself a pint of beer, that’s somewhere between 9 and 12 EUROs. In Cyprus it’ll cost me between 2.5 and 3.5 EUROs – The exact same beer!

In Cyprus I have about 20% tax, in Norway I’d end up paying almost 50%. An inexpensive 2 year old second hand Toyota in Norway; Cashing! Easily €30.000. In Cyprus I can buy myself a new Mercedes for the same price!

If I was a recruiter, instead of trying to headhunt people from abroad, to convince them to move TO Norway – I would spend my time trying to get Norwegian software developers to move FROM Norway, to continue working for their Norwegian employer. Why? Because they could easily cut salary costs in half, have the developer register some offshore company, eliminate employment fees (an additional 25% reduction of costs) – And completely get rid of social costs. The employer would basically save some 75% of his costs for employing the same person, and the employee would feel as if his salary had doubled. Since Cyprus is a member of the EU, this is really quite easy in fact, and perfectly legal too may I add – And according to my own accountancy, an invoice from Cyprus to Norway doesn’t need to even add VAT, since you only pay VAT inside of EU from Cyprus, and Norway is not (full) member of EU, but only member of ECU.

If you’re a headhunter, wanting to hire me for a Norwegian company, to move to Norway – I’ll need at least €300.000 annually to justify it economically to myself. If you want to hire me remotely for a 4th of that price, I’d love to talk with you though. In case you don’t understand why, let me explain it to you, by giving you an estimate of what I’d have to pay for simply living in Norway, with a decent living standard.

  • 3-600 EUROs per month in toll roads
  • 50% tax
  • 25% vat
  • 500% “special tax” on everything considered “luxury items” (cars, liquor, tobacco, etc)
  • €4.000 – €5.000 in rent per month to maintain something resembling my current €750 “mansion” in Cyprus
  • €300 per month for a bus card
  • “Everything” being 3-5 times as expensive
  • Etc, etc, etc …

Sorry, but I simply cannot justify it financially moving to Norway without making at least somewhere above €300.000 annually … 😦

In case you still don’t get it, let me explain to you what me and my wife has planned today. I’ll pick her up after work, and we’ll go to a nice restaurant in Pissouri Bay. Afterwards we’ll probably bring a bottle of wine with us down to the beach, where we’ll probably end up swimming in the dark. The wine will cost me €3, the dinner roughly €25 for the both of us, and the water will be roughly 25 degrees Celcius. If I was to do the same thing in Norway, a bottle of wine would cost me some €15, the dinner would cost us some €80, and the temperature of the Sea would be roughly 15 degrees Celsius – Below you can see a photo of where we’re going to go swimming, only some 5 kilometres away from where we live – Sorry Norway, you loose … 😉

Deciding it for yourself

If you can’t let the developer decide, who should make the technical decisions in your organisation then? Unless you’re technically skilled, and you happen to know a lot of software development theory yourself, deciding which components to use yourself, is arguably the equivalent of playing Russian roulette with your organisation. Facts are, some 3rd party vendor could probably have waved a beautiful website in front of your face, and you’d happily buy something having zero value, believing in the company’s spiehl about their product’s superiority. Obviously this doesn’t work either.

What you should do, is to align yourself with somebody having the knowledge required, but no incentives in regards to increasing your technical debt. Somebody who have incentives that are aligned with yours – Then you should “outsource” technical decisions to this individual or organisation. This might be a person you employ, for instance a “super duper senior” developer, that has already reached the point, where he have few things left to prove. Or it might be an external consultancy company, that is neutrally assessing components, without any ties to the vendors creating the components they are assessing.

Doing a StackOverflow search, only results in finding whatever tool happens to be most popular at the time you are doing your search, and speaks zero about quality – Since components happen to suffer by “networking effects” – Which implies that adoption speaks nothing about quality, since developers tends to gravitate towards whatever is the most popular component, realizing this will give them a larger chance in the job market to find a better paid and more interesting job later down the road.

You can still have the most intelligent individual making your (technical) decisions, just make sure his or her incentives are aligned towards your first, to avoid experiencing the Cobra effect!

That way the dog wag its tail again, and the inmates are no longer running the asylum

Leaving it for the developer to decide

Most junior and senior developers have one simple incentive; Investing in their own future. The way they tend to do this, is by acquiring more knowledge about potential things they imagine future employers will be interested in. This way the developer makes himself more valuable to any potential future organisation and employer, until he reaches the point that he has made himself indispensable. This creates a problem, which is that the developer’s incentives is in direct competition with his employers incentives. In fact, the incentives are arguably aligned in completely opposite directions.

At the same time, the employer is 100% dependent upon the developer’s opinion and advice, because he is the only one adequately equipped with the knowledge required to make choices of technical nature. This results in a “wag the dog” situation, where the most capable individual to be making a decision, is also the least likely individual to be making the correct decision.

For instance, if you ask an average developer how he feels about some component that solves some specific task, he might find the challenge of creating a similar component more intellectually challenging than simply reusing something existing. This might result in that the developer will be looking for flaws in the component his employer asks him to evaluate, in an effort to discredit the component, trying to convince his employer that he would be much better off letting the developer implement a similar component for himself. This would be in alignment with the developer’s incentives, which is to make himself more valuable.

The expression “wag the dog” implies that the tail wags the dog, instead of having the dog wag its tail. Similar expressions have been made that are of more explicit character, such as “the inmates are running the asylum”. Regardless of how you look at it, if you let the developer alone to mind his own business, he’ll probably do what’s in his own best interest, which is to accumulate more technical debt on behalf of his employer, happily coding away, one line of code at the time – Until the cognitive overload of the organisation as a whole, is so large the organisation can no longer sustain itself.

But why should the developer care? He already have 20 new job offers at LinkedIn, which he now is far more likely to be able to fill, due to that he’s learned all those new and shiny things, while breaking the back of his current employer.

Congratulations, you’ve now entered the “wag the dog” world, happily allowing your “inmates to run your asylum” – You’re no longer in charge of your own organisation, because you allowed your “most competent individual” to make your decisions

This will probably come as a surprise to you, but allowing your most intelligent resource to make the most important and hardest technical decisions, will only result in more intelligent objections against using the most intelligent solutions.

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.