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 – Obviously! This simple fact doesn’t require a PhD in rocket science to understand.

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.

Managers are from Mars, software developers from interstellar space

Imagine a Norwegian going to China, trying to order a meal, for then to have the waiter speak for 30 minutes non stop to you in Mandarin. Assuming you actually don’t know Mandarin – How would that feel like? Then realise that this is how it feels like for most managers when they try to have a software developer explain stuff to them.

Facts are, there are roughly 26 million software developers on the planet today, but trying to have most of these explain their jobs to a neuro typical Homo sapiens, feels like an exercise in futility. That is because we live in two different worlds. The manager is thinking about his problems, which might include how to acquire more customers, how to squeeze more productivity out of his employees, and outperform his competitors, etc – While the average software developer is thinking about ways to optimise Duff’s device. (Hint; Don’t even click it unless you’re a developer. Most developers can’t even understand it)

There is obviously a communication mismatch between software developers and (most of) their managers

Therefor it becomes crucial for an organisation to have some “medium”, that is capable of moving between both worlds. An individual that easily understands Duff’s device, yet still understands the futility of explaining it to his non-technical management using technical words. Basically, some guy (or gal) that can explain it as follows.

It makes your stuff move faster!

And really, that’s all the non-technical manager needs to know. Maybe he’ll ask questions such as “How much faster”, as to where the medium can answer; “Well, we’ve tested it towards our old functions, and it seems to optimise the image processors of our 3D scenes by 25%. We can basically create 25% more images per second, with the same hardware we previously used.” That’s all the non-technical manager needs to know.

However, this creates another problem, which is that the average manager cannot possibly even come close to being able to evaluate the skill level of his employees. Two Chinese people can speak to you at the same time. One of the guys are telling you about how his constipation made his morning feel awful – While the other Chinese guy is explaining how to maximise your profit, by including some hard core heavy rocket science stuff, which he perfectly describes to you, using the laws of quantum mechanics and abstract math – And the non-technical manager would think they’re just as good both of them, and possibly even fire the rocket scientist guy, believing the guy speaking about his constipation problems are just as good at his job as the other guy, and the manager wants to save money by reducing his staff. Believe me, weirder stuff have happened in the real world.

If the non-technical manager is able to hire a guy who is both a perfect rocket scientist, in addition to being able to explain stuff to him – He has a competitive edge – Obviously!

Every single organisation that employs software developers needs a manager that can easily understand code and the art of creating software – In addition to understanding the more down to earth requirements of creating a successful company. Then they need to use this person as a “medium” between the non-technical management, and its software developers – Otherwise they might as well put their faith in luck.

Creating a micro SSO JWT authentication/authorisation HTTP REST API

I have just published a video about how to create a minimalistic SSO/JWT authentication/authorisation HTTP REST Web API. Below you can find the video, and further down you can find the code for the POST REST endpoint to make sure you cryptographically hash your users’ passwords. Make sure you download at least version 4.7 of Magic, which can be done here.





Mythical man month

Of all the concepts I have ever tried to explain to non-technical management, the “mythical man month” is probably the by far most unintuitive concept. The ideas behind it, was thoroughly researched already back in the 1960s, and several books have been written about it, in addition to that hundreds of independent scientific studies have proven the theory to be correct – Still it seems like almost impossible to believe in for most non-technical managers.

When the idea was first coined, the man behind it, who was a computer scientist working for IBM at the time, even wrote a book by the same name. The book is fairly long, and enters long arguments, trying to justify its existence – But the idea can be summed up with a simple sentence. Please read it several times to make sure you understand it …

One system developer can do in one month what two system developers can do in two months

Yes, you read it correctly – At least I hope you did. Hint; If you weren’t surprised, read the above sentence once more. It’s almost like “black magic” when you think about it, but the theory have been proven to be correct thousands of times since the idea was originally coined. The reasons are complex, and includes a lot of esoteric and unavailable understandings, such as communication overhead, coordination requirements, integration problems, lack of cohesion, and lack of tranquility – But believe me, the idea is as sound as gravity. What the idea basically implies, is as follows.

One software developer could easily replace Google, while 200 software developers could never do the same.

And in fact, we’ve already seen this in the real world, in the form of Mark Zuckerberg, who arguably is (yes he actually is) a mediocre software developer. But the most famous example of the theory is Linus Thorvalds, and I don’t mean because of his “Linux thing” – Nope, I mean because of his “Git thing”.

When Linus needed a scalable software versioning system, he looked around, and investigated CVS, SourceSafe, SubVersions, and practically all other versioning software systems that existed – Only to conclude with that they were “all rubbish”. At this point in time, approximately 20+ million software developers had been working with some sort of software versioning system for approximately 70+ years – Leading you to believe the problems should have been solved decades ago. But no, this wasn’t the case – At least not according to Linus.

So Linus took “vacation” from maintaining the Linux core, and spent 10 months implementing a software versioning system. Today you know this system by the name “Git”. Today most developers without grey hairs can’t even remember the alternatives, but believe me, they existed. Yup, I’ve gone through SourceSafe, Microsoft Teams, SubVersions and even CVS – And Linus Thorvalds was right; They’re all rubbish!

In 10 months one single software developer, created arguably a software versioning system revolution, resulting in changing the daily routines of 26 million software developers, in 300+ countries on the planet – And he was alone, and he spent no more than 10 months!

Let that simple fact sink in for a while please …

Now of course, Linus is not “just another developer”, but that’ll be the subject of another blog …