The Zen of Source Code
This is the first article in a series where I discuss key software concepts that a non-tech manager should know. Next articles will focus on deliverables, technical debt, MVP, the role of a CTO.
Source code is nothing. Source code is everything. Source code is worth nothing. Source code is worth… well, something.
Source code is the stuff developers produce every day, all day long. If you look over a dev’s shoulder, you might see things that makes no sense to you, but you might recognize a few quasi-english words here and there: if... else..., foreach, class, function, etc. That’s source code.
Source code is irrelevant
As a non-tech manager, it’s very easy for you to ignore source code, and in fact there are many reasons why you should.
It’s meaningless gobbledygook to you. You can’t contribute anything of value by looking at it. In fact, you may break it if you touch it.
Your users care even less than you about it. In fact, they will never even see it. Users care about what they can do with your software product that is either useful or fun, in other words, functionality.
It is not a valuable criteria to evaluate your developers’ performance (at least its quantity; quality is a slightly different matter — see below). You don’t hire developers to write lines of code, but to produce functionality (ie what users care about). Developers should primarily be evaluated on their ability to produce features that add measurable value to your users.
Source code is not a barrier to entry. You may think you’ve done something extraordinary, but to a developer your source code is likely to be fairly bread-and-butter. If you have truly innovated, then apply for a patent; but then the patent is the barrier to entry, and then only once approved. Also, however much time and money you spent, assume a competitor can do the same in 2/3 or half the time. Maybe less if they have deep pockets and can assign a decent budget to it.
Source code is not even software. Software is the stuff that runs on your servers, or on your users computers and phones. Software is the result of a more or less complex process (generally called “build”), of which the source code is the raw material. This process may include compilation, obfuscation, compression, packaging, etc.
Source code is precious
Despite all this, your source code is precious. First, there is no software without source code. Source code may be the raw material of software, but it’s pretty much irreplaceable. (Yes, “no code” and “low code” solutions are emerging, but they are still a long way from fulfulling all your software development needs).
Even to modify the software, developers need to modify the source code (some exceptions may apply through the use of configuration settings which may be changed outside of the source code, but that is limited).
The quality of your source code is directly responsible for the performance of your software: whether it is sluggish of fast; bug-ridden or bug-free; easy to maintain or not; whether it is easy to onboard a new developer in the team and how long it will take before she is productive; whether the software is easily extensible, and new features can be added fast.
More crucially, whether your MVP is scalable. There is nothing worse than not being able to follow through on a successful launch because the software cannot scale appropriately (contrary to what you might think, it is not a nice problem to have).
The reverse is also true. An over-engineered source code — correction: an unnecessarily over-engineered code — will drain your cash and waste valuable time to market.
Source code is an asset
Your source code is an asset. In fact, it’s likely to be the only asset your startup has. Transfer of IP in software refers mainly to ownership of the source code.
To protect it, you first need to ensure you have all IP rights to it. Check the employment contract for your in-house developers; check the service agreement with any outside provider. Outside providers may impose a reserve clause where IP rights vest only upon full payment of their invoices. Avoid this if you can; offer to pay in advance. I recommend monthly payments to reduce risk on both sides. But in any case, the risk of losing a deposit is nothing compared to the risk of scaring investors away because of a dispute over IP rights with a third party.
Possession being nine tenths of the law, you should own your source code. Source code is stored in specialized servers called Version Control Systems(VCS). There are 3 main providers who offer this as a service, and it’s free: github, bitbucket, and gitlab. Open an account in the name of the company, and invite your developers to join.
The first question I ask when doing a tech audit is “Where is your source code?” Surprisingly, 90% of startup founders either cannot answer this question, or give the wrong answer (eg “on our dev’s laptop”). The correct answer to this question is one of github, gitlab or bitbucket.
You must also demand from your developers that the source code they write each day is saved to your VCS account at the end of the day at the latest. Source code that exists only on a developer’s computer has zero value, and you should refuse to pay for it. It also defeats the purpose of storing your source code on your own VCS account, and prevents collaboration beetween devs. You want all your source code as soon as possible on your account.
Source code has zero intrinsic value
Unfortunately, as an asset, source code has an intrinsic value of zero. In some countries, like France, accounting rules create a strong incentive to capitalize source code at cost (salaries or outsourcing fees). Do it if you have to, but don’t believe that number. Most investors will recalculate your balance sheet anyway and take it out.
The true value of your source code is its replacement value
On the other hand, source code is like your old car, which has no market value, but would cost you some serious money to replace if it broke down. If you had to rewrite your source code from scratch, it would cost you a significant amount (it always costs less than the first time round, but still).
This is not an outlandish scenario, by the way. It happens far too frequently that source code is held hostage by a software shop wanting to be paid before they release it, sometoimes asking for far more than was originally agreed. In most cases, this is a death sentence to the startup.
