The best line of code is the one you didn’t have to write.
As developers, we love writing code. At the end of the day, it is what we are paid to do. Isn’t it?
Whenever we see an opportunity to write code, we take it and usually bypass the more efficient solution.
Even simple things like parsing a file, instead of using a tested library, we create our own implementation. We might come up with some excuse that the library doesn’t have the feature that we need but in reality we just like coming up with our own solutions.
What most developers fail to realise, is that every line of code you write is a liability.
People get confused between an asset and a liability.
"Most people struggle financially because they do not know the difference between an asset and a liability."
From the book "Rich Dad, Poor Dad" by Robert T. Kiyosaki
For most people, their biggest “assets” are their house and their car. However, just because they cost you the most money, doesn’t make them an asset.
An asset is something that puts money in your pocket. However, a house and a car both cost money, both in terms of bills, such heating and petrol, but also in maintenance costs. They are liabilities disguised as assets.
Your code is also a liability.
Every line of code you write requires more lines of code in the form of unit tests. It requires maintenance over time as more features are added to it. Even though you might put it off, it also requires you to write documentation.
Every line of code also has the potential to produce bugs which will waste your time, your team's time and may even lose the company money and put your customer’s data at risk.
Every line of code you write adds to the complexity of your application. Sometimes we consider this as technical debt. The code was quick to write but adds to the overall complexity and makes maintaining the application a pain.
Some of this can be mitigated by writing better code. Writing code to the rules of the SOLID principle will help.
- Single Responsibility Principle - Your code is only doing one thing, which means less code and no complicated branching logic.
- Open Closed Principle - most bugs occur when making changes to an application. How many times have you added a new feature but inadvertently broken something else?
- Liskov Substitution Principle - derived classes should be compatible with their base classes. This can help avoid unexpected consequences (bugs) in your code and reduce the maintenance needed in the future.
- Interface Segregation Principle - by having smaller interfaces, you aren’t forcing developers to write more code (liabilities) for the methods they aren’t using.
- Dependency Inversion Principle - decoupling modules will help when it comes to fixing bugs, as you are less likely to cause unintended consequences.
You might argue that the code is also an asset, as it produces an outcome that is desired and in some cases produces money as well.
The code however isn’t the asset, the solution is.
As I hinted at the beginning.
Our job as developers isn’t to write code, but to solve problems.
In some cases, the best solution is to not write any code at all.
There are so many no-code solutions coming out that it is getting harder to justify writing a solution from scratch any more.
IFTTT and Zapier can help with some of the simpler integrations between cloud services. The alternative would be to write a “simple” AWS lambda to perform the task.
However, you then not only need to write the code and deploy it, you also need to maintain it. Inevitably, API contracts will change or get deprecated and you will need to make updates which you wouldn’t have needed to do otherwise.
If you are worried about security and need a self-hosted solution there are quite a few available such as:
- n8n - has a great UI and is easy to use.
- huggin - a very popular open-source alternative good for basic scripting.
- beehive - has a lot of ready-made integrations.
- node-red - not the simplest to understand, but very extensible.
I am currently using n8n to republish my blog posts (like this one) to different platforms. It would have taken me a week to write an AWS lambda function attached to an API Gateway for the incoming publish webhook. Instead, I put the whole thing together in a day. It is not completely no-code, I still have some “code nodes” that format the JSON payload for the requests, but it is certainly less code.
No-code tools aren’t just limited to backend solutions, either. There are also tools such as Retool, which can be used to build out complicated UIs in minutes (and can be self-hosted).
Tools like these might not work for customer facing products, but they are great for replacing internal applications, which often require just as much work as the public facing applications but are often neglected by companies.
There is always going to be a need for developers to write custom code, but when thinking of a solution, not writing code might be the best option.
Top comments (0)