Demand to see your Software Vendor’s Unit Test suite!

A 370 million dollar accident, happening because of lack of Unit Testing of software: Ariane 5! Don’t be Ariane 5!

A car manufacturer that doesn’t test its vehicles, is a minefield waiting to explode in somebody’s face. Everybody can relate to that simple fact – Which is why the car industry every now and then make video footage publicly available, of blowing up some car, by driving it at 65 miles per hour into a brick wall, demonstrating how some sort of dummy is only suffering “minor injuries” due to the collision.

The same way the car industry is in such a regard made accountable for its testing, a software vendor should be made accountable for its product. This is in fact very simple too, and much less expensive than blowing up some car by driving it into a brick wall at 65 miles per hour. Just inform your software vendor of that you’d like to see their Unit Test suite for the product before you purchase it. Preferably (at least) demonstrated in some sort of video, illustrating how they are taking testing seriously.

Nobody would put their asses into a car without knowing for certain that the car producer have done extensive testing of the vehicle before it was let loose on the road. And neither should you allow your software vendor to sell you software that he can’t prove has been tested, with a coverage of at least some 60-80 percent. If you do, it is the equivalent of putting your ass down on an airplane seat, that “probably won’t explode in mid air”, but nobody would know for sure, because the engines haven’t been tested before allowing passengers on board.

Demand to see the Unit Test suite from your Software vendor. If he can’t show it to you, walk away. It’s really that simple …

The Myth of Unit Testing

Would you want to hang here without a rope? The dirty industry secret is that you ARE hanging here without a rope!

Do you want to know a dirty little secret? In “real life” nobody are creating Unit Tests, at least not in my line of business. Every single time I have applied for a job as a software developer, I have seen lots of fancy buzz words about how they expect you to create Unit Tests, and expects the developer to create tests for every piece of code he (or she) creates. However, as I start my job working for the company, I discover that the test suite have a 50% fail ratio, if there even is a Test Suite at all – And I’m not allowed to make it work, because that is “unproductive work”, and we “don’t have time for such things”, and the test suite haven’t been maintained for half a decade. The irony …

TDD, xUnit, nUnit, Continuous Integration, DevOps, etc – Fancy words and all that, but all of these words are useless without a rich suite of Unit Tests. In fact, DevOps without Unit Tests, is like driving a spaceship, made out of paper, to the moon, without space suites. It will inevitably go wrong, and all sorts of shit is destined to happen.

I don’t know about you, but for me this is a real problem, making my life as a software developer that much more difficult, since it implies having to manually run all sorts of tests, for every piece of change I do, effectively making me 10x less productive in my “day job”. Regardless of how a company projects itself in job ads, and on LinkedIn, I’ll bet with 98% certainty, that their Unit Test suite is a joke. Don’t believe me? Go ask your own developers.

FYI, Magic has roughly 400 Unit Tests, and no I don’t have 100% coverage, and I could have better coverage, but my ~60-70 percent coverage, is roughly 60-70 percent better than the stuff that’s in your ATM machine, and your pacemaker. I find that fact quite scary to be honest with you …!! :S

The advantages of doing the “big rewrite”

Purely statistically, this is your current codebase

The big rewrite scares the living crap out of many software developers, and especially managers. The arguments against it are basically permutations of “We have spent a decade maintaining this codebase, and we have had dozens of employees working on it,  and you want to start all over again?” Of course, to an experienced software developer, the above argument is exactly why the code should be rewritten. If you don’t understand why, read the argument again, this time thinking about what it’s actually stating.

However, most managers believes that just because the spent 100+ man-hours creating the code in the first place, it will also require 100+ man hours re-creating the code. This is a fundamentally flawed argument, and has no hold in reality what so ever. In fact, I’d argue that every time you create the same piece of software, you can do it 5 times as fast. Hence, if you have created a system 3 times, the 4th time you create it, you can create it 125 times as fast as you did the first time. Simply because you at this point know everything that’s needed to wire the system together, and you are able to produce smaller and tighter code, and paradoxically the result also becomes better as a result of rewriting the system. I should know, having done this dozens of times myself. In fact, this is almost a “natural law of system development”, almost like Moore’s law. It’s difficult to believe in though, so let me illustrate my point, by showing you how I recreated a CRM system, wrapping 222 database tables, arguably replacing (at least) 50% of an existing legacy system, that had been maintained by dozens of software developers for more than a decade – And I did it in 40 seconds!

Don’t fear the big rewrite, fear the fear of the big rewrite

Facts are, there is a 95% statistical probability of that the code you currently love, in the codebase you have maintained for more than a decade, having dozens of software developers maintaining, is PURE GARBAGE! I should know having worked on dozens of legacy systems, spanning a range of more than 37 years of software development.

Download Magic here if you’re not afraid of the big rewrite

Creating a Web API backend with ZERO lines of code, and invoking it with ONE line of code

About a year ago I told an acquaintance of me on Twitter that I was working on a “zero lines of code” software framework. His reply was “I don’t believe in zero lines of code, but I believe in ‘low code’ frameworks”. In the end he was right, because I couldn’t reduce the LOC to ZERO. Regardless of how much I tried, I still ended up with ONE single line of code … 😉

Failure comes in many flavours, also sweet

Anyways, Magic is now at the point where I can literally wrap any MySQL or MS SQL Server database into a Web API backend, without having to write one single line of code. This works by having my computer read meta data from the SQL database schema, for then to generate or “scaffold” Hyperlambda code, that results in HTTP REST endpoints, for every single CRUD operation towards my database. So far so good, still at ZERO lines of code. Watch the video below where my computer is automatically creating 888 HTTP REST endpoints, and equally many code files, in some roughly 40 seconds.

Then comes the need for authentication and authorisation, in addition to that sometimes the automatically generated CRUD endpoints sometimes needs to evaluate custom SQL, and you can’t rely upon the “automatically generated” SQL that only allows you to do simply CRUD – Even though it’s obviously powerful, and allows you to create fairly complex stuff “for zero effort”. Watch the following video for a “deep dive into how Magic actually works” – That demonstrates it in more details, and goes through it in more details.

So far we’ve created ZERO lines of code, right – Even though we have arguably created an entire CRM system, with 888 HTTP REST endpoints, wrapping an extremely complex and rich database (Sugar CRM’s database, with 222 tables). Then unfortunately to the point where I “fail” – Since I needed to “sugar the pill” with one single line of code – Where I invoke any HTTP REST endpoint from Hyperlambda, using the “Evaluator” of Magic – Which becomes the one single line of code, proving how my friend was right, and that “Zero code frameworks don’t exists”.

Sorry, I failed 😀

Psst, if you want to read my DZone article about how to invoke HTTP REST endpoints with a single line of C# code, you can find it here

Magic, Django for .Net Core

A friend of mine showed me Django for Python a year ago, and I became envious, realising there wasn’t anything like it for .Net – So I decided to create something resembling Django for .Net Core myself. Below I demonstrate the latest release of Magic, where I have created support for query parameters and operators in its HTTP GET REST endpoints, at which point I’d argue it’s not really that far away from Django myself.

Read more about Magic and download it here

“Porting” Entity Framework’s EDMX files to .Net Core

We’ve all been there, our manager asks us to port a 10 year old legacy app, built with all the wrong design patterns from .Net Framework’s Entity Framework to .Net Core – Just to realise that .Net Core’s implementation of Entity Framework is literally a completely different library. It’s basically the equivalent of “porting” your database layer from Python to Lisp. You might as well give up. SHIFT + DELETE the folder with your backend code, and start the project entirely from scratch is my advice to you.

However, the good news is that I’ve got a tool that allows you to reignite your backend, extremely rapidly, assuming you have a ton of endpoints simply doing CRUD stuff + authorisation. If this is true for your solution, you can literally recreate an entirely new .Net Core based backend in seconds, without having to bother about how to change from your EDMX file’s syntax to the new attributed version of .Net Core’s Entity Framework. Watch the video to understand what I am talking about 🙂

How Magic works

Magic is a CRUD backend generator that will scaffold up HTTP REST endpoints for you, wrapping your database “automagically”. This allows you to point it towards an existing database, click a button, and end up with every single CRUD operation towards every single table in your database. Behind the scenes, Magic will read the meta data from your database, and create one code file for every single CRUD operation in your database. These code files will contain “Hyperlambda” code. Magic supports both MySQL and Microsoft SQL Server databases, and is built on top of .Net Core and C#. Most of its source code is publicly available online.

Hyperlambda is my own programming language, inspired by YAML, that allows you to create functionality in a more “declarative way” than traditional programming. In fact, if you look at any of the Hyperlambda files that Magic creates, they will resemble “configuration files” more than for instance C#. However, have no doubts, Hyperlambda is 100% perfectly Turing complete, and actually a “real” programming language, albeit a bit “simple” in its syntax. For instance, Hyperlambda have no classes, no OO, and none of the complex and advanced structures that more “hardcore” programming languages contains, such as C# or Java. In a way, Hyperlambda is a super scalable DSL, as easily understood and extended as FoxPro or Clipper from the old days of 4th generation programming languages – But of course 100 times as scalable as both FoxPro and Clipper were. Hyperlambda sits as a tiny layer in between your HTTP REST endpoint, and the C# code that Magic is built with. Hence, for Magic, Hyperlambda is an “orchestration programming language with DSL qualities”.

Magic also contains a “routing controller” which is a plain C# controller class, that accepts “any URL”. This component will map URLs and HTTP verbs to files physically existing in your Magic installation – Some of whom are the results of the CRUDify operations you have performed on your databases. This combination between having physical files representing each endpoint, and using Hyperlambda to “declare” the endpoints functionality, allows Magic to know a lot of meta information about its own capabilities. You can see this in action after you have CRUDified your tables, and you click the “Endpoints” menu item, to look at your endpoints. This results in that Magic produces a very friendly API, arguably inspired by the Open Web API initiative, that allows you to “see” into your server, and understand what Magic is capable of doing – Without risking creating security holes, etc. Each endpoint can be secured through mechanisms of authorisation and authentication, forcing the client that invokes your endpoint, to belong to some pre-defined role to allow him or her access to execute the code in the endpoint. Internally, Magic is using JWT security tokens to authenticate and authorise its clients.

The end results of this, becomes that you can create 4662 lines of code, and 888 code files, wrapping a database with 222 tables into all CRUD operations, securely – In no more than 40 seconds. Which is what I am doing in the video below.

Notice, scaffolding endpoints and creating CRUD endpoints from your database, does not even interrupt normal usage of the existing backend – And could in theory be done on your production server, without interrupting normal usage. An analogy for this process would be repairing the wings of an airplane, during its flight, without risk of crashing.

Extending Magic with your own functionality, is easy, since the whole thing is created in C#. So you can easily mix Magic with as much C# code as you wish, in addition to creating your own “keywords” for Hyperlambda, by looking at how the existing keywords are implemented, in components such as magic.lambda. However, you don’t really need to understand Hyperlambda at all in order to use Magic – Because it was created more to be understood by the computer, than to be understood by the software developer. In a way, Hyperlambda serves the same function to Magic as IL code or Assembly code serves to C# and C++. So hence, arguably, there is little or no new knowledge required to start using Magic in your own solution – Beyond being able to modify a connection string, compiling your Angular frontend, and C# backend, and literally clicking a button. Clicking that button of course, often results in saving you for hundreds and sometimes thousands of hours of work – Which is its purpose.

That’s why I chose to name it Magic, because you don’t need to understand how it works to take advantage of it. You can simply take advantage of that something else understands how it works (your computer), for then to take advantage of your computer’s ability to make you fly, kind of like you probably don’t understands how a Boing 747 works – But you can still fly. And that’s Magic!

If you’re still interested in its technical details, and you feel you have to understand its internals, 98% of its source code is publicly available online by following my GitHub account. Magic will cost your company €495 for each server you want to run it on. You can obtain a license to run Magic here.

Cutting your software development costs in half

Let’s be honest about this. Much of the work we software developers do during our day, doesn’t require an Einstein – It’s repetetive and boring work, but still required to make the end product function – And it could arguably be done by “trained monkeys”. If you go through what you did today, I am sure you can relate to this. Making computers offload some of our burdens in these regards, isn’t exactly a new thing either. Databases are basically an alternative to old style libraries and document cabinets. Emails are basically an alternative to snail mail. So making the computer do our work, isn’t something new either. So how come we haven’t made our computers create our code then?

In the video below I am demonstrating Magic. Magic allows you to do just that, basically cut your costs in half, and only leave the fun and challenging parts of your software development job left – While your computer does all the boring and repetetive stuff.

Then imagine how your business could prosper, if you could get away with being equally productive, but only needing to spend half of your costs? If you want to talk with me about Magic, feel free to use the form below.

Make money creating Open Source code

For a long time it has bothered me that so many great developers are creating so much awesome software, and releasing it as Open Source, without being able to earn money on their work. If you ask most of the Open Source “titans” about how much they’re making in donations, their answer is “not anywhere near enough”. I might not have the answer to how to fix that for everyone, but I do have the answer for that question if you’re using Magic to create your Open Source things. Simply because even though most of Magic’s source code is freely available online, it’s not Open Source – In fact, 5 hours after having put a Magic solution into production, it’ll stop working without a valid license key.

This means that if you create an awesome CRM, or a magical Webmail client on top of Magic, or even a small SSO portal to serve JWT tokens to other developers and apps, and others are choosing to use your stuff – They’ll have to pay me €495 to have it work on their servers.

Realising Rome wasn’t built in neither one day, nor by one man, I’m willing to do revenue sharing for each license sold to anyone needing a license to make 3rd party components and applications work. In fact, I’ll share everything 50/50 with you. This implies that if you create an awesome app or component on top of Magic, and it becomes popular, and somebody wants to use it, and choose to purchase a license from me – Catching! You’re up €200. No needs to rely on PayPal donations. No needs to beg your users for handouts. No needs to chase companies to sponsor your app. Simply create something Free on top of Magic, let others download it, link to your own custom PayPal payment link, tell your users they’re saving €100 when using it – And whenever somebody wants to put your Open Source stuff into production – You magically get paid €200 each time! (Minus PayPal fees)

Not too bad for creating Open Source and Free Software if you ask me

Why should anybody care? Well, Magic allows you to create HTTP Web backend REST APIs in seconds, wrapping your database by simply clicking a button. This means that among other things, you could probably create your entire backend in seconds – Or at least 80% of it. Maybe you’d have to plaster on some 20% of C# code on top of it, to make your backend do everything you want it to do, but I pretty much guarantee you that if your backend requirements includes reading and writing data to and from some database, you’d be able to “magically” create it (at least) 10x as fast. Then you could simply add some frontend on top of your Magic backend, using e.g. Angular, and voila! You have a complete Web application.

It might not be free as in free beer, but it might just provide you with a beer 😀

Contact me on email if you have built something using Magic, and you want to hear more about this.