Magic, 2.5x faster than Python’s Django and 5.5x faster than PHP’s Laravel

I was asked how much Magic scales, and how fast it is, compared to other popular solutions out there – And this question intrigued me to such an extent I had to find the answer for it myself. Since there are a whole range of existing performance measurements out there comparing .Net Core to PHP’s Laravel and Python’s Django, I could get away with simply comparing a Magic solution to a “pure” C# and .Net Core Web API, for then to simply extrapolate my numbers unto existing graphs. Maybe you think that this was “cheating”, but since Magic is all about doing less work, and get more results – I kind of felt it would be in the “Magic spirit” to avoid repeating things you could easily find out through a simple Google search.

My conclusions was that Magic is roughly 33% slower than a pure .Net Core controller endpoint, ignoring the fact that Magic has 10x the number of features as its “pure” .Net Core equivalent. Since a pure .Net Core solution is between 3 and 8 times as fast as its Django and Laravel equivalent, this puts Magic into the league as 2.5 times and 5.5 times as fast as their Python and Laravel equivalents. Read the performance article where I got these numbers here. In the video below you can see how I accomplished these numbers, what code I was executing, and how I did the measurement – Such that you can reproduce it for yourself, in case you doubt me.

Conclusion – Magic is between 2.5x and 5.5x faster than Django and Laravel

As a final note, I want to emphasise that the “pure” .Net Core solution did not support paging, filtering, rich querying, or any of the added features the Magic solution gives you out of the box. Hence, the comparison isn’t really a just comparison without mentioning this simple fact. I could of course have pulled in OData, at which point my pure .Net Core solution would also have ended up with query capabilities. I suspect this would have resulted in that Magic would have significantly outperformed the pure .Net Core solution, probably by several folds – But these are my assumptions, and should be taken with a grain of salt, until proven to be correct or incorrect.

As an additional note, I must also say that even though Magic obviously is really, really fast – Magic’s most important feature is not in speed of execution – It is in speed of development. It took me about 30 minutes to wrap up the code for a really simply .Net Controller HTTP GET endpoint. It took me about 1 second to create a much richer and more flexible HTTP GET endpoint in Magic.

Hence, regardless of how you compare Magic to a manual solution, where code has to be written, it becomes an unfair comparison – Simply because with Magic the whole idea is to completely avoid the creation of code. Something I have illustrated previously in one of my videos where I wrap a Sugar CRM database with 222 table, creating 888 HTTP REST endpoints, by simply clicking a button.

Let me put this into perspectives. It took me 30 minutes to wrap up a simple HTTP GET endpoint in C#. If I was to add filtering for it, paging, and query capabilities – It would probably require me (at least) 3x the amount of time. Extrapolating 1.5 hours of development into 888 HTTP endpoints, becomes 1332 hours of software development. 1332 hours divided by 8 becomes 166.5 days of actual development. 166.5 divided by 5 days (working days per week) becomes 33.3 weeks of development. This translates into 7.9 months of development – Ignoring vacations and such. Hence, one man would have to work for roughly 8 months to produce what I did in one second, by clicking a button, and my computer spent 40 seconds delivering – Assuming we can extrapolate 1.5 hours into 888 HTTP REST endpoints. If we were to take this amount of time literally, and translate it into costs, this results in that creating code yourself becomes for this particular use case 4.795.200 times as expensive. Simply because 1332 hours becomes 4.795.200 seconds, and it took me “1 second of man hours” to create Magic’s 888 HTTP REST endpoints.

Of course the above is arguably “China math”, and there are many additional things to consider in a real solution, skewing the numbers towards one or the other directions. For instance, what about maintenance? But if we are to take the numbers literally, you will need roughly 5 million dollars to achieve the same thing manually coding, as you can achieve with $1 and Magic.

1 dollar with Magic brings you the same as 5 MILLION dollars without Magic

Yet again, take the above numbers with a grain of salt, since there are a lot of other factors you need to consider when choosing how to implement your solution. But the above are interesting numbers, and arguably impossible to prove “wrong”, although yet again I want to emphasise that they are “China math”

But that Magic saves you costs, resources, and therefor money – Is beyond any doubt for those with eyes to see for themselves. Now we also know that Magic results in faster end products, at least compared to everything that can compare itself towards Magic.

Identifying your Pearls

What is the real value of your company?

If your software is legacy garbage, what is your company’s true value then? I don’t really have to say this out loud to a seasoned manager, but it’s the relationships you have with your customers, combined with your database. The experiences your clients and customers have with you, combined with the information you have about these clients, is your company’s real value. Your database is the reasons why your key account manager can call up “John Doe” and ask him how his BBQ last Saturday was, and if he’s interested in purchasing your latest product, that outperforms the previous version by 1.8 times on all metrics – Closing the sale due to his existing relationship with Mr. Doe, becomes almost as the most natural thing in this world. Any person having any kind of experience with sales can easily agree with this.

However, if your existing software systems needs 30 minutes of finding Mr. Doe’s last activities, and the last phone conversation your key account manager had with him – Then your software system becomes an anchor that drags you down, instead of lifting you up. This implies that if you are to completely change your existing software, you must change it in such a way that you can still leverage your existing asset: Your database. Hence your next generation of software, must be able to bring the lessons from the previous generation of software with it, in order to provide value to your company, while still being fresh, modern, and blistering fast – Following all the modern best practices in regards to UX, security, and scalability.

Luckily, your database contains what we software developers refers to as “meta information”. This information allows us software developers to gain knowledge about the structure of your data. This structure can then be used to automatically recreate your software, and upgrade it according to modern standards, getting rid of all the legacy garbage you’ve been dragging around for a decade or more. Basically, this meta information allows us to recreate your backend software system, literally in seconds. Watch the following video to understand how, where I take an existing CRM system, that has been maintained for more than a decade, and arguably port it to a modern platform, getting rid of all legacy garbage in the process, and I am able to do it in 40 seconds!

I want to emphasise, that the above video demonstrating literally doing some 40-60 percent of the job of recreating your entire software system, and it is doing that job in 40 seconds. This allows us to create an entirely new software system, based upon your existing data, and its structure, and simply “apply” an entirely new software backend to it. New software that is highly optimized, extremely scalable, and super secure. Software that is created for the future, and not your past.

When asked how to build a house, others will start building. I will spend 10 years thinking about how I can build a house in 10 seconds. Then when I have succeeded, I will build thousands of houses in one hour.

The above process is unique for something I refer to as “Magic”, which is a proprietary tool, I have spent more than a decade of researching and building. Paradoxically, as I created it, I had to throw away 3 “legacy versions” of it myself, which wasn’t good enough for different reasons. Hence, I do as a preach – Few can object to that simple fact. Now it’s your turn to get rid of your old garbage, and upgrade your software infrastructure, and ready yourself for your future – Getting rid of the “past ghosts from previous times” in the process. Contact me below if you’d like to hear more about this. Or check out Magic for yourself if you’re curious, and technically savvy enough to understand the process.

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.

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.