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!

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

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 not invented here syndrom and technical debt

Probably the single largest source for unnecessary technical debt is the “not invented here syndrom”. The not invented here syndrome is a humorous way to explain a system development problem, which is the natural resistance many developers have towards using 3rd party tools, and would rather reinvent the “wheel” themselves when confronted with a problem requiring “wheels”.

Once you realise that code actually is technical debt, you also understand that you want to minimise your amount of code, to increase your future flexibility, and free up resources in your development department. The simplest way to achieve this is actually to use third party libraries and components. Either Open Source components, or proprietary components. From a technical debt point of view, it doesn’t matter if your component is open source or not – Since every single line of code you can avoid creating yourself, becomes one line of code less you need to maintain in the future. Ask yourself the following question.

What is most expensive; Having a developer spend six months coding, or purchasing a 3rd party tool for €500?

Then realise that even if the developer succeeds, he creates technical debt for you, that you’ll have to maintain in the future. Purchasing a component from a 3rd party, implies that the 3rd party will (probably) give you new versions, and bug fixes in the future, included in their price.

There is a reason why we don’t create our own cars, and that reason is because huge car manufacturers are able to optimise the process of creating a car, to the extent that their product is better, less expensive, and more secure than whatever we could have built ourselves home in our garage. The same is true for all fields that require specialisation of some sort. No company can master all fields required to assemble their entire product – In fact, not even a car manufacturer. Most car manufacturers will purchase a whole range of the components that makes up the final product from 3rd parties. This is a large reason of why they are more efficient at assembling cars than we are ourselves.

Whenever your software development department has a problem, the first question should always be; Have somebody else already solved this problem in an adequate way? If the answer to that question is yes, you can significantly reduce your technical debt by somehow obtaining these pre-existing components instead of reinventing the wheel within your own organisation.

Giving away your technical debt

This might be perceived as counter-intuitive for many managers, but sometimes you can actually save money by giving away parts of your product for free as Open Source.

As I discussed in my previous article about technical debt, you should always keep what is of strategical importance for you and your company a closely guarded secret. For instance, if your business is automated trading, based upon artificial intelligence and deep learning, you’d probably want to keep your algorithms and trading robots a highly proprietary piece of code, and lock it into your safe as you leave your office for the night. However, most companies tends to also create a whole range of additional software solutions that are not of strategical importance to the company, mostly out of necessity. Our example with trading robots for instance, could include the necessity to communicate with 3 different financial database systems simultaneously – Examples here are MT4, the FIX protocol and CTrader, for then to aggregate data from all these different systems together somehow, as input to your trading robots. If such components does not exist from before, the trading company becomes forced into creating such systems, out of necessity. Hence, creating parts of your software, becomes a necessary evil, you must do, in order to facilitate for your strategic advantage.

In the above example, the database adapter has zero strategic advantage for the trading company, but is still something that must be done, because no off the shelf components exists that does this from before. Hence, a database adapter becomes a necessary requirement to make the trading robots function. The problem is that this increases the amount of proprietary code the organisation is dependent upon to function adequately. Hence, it adds to your organisation’s “technical debt”, without really contributing much, besides being a necessary stepping stone, on the way to reaching your strategic advantage.

If you however publicly release your database adapter as Open Source after initially having created it, chances are that others will recognize its beauty, and start using it. As they do, they might find errors in it, and might come up with good ideas for improving it. In addition, they might also fix these errors, improve upon your system, and send these improvements back to you as “patches”. Congratulations, you have now shared your debt, and you no longer need to carry (alone) that which you shouldn’t have carried alone in the first place anyway.

At this point, your organisation have given away zero of its unique advantage or its proprietary secrets, while at the same time is sharing the burden of maintaining crucial components with a whole range of other companies. So even though this is easily perceived as giving away something for free, what you are ipso facto giving away, is actually debt – Nothing more.

In fact, I would argue that all “non-crucial strategical components” within a company should be shared across multiple organisations this way, since we happen to know for a fact, due to game theory, that such strategies results in literally creating value out of thin air, since this is not a zero sum game. What I mean by that, is that the value you gain by giving away that which has no strategical value for your organisation, becomes more than the sum if its participants’ contributions to the system. To speak in laymen terms, one might imagine a world where the rules of math literally dictates that “2+2=5”.

To understand why, imagine a world where every single individual had to build their own roads. No public roads existed, and nobody were allows to use roads built by others. This humorous description is paradoxically a very accurate description of the state of software development today. It doesn’t take a rocket scientist to understand that this would be a highly impractical world. Non-strategic software for your organisation holds the same value for you as roads do in this “parallel world”. Allowing others to use your roads, makes little or no change to your ability to move on these same roads, to sell your services and goods, whatever they may be. While at the same time the burden to maintain these roads, keeping them clean, and fix potholes in these roads over time, can be shared among the rest of society. Facts are, a large portion of your software portfolio today is probably infrastructure software, having little or no strategical value to your company per se, and could easily be “given away for free”, without you actually loosing anything – Except debt of course.

In fact, any financial scientist can tell you the exact same thing, since according to the rule of finance, value is created literally out of thin air, as a transaction between two people occurs – Since afterwards, they both feel happier than what they felt like before, and they have both been given something they want more than whatever they had to give away to acquire that which they were given.

So the ability to create value out of thin air, by giving away something you don’t want (debt), and share it with the rest of the world, is not something new in fact – It’s as old as the idea of trading is in fact. It’s just not commonly applied to the creation of software. In case you doubt it’s impossible to create things out of thin air, then do the following …

Ask an expert in fractional reserve banking if value can be “magically” created out of nothing …

Then realise, this isn’t anything new – We’ve done this for thousands of years in fact. It only implies applying the principles of game theory and finance to the subject of software development …

Strategies for reducing technical debt

This is my third article about technical debt. You can find my previous two articles here and here. In this one I will focus on how you can reduce technical debt as a middle manager or upper manager in an organisation.

Obviously, reducing technical debt to zero is easy, by simply making sure you don’t have any proprietary code at all in your company. If KLOC is the ability to quantify technical debt, then zero KLOC obviously equals zero technical debt. This however also eliminates your company’s edge and uniqueness, and makes it impossible for your organisation to stand out from the rest of the crowd, since everything you build your company from is “off the shelf components”, making it easy for other companies to copy whatever your company is doing – And if your company is successful, others will copy your strategy.

The best historical example of this is how IBM used exclusively “off the shelf components” to build their PC in the early 1980s. Which resulted in that Compaq and other computer vendors could easily copy their product, and such take market shares from IBM. Today IBM barely have market shares at all in the PC industry because of this decision. This is considered one of the classical historical strategical failures in the history of computing today. So obviously, keeping some parts proprietary as “your own” technology, is key here.

Identify your strategy

The first thing you need to do in order to balance this, is to identify your strategy. Your strategy should be summed up with a simple sentence, easily understood by all members of your organisation. I currently work in ForEx, and a good example here might be illustrated with some insights into how my industry works.

In ForEx trading, 80% of revenue is acquired indirectly through “Introducing Brokers”. These are key movers and shakers, often with a massive social profile, with thousands of followers. Making an IB evangelise your trading company, might sometimes result in thousands of traders willing to use your services. Hence if a ForEx company’s vision is to “be the preferred broker for ForEx traders”, a good example of a sound strategy might be as follows.

Provide superior tools for Introducing Brokers

Simply since you realise that if you can convince introducing brokers (IBs), you don’t need to convince your end customer (traders). The IB will effectively make the decision on behalf of his clients.

At this point you know what you don’t need to create yourself. For instance, superior tools for IBs does not require you to create your own CRM. Hence, you can use off the shelf components for your CRM. You can also use third party components while building your software, such as database adapters, other libraries and frameworks, that allows your developers to more effectively do their job.

However, the one thing you really want to build yourself, is the “partner management system”. This is the system your IBs are using on a daily basis to do their jobs, check their profits, and create sign-on links for their clients again. This system is arguably the only system in this example you’d want to create yourself, while everything else are things you could easily use pre-fabricated components and tools to accomplish. This allows you to focus all your energy into creating one staggeringly good system, while buying or obtaining everything else in “the market” somehow – Either by using Open Source components (Sugar CRM), or by purchasing services and libraries from other 3rd party vendors somehow.

In my next blog I will look at additional strategies for “outsourcing” the creation and maintenance of components and supporting tools, by leveraging Open Source as an asset in your organisation. But for now, let this article sink in, and try to identify your company’s main strategy, which is never the same as your company’s vision, but rather an “activity” that facilitates for your company’s ability to reach its vision.