Software development bankruptcy

Debt is when you owe something to someone or something. Hence, cognitive debt, is when you have things you haven’t thought out well enough, and therefor are forced to think about them in the future.

When you build a house you need to start out with a solid foundation. If you don’t, the rest of the house will suffer, and as you want to make the foundation better, you’ll also need to completely remake your house. Hence, making sure you have a solid foundation for your house, is the by far most important task you have when creating a house – Otherwise the rest of your work’s quality becomes completely irrelevant.

When you start out a software project, the initial architectural decisions becomes your foundation. If you don’t make sure you have a solid foundation, the rest of your project will suffer, and it will end up the equivalent of a house built on a collapsing foundation.

The above describes cognitive debt as an analogy, and also situations where your debt becomes too large for you to ever be able to repay it.

Where I live, there are hundreds of houses built on moving ground. This becomes the equivalent of choosing the wrong framework during your initial software creation process, the wrong libraries, and the wrong tools. Frameworks are your project’s foundation. If you choose the wrong framework, you’ll build your project on a sliding foundation of mud, which will result in cognitive debt, too large for you to ever be able to repay it at some point in the future – And your project will inevitably collapse some day.

The above is the equivalent of software development bankruptcy. Choose the right foundation, or choose bankruptcy in the future.


If you ask a human being to perform a task, it might do it correctly. If you ask the same human being to do the same task 1.000 times, it’s impossible to do it correctly. It’s simply the human condition, and an integral part of our humanity, that performing the same task 1.000 times accurately is impossible.

If you ask the computer to do the same task 1.000 times, it will perform it perfectly, every single time – Assuming you have given your computer the correct instructions.

The above is the main advantage with computers, and arguably one of the primary reasons we choose to use computers at all. It’s your computer’s value proposition figuratively speaking.

When a software developer is asked to create a piece of software, a large portion of his work is repetetive in nature. For instance, how many times do we have to implement JWT verification? The answer is once for every app we create. If you create JWT verification manually every time you’re asked to do it, you’re exposing your end result to potential errors and security holes. If you ask your computer to do it though, it’ll do it correctly a million times for you – Assuming you’re able to inform your computer how to implement it accurately.

Facts are, software development as we perceive it today, is arguably in the stone ages. Not only are we exposing ourselves to errors due to lack of automation in our own processes, but we’re also increasing our own costs by several orders of magnitudes – Simply because a computer can implement JWT verification for 0.00000001 dollar, in a fraction of a second. While a software developer’s cost to implement the same thing, easily becomes thousands of dollars, and sometimes requires weeks of coding.

Choose automation whenever you can choose it!

How to paint your door

Imagine if building and maintaining your house suffered from the same amount of bureaucracy as software development. Then imagine trying to paint the door to your house.

Before you could even start discussing paint, you’d have to hire 5 lawyers. These lawyers would spend three months writing a piece of paper that all participants had to sign, which said “I will not reveal any details about the coloring of this door.” Then you’d have to hire a Chief Door Officer, a Head of Door Painting Chief, a Human Resource Door-Painting Director to supervise that nobody got hurt in the process, a Door-Painting Risk Assessment Director to constantly calculate the risk of the greenness of the door, a dedicated Specialized Door Painting Chef to create food to your employees, in addition to some 25 painters, and 250 Door Coloring Quality Assurance employees, to make sure the door was “really green enough”. And of course, all of these employees would have to be specialists, with 25 different certifications each, and a PhD each in door painting, to prove that they actually knew their jobs.

Before they could even open up as much as a bucket of paint, each painter would spend three months arguing over the chemical compounds to use in the paint, the CMYK composition that most closely resembles the word “green”, in addition to arguing over whether or not they should use a pig hair paintbrush, or some new plastic based paintbrush. Not to mention that every time anyone brings up the question of whether or not to use Agile or Waterfall methodologies, the entire office would erupt into fist fights and quarreling, to such an extent, the Human Resource Door-Painter Manager would have to hire baboons to simply separate the different fighting fractions. Licenses for the chef’s recipes alone, would dwarf an average African Republic’s gross national product too may I add …

Of course, nobody could yet again not even open as much as a single bucket of paint, before the Risk Assessment manager had created unit tests for your door, which implies creating a robot that opens and closes your door, 11.000 times every day, to make sure its handles doesn’t break. Some 9 -18 months later, you can finally start painting your door. 15 years later, having spent 25 million dollars, employing half the village, and spending your country’s national gross product on a bucket of green paint, you could finally experience your new door – A new shiny green door, making you the envy of all your neighbors.

Am I the only one seeing the problem here …?

Don’t get me wrong, I love my unit tests – There are in fact more than 300 unit tests in Magic. But Magic was built arguably on the front page of MSDN Magazine, no NDAs to be seen. Every time I had a problem, I would post my code to Reddit and ask the great people over at /r/dotnet for help, to look at my code, and come with improvement suggestions. It was built by a single person, almost exclusively in his weekends and spare time, and still it’s a “billion dollar project”. In fact, I would argue, Magic has a higher amount of quality, than every single “professional project” I have ever worked on combined, even though I never had a Chief Door Technology Officer, or a Paint Risk Assessment Manager, or even a dedicated chef for that matter. And I can pretty much guarantee you that my budget for building it, was far away from the gross national product of both Norway and Cyprus for that matter.

Magic is not the exception that confirms the rule, Magic is the confirmation of that the rules sux, and that our current ideas of building software, are in fact madness!

20 GOTO 10

The above Amstrad CPC464 BASIC illustrates how easily it could be done. Sorry to sound the alarm here, but we lost something along the road …

Magic, a part of the official .Net Documentation

From 2017 to 2019 I wrote 6 articles about C# architecture and design patterns for MSDN Magazine. Later the magazine was closed, and its most important and relevant articles were moved to the official documentation for .Net. Although I am saddened to see MSDN Magazine being pulled, and I will dearly miss working with Michael, James and the other brilliant people over there – I can’t deny the fact that I am also proud to see all of my articles about Magic now becoming a part of Microsoft’s official .Net documentation.

This actually implies that Magic is now an integral part of the official .Net documentation – Which is no small feat for an independent software vendor. Notice, parts of my ideas have evolved since I wrote the first article about Active Events in 2017, but the main ideas are still similar enough for most to have some sort of benefit of reading these articles. Two of my articles also became among the most read articles they ever published during their existence. The Active Event article made it up to among top 20 most read articles, and the Hyperlambda article became the 5th most read article, for the magazine’s last decade of existence.

If you want to read these articles, you can find them below.

  1. Super DRY development for ASP.NET Core
  2. Active Events: One Design Pattern instead of a dozen
  3. Make C# more dynamic with Hyperlambda
  4. Create your own script language with Symbolic Delegates
  5. Minimize complexity in multithreaded C# code
  6. Could Managed Ajax put your Web apps in the fast lane?

Out of the above articles, probably the most relevant to Magic are the Active Event article, in addition to the Hyperlambda article. Parts of the ideas have evolved since I wrote these articles, but the general idea should be similar enough to make you recognize it in relationship to Magic and how it looks like today.

The cost of cutting corners

I have worked in software development departments, where after the product was finished, we had to hire an additional 20 developers just to keep it running. Those whom are seasoned developers among us, can immediately understand what I am talking about.

When you cut corners, you create unstable software. When you create unstable software, a large portion of your operations will fail. When an operation fails, you’ll need somebody that understands the system to babysit it, and fix it – Which of course translates to a software developer for all practical concerns.

Requiring a software developer to babysit 25% of your form submissions, spending hours reading through log files, to figure out what goes wrong – Is probably OK if you live in a world where a software developer will cost you $5 per hour. If you live in the real world though, it is not OK!

Preventing 25% of your users to register at your website, having them wait for 2 days while 2-3 software developers tries to figure out why their registration form doesn’t work if the user has an รณ character in his name, because of a bug in your software system – Is not OK!

However, just breadth in and out and stay calm. Because somewhere out there, is somebody whom are not willing to cut corners when creating their systems. Somewhere out there, is some software development department wanting to do things right. They might not make it first to market, and you might be able to outperform them in the short run – However, when they finally do come around, they’ll blow your value proposition off the table, and you’ll be left picking up the scraps from their table, without any amount of sustainable revenue – Yet still needing to hire 10x as many software developers, to maintain a system with 10x as many bugs, spending half their days reading through log files …

Good luck with that ๐Ÿ˜‰


Symbiosis is when two different organisms lives together in a relationship that are mutually beneficial to each other, without competing with each other, but rather helping each other out, making sure the other party have some sort of benefit from the other party’s existence.

Yesterday I attended a meeting as a DZone core member together with the community managers from DZone and some 10-12 other article writers. All of us had been given the opportunity to give DZone feedback before the meeting, and during the meeting we got to hear that they had taken our feedback to their hearts.

For instance, DZone will now start giving out SEO juice to article writers, implying that a popular article on DZone, will now start counting in regards to SEO link optimisation. In addition there were multiple other minor things they were looking to fix, due to the feedback their writers had been giving them over the last couple of weeks.

Small changes like these makes it much more tempting to talk positively about the site, simply because in the end, everybody only wants somebody else to scratch their back I assume. However, few will scratch other people’s backs unless there is something to be gained from the process.

Thank you for a nice meeting Blake, Mike and the others participating – And thank you for listening to us, your writers, and arguably also your main assets. And thank you for understanding this important word – Symbiosis that is. I’ll start with a little bit of paying it forward, as a gesture of how much I appreciate these new ideas, to such hopefully give them water, and the ability to grow into even more and better symbiotic ideas …

Read some great tech and software development news here

Have a nice day ๐Ÿ˜‰

The art of breaking rules

Do you want to know a secret? You don’t have to use things in accordance to the instructions given by those who created the things you want to use. For instance, GitHub is probably one of the largest untapped resources for hiring software developers on the planet today.

Nobody would hire a piano player without listening to him play first. In software development however, we are expected to hire people based upon some rubbish piece of paper, and whether or not the guy remembers how to implement quick sort in Pascal.

If you go to GitHub today, you won’t find any “I am available for hire” badge. Still, many of those creating marvellous open source projects would probably easily accept an offer from you, if given one. This allows you to off shore software development, literally without risk, because you can assess the quality of the developer and his code, before you hire him or her.

Break the rules. It gives you an edge!

The man from the future

Some people are cursed, because they can see the future. Not because they’re psychic or clair voiant or something, but rather because of that they have studied the past, and are therefor able to draw lines, stretching far into the future.

These people are always cursed, because they tell us “inconvenient truths”. Truths the others amongst us for some reasons don’t want to hear, because they would rather live comfortable within the confined space of their own lies.

Such men and women live solitary lives, never being believed, before it’s too late for others to take their wisdoms to their hearts. Such people are always hated and despised by their peers, because they raise the alarm when nobody wants to hear it. And afterwards when the others realise they were right all along, others who didn’t want to listen, feel shameful for not listening in the first place. Even “winning” for these people is a curse.

I am here to tell you to be that man! Not because it will give you rewards, quite the contrary in fact – But because we need more people like this!

I can promise you it will be painful, and I can promise you that you will be hated, and you will be despised – But in the end you will start to realise that is the reward in fact.

Be the man from the future! We need more of you! Because in the end, the Truth shall truly set you free – Often in ways you cannot even possibly comprehend as you start being the Man from the Future.

Be the man from the future! We need more like you!

Machinery Nirvana

I once heard a funny joke about having a job, it went like this “If having a job was such a fantastic thing, owners of companies would have kept all the jobs to themselves.”

Let’s be honest about this, a lot of the jobs we do, aren’t exactly rocket science, and not particularly intellectually challenging. Don’t get me wrong, I love my job. As a software developer, I get to work on really hard and intellectually challenging problems – But a lot of the work I do, is also arguably work we could have trained monkeys to do. It’s repetitive in nature, requires little intellect to complete, and yet a tiny error can still have drastic consequences.

The first time a brain surgeon performs some difficult procedure, it’s challenging. The 5th time he does the same procedure, it’s routine. The 1.500th time he does it, he’s probably thinking of his upcoming weekend at Disney Land, as his autonomous nervous system cuts through your brain tissue on autopilot. For the record, this is not a good thing.

If the brain surgeon could somehow teach a machine to do the same procedure, the surgeon could instead of being bored at work, spend his time at Disney Land with his wife and children. And the machine would never be bored, it would always perform the procedure the exact same way, and it would highly unlikely do errors that the human being could do, due to lack of focus. Machines are simply better at this type of work than humans. This is a fact. As long as the parameters are not changing, or some unforeseeable event occurs, and the task is repetitive in nature – The machine will always outperform the human.

Brain surgery is probably not the best example here, and you might not necessarily be willing to allow some computer to rewire your synaptic connections, based upon some algorithm – But in software development, I can think of a million tasks, where the parameters are never changing, yet the task is extremely repetitive in nature. Having a human being do these tasks, is not only boring and less cost effective – But also flat out madness.

Don’t be insane, have your computer do whatever your computer can do!

The Magic Hammer

I once heard a story, apparently it’s true. 40 years ago some company had a problem with their hard drive. For some reasons the hard drive wouldn’t start in the morning. This was in the days when hard drives were the size of refrigerators, and still couldn’t store more than 20 megabytes. Hard drives back then also had a cost of a small fortune. The CEO of the company that owned the hard drive was panicking. His 25 employees couldn’t work, and the company was slowly suffocating. They call in some brilliant repair guy, and the guy comes over with a small hammer. He carefully nudges his hammer in the corner of the hard drive, and the hard drive magically starts working. Naturally everyone are grateful, and the repair guy goes back to his shop after having spent only 5 minutes with his customer.

Later the repair guy sends an invoice for $2.500. The CEO almost has a heart attack, and asks the repair guy on the telephone “did you really send us an invoice for 2.500 dollars to nudge our hard drive with a hammer?” The repair guy answers as follows …

“No, I invoiced you only 1 dollar to nudge your hard drive. The rest of the invoice was because I knew where to nudge it, and because I have a special hammer.”

Facts are, you could have hired 1.000 carpenters with hammers, and none of them would have been able to fix your hard drive. Sometimes it’s better to pay only one, assuming he’s got a magical hammer.