The cost of a line of code

As you can see from my previous article about this subject, one developer can produce roughly 563 lines of code per month. In Cyprus a software developer will cost you on average €40,000 per year to hire. If you break the numbers down, this implies that each line of code you have in your organisation had a cost of €6. Basically, one line of code will cost you €6 on average in Cyprus, ignoring the fact that developers do other things than creating code of course.

In Norway, my native country, you can easily double the above cost, resulting in some roughly €12 per line of code. While in London the cost is as much as 15-20 EUROs per line of code. In extremely high cost places, such as the Silicon Valley, each line of code might cost you as much as 30 EUROs.

In my years as a software developers, I have seen a lot of projects. All of them have one characteristic they share, which is that they contains thousands of lines of code. Sometimes even hundreds of thousands and millions of lines of code. No wonder that independent studies have found that the size of the software development market to be somewhere between 322 billion dollars to 864 dollars in size annually – Depending upon how you measure it. Which of course again employs some roughly 26 million software developers world wide.

However, this is a historic anomaly. In the year of 1850 I betcha the market for breeding horses saw similar traits, as in being humongously large in relative size, resulting in that some horse breeders were filthy rich. Then came the trains initially, and later the automobile, and the market for breeding horses fell dramatically. It’s simply a consequence of automation. Today breeding horses is probably only for those with special interests. 170 years ago, it was the backbone of the economy and our society.

Similar changes have been seen over and over again throughout history. For instance, 1,100 years BC, Cyprus, my country of residence, was a super-nation due to its production of copper. Copper when combined with tin was the equivalent of gold some 3,000 years ago, and Cyprus was rich in copper. Then some smart guy invented the process required to create iron, and both tin and copper became meaningless historical artefacts, of no more interest than that of horse breeding today.

50 years from now, we will laugh at the way we created software today, simply because it’s an extremely manual job, and the products we create often fails due to the human factor. According to Gartner only 25% of all software development projects succeeds. 50% of software projects are challenged, in such a regard that they don’t deliver on time, or deliver inferior products according to their specifications – While 25% of them are never even finished, and simply completely discarded a couple of years after having been initiated. Hence, when some smart guy comes along and realise we can automate the creation of software, the world as we know is destined to change, and new methodologies for creating software will be born.

Hint, that guy is already here … 😉

Developer productivity

According to studies in the subject, the average software developer can produce between 325 LOC and 750 LOC per month. LOC implies of course Lines Of Code. If we are to be kind, and round upwards, this becomes 563 LOC per month on average. There are 22 working days per month, hence 563 divided by 22 becomes 25.5 LOC per day on average.

Hence, if you’re about to start a software project, and a qualified estimate of its complexity is 40KLOC, implying 40,000 LOC, this would require a single software developer 40,000 divided by 25 days to complete – Which becomes 1,600 days, divided by 22 equals 72 man months, divided by 12 becomes roughly 6 years.

At my previous company we had a fairly large codebase. The total count was 246KLOC of C#. The codebase was roughly 3 years old, and on average there had been roughly 8 developers working on it – Sometimes more, sometimes less.

If you multiply 8 developers by a productivity of 25 LOC per day, and you multiply this number by 22 working days per month, and you multiply this number by 12 months per year, and then again this number by 3 years – You end up with 158,400 LOC. The last number is the number of LOC these 8 developers should have been able to deliver in 3 years. Hence, 246,000 LOC is considered to be within the range of what they should have been able to produce, accommodating for standard variations.

Lines of Code might be a terrible way to measure productivity. Bill Gates once said that measuring developer productivity according to LOC, is the equivalent of measuring an airplane’s quality according to weight – But unfortunately, it’s our only way to measure these things, and it’s also highly accurate once you break down the numbers, and apply them in your own organisation. Of course, the really brilliant developers removes 25 LOC per day, and still keeps the existing functionality – But that’s another discussion.

Do me a favour and look at your current codebase, and count its LOC. Then look at your development department’s size, and how many years your developers have been working on the codebase. If the numbers don’t add up, you should be asking somebody in your organisation some difficult questions. The paradox is that “that somebody” is often the leader of the organisation, and not individual developers, and not even the head of the development department – Because productivity sprinkles down from the top. And if you cannot facilitate for your developers’ productivity to increase somehow, that’s your problem!

Identifying the strongest crypto algorithms

Approximately 10-15 years ago, NIST, an American organisation responsible for standardising technology standards, created a document describing how to correctly implement Elliptic Curve cryptography. This document became “the standard document” for others wanting to implement EC cryptography.

Some 5 years later, a really smart guy realised there was an “error” in the document. You see, NIST had proposed example values for G and P. These are two numbers required as you create your key pair. He did a lot of research, and quickly found out that if somebody knew the distance between P and G, they effectively had a backdoor allowing them to retrieve your private key, without too much effort. The thing was later revealed by Edward Snowden to be an infiltration job conspicuously executed by the NSA and the CIA in order to make people implement Elliptic Curve such that they could read whatever was encrypted using a public key.

This story tells us two things.

  1. Don’t (always) do what others tells you to do
  2. Elliptic Curve is a very, very, very strong form of crypto

The latter we know, since if this was executed by the CIA and the NSA, we must assume they had at the time no other means to decrypt your private communication, that had been encrypted using EC. Hence, if implemented correctly, EC encrypted messages was, at least at that time, impossible for the NSA and the CIA to decrypt.

If you Google for C# and AES today, the SERP of Google will show you some few examples of how to implement AES using C#. The problem is that they’re all rubbish! Some of the examples you find at StackOverflow is so easily brute forced, they could arguably be hacked by a 14 year old kid, with his father’s pocket calculator.

The first problem, is that they’re using Microsoft’s AES libraries, which makes it impossible to implement the correct padding of blocks, making an AES message easily brute forced by people with deep pockets.

The second problem, is that some of the code examples requires the user to give a 16 character long password, and simply does Encoding.UTF8.GetBytes to generate a “key”. This reduces the entropy of AES keys from 256 to the power of 16, 24 and 32 – Down to roughly 65 to the power of 16. 65 to the power of 16 can easily be brute forced in minutes by a modern computer. 256 by the power of 32 requires the same amount of energy that’s needed to boil all the water in our galaxy to brute force.

Now of course, both Microsoft and Google being American companies, have probably been coerced by NSA and the CIA to make sure everybody whom wants to implement cryptography, does it in such a way that the NSA and the CIA can easily decrypt it. The problem of course, which was explained by Edward Snowden, is that if the CIA and the NSA can read your messages, so can probably the FSB and Chinese intelligence – In addition to the Cosa Nostra and other criminal organisations.

Hence, if you want to identify the strongest cryptography algorithms in existence today, all you need to do, is to Google your algorithm, and find the algorithms with the most “rubbish examples”, reducing the strength of the original algorithm – And you’ve highly likely identified the algos that not even the NSA or the CIA can crack. This implies the algos having the most bogus example code at StackOverflow, while hiding its most serious implementations on “page 11.554” etc …

Just make sure you DO NOT implement the algo using the rubbish example code you find at SO once you’ve decided upon an algo.

Here you can see an implementation of AES done correctly

Download Magic

When it comes to crypto, NEVER, EVER, EVER copy code from SO

Caring more about process than product

Some 500 years ago, before the inventing of the printing press, monks would copy-write the Bible, to create new copies. It would take about 1-2 years for a monk to create a copy of the Bible, and the price of a copy was equivalent to the amount of gold you had to invest to buy a farm, capable of sustaining a large family with food.

In this era, it was more important to follow the process, than to deliver a good result. For instance, the monk had to pray several times per day, he was expected to write calligraphy, making the end product arguably only less readable, etc. Then comes Gutenberg, invents the printing press, and makes it possible for one man to create several copies of the Bible per day.

Today we have similar problems in the software development industry, where the quality of the end product sometimes seems to be of less importance, than following the correct process.

Software developers are the priesthood of the 21st Century, which of course is a historical anomaly, and cannot continue in the long run. Which is why I end my YouTube videos with “Embrace the future”.

How much of your job is CRUD?

If you’re a software developer, you know what CRUD means. But do you know how much of your job is actually creating CRUD endpoints, CRUD UX, etc?

In my work with Magic, I have realised that it creates a shitload of code as it is scaffolding a database. In fact, the Sakila database distributed by MySQL generates 15.000 lines of frontend code, and almost 3.000 lines of backend code. Over the last couple of months, I have also optimised it to the extreme, making sure I use base classes and reusable objects as much as possible, to reduce the size of the scaffolded code – Still after insane amounts of optimisations in regards to the size of its result, it still produces 18.000 lines of code in total for a simple 18 tables large database.

Some of these endpoints and grids are probably not needed, and the end solution you want to deliver would probably benefit from having some of these integrated into some parent object form. Still, I am willing to bet with you, you’d have a very hard time creating anything wrapping the Sakila database with a backend and a UX that ends up being smaller than 15.000 lines of code in total.

This implies that a very, very, very large portion of your work as a software developer implies creating simple CRUD endpoints, if you’re a full stack developer of course. Magic does this for free for you, giving you the time you need to focus on the fun stuff. If you’re never creating CRUD things in your work, and you don’t create database driven apps – You arguably don’t need Magic. For everything else, there’s Magic 😉

Getting more out of your ForEx software developers

The average software developer earns about 30-50.000 EUROs per year in Cyprus. Most medium sized ForEx companies have some 5-10 software developers. This results in an annual cost of roughly 200.000 to 400.000 EUROs per year. Most of the time, these developers are typically doing boring and repetitive work. What if I told you that you could easily double your developers’ productivity, would you believe me?

How to make your ForEx developers’ more productive

Using Magic doesn’t necessarily imply you can fire all your software developers, and simply click a button to replace what they’re doing today. And sure, Cyprus is a low cost country, where developer resources are inexpensive – But they’re still not free. Starting a ForEx company today implies spending 200-400 K EUROs per year on software developers, simply to have the company floating.

And sure, Magic does not create a finished product. But, it implies your existing developers no longer have to spend most of their time doing the boring stuff. Instead, they can focus on the fun and challenging stuff, such as creating MT4 Manager APIs, implementing the registration form, supporting multiple PSPs, etc.

But the boring stuff, you can literally outsource to your database administrator – Because once he’s created the db model, he can simply click a button, and voila! He’s created most of the boiler plate code necessary to wire up 80% of the code for things such as your CRM, partner administration system, etc, etc, etc. So even though Magic does not replace your existing software developers, it will definitely make them able to double their productivity. This implies you’ll get to cover twice as much ground, with the same amount of human resources as you used to have. And Magic’s cost? 347.68 EUROs per developer needing to use it. That’s a one time investment in your developers, making them deliver (at least) twice as much, in the same time. I think that’s worth it. Do you …?

Ohh yeah, did I mention that Magic is built with .Net Core, Angular and that it’s Open Source …? 😉

The Early Bird

It’s commonly known that the early bird gets the golden nugget. To reflect this wisdom, I am currently selling Magic for a ridiculously inexpensive price. The idea is to allow some few dozens of developers on board for pennies, realising they’ll give me valuable feedback, for then to slowly and incrementally increase the price over time.

The place I want to end at is somewhere between 200 and 350 dollars for a developer license, but currently it’s at $78. This is simply fair, since early birds hopefully will give me valuable feedback, and help me weed out bugs, and bring the product forward.

If you want to save a couple of dollars, by being the early bird, go check out Magic first. Then get licensed. For the record, you do get free updates, for the entirety of the 8.x track of releases – Implying you get the same value as those paying possibly $350 later down the road …

Win a Free Magic License

For a limited time, we’ve decided to give away 5 free license keys. The rules are as follows; You share a link to the main Magic website, and you somehow get at least 5 interactions, such as comments, likes, re-shares, etc – And you send us proof of it at – And you’ll participate in the contest, where we’ll draw 5 lucky winners, that each gets a free developer license each. This is worth $78 at the time of this writing.

FYI – Yup, we’ve increased the prices from $49 to $78, and we’ll probably slowly over time increase it, until it’s at somewhere between 200-350 dollars. Why? Because the current price is an anomaly anyways, and the only reasons we are giving it away as inexpensive as we are currently doing, is because we want early adopters to have an advantage.

A Magic license key allows one developer to work on, and deploy, as many Magic web apps as he or she sees fit. If more developers are working on the same project, one key is needed for each developer working on the same project.

Don’t know what Magic is …?

This is Magic … 😉