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!

Advertisements

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.