Your Code Is A Liability
Every chunk of code you commit is more for someone else to read, digest and understand.
Every complex “clever” expression requires another few minutes of effort for each of your team. They must now interpret what you wrote and why you wrote it.
Every line you add limits your project’s responsiveness to change.
Your code is a liability. Never forget this.
The features are the asset
We need code: it’s a major way we deliver features. The feature is the reason we write the code in the first place.1
The only way to value features is through the code we write to create them. CFOs treat code an as asset, because it is the material connection they have to the feature provided and the business value behind it. It is not the code itself that has value. Counter-intuitively, the more code needed to deliver the value, the less valuable the asset.
If you are working at a a startup, much of your company will not survive contact with customers. The quicker you find out what to remove the better. If you build a whole framework to serve a feature, and it is not needed, you are less likely to delete the feature when it proves superfluous. How much code does your feature really need? What iss the simplest smallest version of the feature in front of you that you can learn from?
Thinking of code as a liability puts AI into perspective. It is possible to churn out code using language models and it may have some value. Who decides whether it is providing the feature? We need strong developers to determine this.
Code is a liability, but coders are a clear asset.
Do not compromise on quality
Developers: do not skip the tests for critical code.
I write tests for self contained code that is beyond my ability to understand at a glance. That limit is always lower that I think. As Dave Astels said: “Test where the risk is.”
I do not write tests for how the code is arranged when I am figuring out the feature.
I rarely test UI directly. UI tests take too long to run and the maintenance is almost never worth it.
Write code in conversation
If you have a team to talk to, try this: rather than diving in to coding your next feature, have a discussion.
Talk about different ways to achieve the same thing. Argue about the architecture and the arrangement of the different concepts you’re planning. Write down a spec of the work you are attemping and have the team critique it.
Zone in on the simplest and lightest code structure you can find. Solutions developed with others will always be better than us implementing our own ideas in isolation at a ridiculous rate.
The simplest form of code in conversation is is pairing. Every line of code we write when pairing is scrutinised by our partner. If it doesn’t make sense, or shouldn’t be there, they can let us know straight away.
Remove code wherever possible
The best pull requests are the ones that remove more code than they add.
If we spot a duplicated concept or idea, it often makes sense to remove it there and then. I normally do this as a standalone change, so that it’s obvious that the change has nothing to do with what I’m working on.
This is not “Don’t repeat yourself”. Often code is removed too early, before you know what the abstraction is. Solve the problem in front of you.
Don’t write any code at all
Can we solve this problem with a high quality library, or API? Are we able to reconfigure an existing module to make it do what we need? Can we buy in a solution that is good enough for what our business requires?
Avoiding writing code at all is especially important when we’re navigating a new complex idea. Plenty of times we’re not exactly sure how the feature we’re working on will evolve yet. The fewer lines of code we write, the better chance we have of changing the feature later into what we discover it actually needs to do.
When we embrace that our code is a liability, everything becomes lighter. Our functionality is set free from heavyweight code drag. It allows our features to soar, responsive to change requests, and easily debugged. There is just not that much code to go through.
Thanks to Matt Barcomb for feedback on earlier drafts of this article.
-
Except when the feature is not the reason we wrote the code. The allure of a “proper” architecture is real. Fight it. Force every part of your code to directly contribute value now. ↩
Share this article
Read more
The Job Is Not To Build
Startup CTOs or founding developers are the first technical people in the business. It is natural to think your job is to write code and build software. This is backwards.
Your first job is not to build software. Your role is to use your technical expertise to help the startup figure out fast if you have a valid solution to a compelling problem, and then a valid product for a big enough market.
You might do this through building software, but you might not need to.
Here is a story of how I did this wrong, and how you can do it right.
Read moreThe First Thing A Startup CTO Must Do
Perhaps you are a technical co-founder who has managed to raise funding and you have been catapulted into the startup life. Perhaps you have just been brought in to handle the startup’s tech after the first round came in.
As the CTO, or the most senior technology person in the company, there are so many calls on your attention at this stage.
There is plenty of interesting new tech to build. There are potential customers to speak to (hopefully). There are investors to keep updated, who will want to know when the company is going to grow. There are people to hire. It can feel like you are drowning in possibility.
In the midst of all of that, we neglect this one thing at our peril.
Read more