There is no shame in asking for help

I don’t cut my own hair. Neither do I build my own cars. Instead I pay for these services with money I earn doing my job, which is software architecture and development. This creates a symbiotic relationship, where I can do what I am best at, and everybody else can do what they are best at – Win win!

Unless your core value as a company is to create software, creating your own software is like having your hair dresser building his own car. Everybody can see the madness in this analogy (puuh!), but few can see the madness in having some Acme, Inc. Financial or Medical company building their own software for some weird reasons. If your core business model is insurance, chances are you’re probably not going to be able to take software development seriously – And you shouldn’t either in fact. You should hire somebody else to take it seriously on your behalf. Somebody that has already taken it seriously for decades. Doing things with your “left hand” results in “left hand results”. For a company where software development is a secondary function, software will always be created with “the left hand”. Since your business depends upon software, the same way you depend upon your car, this results in weird situations, where you are no longer able to sustain your company’s operations, because you have built your company on top of “left hand products”.

There is no shame in asking for help

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.

The “precious” legacy codebase

You don’t have to be destroyed as your codebase nears the end of its life

Most managers have an unrealistic idea of the value of their own codebase. This is a natural consequence of having maintained the code possibly for as long as a decade. “If 10 people spent 10 years creating the stuff, obviously it must be worth a lot, right?” I am here to tell you that such conclusions are fundamentally wrong. In fact, the more developers have maintained your codebase, and the longer you have maintained it, the less your codebase is worth! The reasons are obvious for anyone having experiences from software development spanning more than a handful of projects; Spaghetti!

The more people touching your codebase, the less consistent it becomes, and the more difficult it becomes to maintain. And the more difficult it becomes to maintain, the more bloat it automatically gets. The more bloat your code gets, the more difficult it becomes to maintain, and so on. This becomes a vicious cycle, where the codebase quality spirals downwards, to the point where its value becomes net negative.

If you don’t believe me, look at your own codebase. My guess is it contains dozens of libraries that are no longer actively maintained, or that used to be “best practices” a decade ago. jQuery, Durandal or .Net Framework for that matter? If your codebase contains any of these elements within, it’s destined for the scrapyard. Sorry for giving you a painful message here, but it’s the sad truth. Code doesn’t have value, in fact it has no value at all. Code has never had value, and it will never get value either. What has value, is your software suite’s ability to solve problems. As time passes, your codebase ability to solve problems becomes less and less, du to legacy code, bloated repositories, and obsolete libraries, to the point where it can no longer sustain its life. As it does, it is crucial that your codebase “spins of a child” (new codebase) to continue your ability to keep solving the problems your original code was architected to solve in the first place.

Facts are, code has a lifespan, just like animals and humans do. And when your codebase reaches the end of its lifespan, you can either accept it, throw it away, and do the big rewrite – Or you can choose to sink to the bottom with it, like the Captain of the Titanic. Everyone in the software industry having more than a decade of experience with creating software can easily echo my experiences here. Whether they have the courage to actually tell you though, is a different story. Don’t hire “yes people”, hire people that will guide you to the truth – Even when the truth is painful. This was the recipe followed by literally all great entrepreneurs, ranging from Bill Gates to Henry Ford. If you’re a manager and your company is maintaining a mountain of garbage, do me a favour. Go to the bathroom and tell yourself the following.

My code is garbage. I know this, and I must do something about it.

Accepting the truth, is the first step to recovery!

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