Time is money, money is value
Okay, I’ll admit that calling your software worthless was a shameless clickbait tactic. However, I will assert that it’s not as valuable or indispensable as you might think it is. You need two things to solve a problem using software, skill and time.
Skill. Of course, you can create code using unskilled practitioners. The code might even work, but that’s not the same thing as solving the problem. Bad code is an issue in itself, so even if you solve your original problem, you now have a new, possibly bigger one to deal with. Skill is essential if you’re going to succeed and talent doesn’t come cheap.
Time. Coding can happen quickly, but solving problems is tricky. It takes time, and time is money. A software development team is not cheap to run, so any decent piece of software is going to incur significant cost. If you’re going to put investment into your solution, you should expect it to be worth something when you’re done.
So, why am I suggesting that the code is worthless? If it solves the problem, it’s delivering value. Worthless seems a bit harsh. It’s true that I’m exaggerating, but not by much. To understand, let’s take another look at that solution, and the time that went into it. It’s easy to focus on the software and ignore what surrounds it.
How to bake a cake
Firstly, there’s the team. You have to find the right, skilled, people, and bring them together. Then, they have to establish clear roles and responsibilities and learn to work together as a cohesive team. Finally that team has to establish relationships with the stakeholders and users, and familiarise themselves with the problem space.
This takes time.
Secondly, there’s the business logic. Even the simplest of solutions has to perform some sort of business processing. Someone has to work out what that logic needs to be and codify it.
This takes time.
Thirdly, there’s the design. If the code is user facing, it delivers an experience to the user. That experience is (hopefully) developed over time through careful design, feedback and iteration.
This takes time.
And finally, there’s the code. That also takes time, but that time is small in comparison to all the others. Sometimes it feels as if all the effort is going into the code and the other parts are incidental. However, the reality is that very little of the productive time ends up as code in the live solution.
Some of the code will be replaced by alternatives as part of the iterative feedback approach. Some of the code will remain, but will no longer be used as a result of changes to the design. Some of the code will have been written in anticipation of a situation that never arises.
The developer’s answer to all of this is “refactoring”. For those of you who don’t code, refactoring is the process of reviewing existing code and making a range of improvements whilst retaining the core functionality.
This takes time.
Knowledge is power
When you add all the time together, you get the cost of your software solution, and you could argue that this represents the value of the code. You might even argue that the value of the code exceeds the cost.
This is where I disagree. My opinion is that in doing this you are conflating the codebase and the solution. All the value is stored up in the team, the logic and the design, and very little of it is in the code itself. Originally this view was just a hypothesis without any form of proof, but over time I’ve had the opportunity to run experiments to test this hypothesis.
One particular experiment involved a web portal I was involved in developing as part of an all remote team back just before the turn of the millennium. Smartphones didn’t exist, and the internet was still a fairly new concept to many people. The portal was for a growing internet service provider.
The work took a team of just 7 people 6 months to develop and the result was a cross platform solution that could deliver content, email, calendering and messaging. It was ahead of its time, and also supported voice interaction via mobile phone and delivery of content via WAP. What’s WAP? Google it – the days before smartphones were far from sophisticated when it comes to mobile access to the internet.
The result was good enough to be bought up by a large organisation as their portal solution. That company had already spent longer than 6 months with a significantly larger team trying to create the same thing without success. We were rightly proud of what we’d achieved in such a short time and with such a small team.
So, my experiment related to something that was already considered very efficient in code development terms.
We can rebuild it!
What I did was spend a couple of weeks at home recreating the solution from scratch. The code now belonged to a third party so I wanted a completely new version I could call my own. I used nothing from the original apart from my own knowledge of the problem and my experience solving it. The code repository was no longer accessible, so I couldn’t copy anything from it, even if I’d wanted to. To do so would have also been unethical as it didn’t belong to me. So, every line of code was genuinely built from scratch.
Within two weeks I had a fully working solution that did everything the original did (and a bit more). I’d achieved this in no time at all, and I’d generated a fraction of the code compared to the original solution.
How did I achieve this? Was I some kind of coding genius? Obviously not. I was a very competent coder, very much at the top of my game, but I was just one coder. No matter how good you are, there’s a limit to how fast you can type.
No. I achieved this because the code contained very little of the real value. That was all stored in my head. The design was in my head, and with hindsight I could see all its flaws. I was therefore able to create a much more efficient and effective design based on that learning. All the mistakes had been made, so I was able to get this version of the code right the first time. Most of my tests ran successfully, and debugging time was almost non-existent.
I now knew what wasn’t needed. All those things we’d built in to cater for anticipated needs could now be whittled down to the few that really proved useful. I understood every piece of technology, every protocol and every library, so there was no learning curve.
Mostly worthless
From this, I can conclude that of the 6 months of time spent by 7 people creating this solution, hardly any of it related to the code. It could be completely discarded and rebuilt by one person in under two weeks. What’s more, it could be radically improved at the same time.
So, this is why I assert that your code is worthless when compared to the overall effort invested in the creation of your solution. And I’d go further than that. I’d suggest that, contrary to what intuition might tell you, refactoring might be better achieved by throwing the code away and starting again.
It’s a scary thought. You might even consider it ridiculously farfetched. I wouldn’t expect you to agree with me based on a blog post. However, what I would recommend is that you give it some serious thought, and maybe conduct a similar experiment of your own. If you do, let me know how you get on. I’d be genuinely interested to find out.
Maybe I’m special? Maybe I’m the mythical ten times developer? Personally, I doubt it very much. After all, I was one of the people who took six months to build it the first time round.
Oh, and remember this next time you have to fix someone else’s code. It’s easy to feel superior and knowledgeable. It’s tempting to laugh at the obvious mistakes made by those who came before, but you have the advantage of hindsight. Maybe consider instead that you might be standing on the shoulders of those who carved out the first path for you to follow.
