The ultraconservative developer
Why your codebase is your biggest fear?
In this article, we’re going to talk about a phenomenon I encounter more and more often during my freelance jobs:
Developers who are averse to change
This is a real issue that can dramatically impact the competitiveness of your product.
To give you few examples:
1- some applications are still running in a very old version of a framework.
2- the codebase architecture is rigid and based on old IT concepts (SOAP vs REST, etc..). In other words, an archaic system.
You got the point.. So let’s try to analyse why these ways of thinking don’t fit to the era of modern app development.
Why a developer becomes ultraconservative?
The answer is very simple: the school..
Indeed, that’s the big difference between a developer with a classic university background and a self-taught developer.
I have a master degree in computer science. So I know what my professors taught me:
- safety first
- rigid but strong systems
- Guard clause everywhere
- Anticipate problems
- blah blah..
While these assertions are based on important theories (a code should never segfault, a system must be idempotent, etc..), in the reality of the startup world, all these concepts become almost irrelevant (depending on the context).
Let’s have a look to 2 examples to determine whether is good or bad to be averse to changes.
Bank of Konoha
In the hidden village of Konoha, the Bank of Konoha is the oldest bank still in place.
This bank treats millions of daily transactions.
In this case, their system must be safe (strong security policy). The system is archaic because it was created on a rigid architecture years ago. This approach had the merit to ensure a quick response time with a very low errors rate.
So what our teachers taught us works pretty well for this kind of context.
But what about a startup?
ramen-express.com
Disclaimer: if your startup is an online bank, then use the above rules as pillars for your application. Rigidity is a good thing in this case.
This said, our startup operates in the food delivery industry.
It’s a website that allows you to order and receive the best ramens in less than 20 minutes.
That’s the value proposition. But how to know if potential users are interested?
The only way is to materialise this idea and put the result in users hands.
To do so, you create a website with 3 kinds of ramen.
This is the minimum viable product.
At this step, you don’t know what will be your final product.
So, over-engineering and anticipating potential issues is a waste of time as the core of your project can change pretty easily because of the uncertainty of your business model.
After a while, you finally met your clients and you start to get traction. You decide to enhance the test coverage, handle few bugs and side effects.
After few years, of development, you passed from 1 to 20 developers.
Some developers left the company.
This year, with your board you have the ambition to add the possibility to group order.
This functionality could add a real value to your business.
The problem is that you and your team aren’t comfortable with the idea of touching the core of the application. And delivering this feature in 3 months.
The existing system is rigid and adding this feature could threaten the stability of the entire app.
Blah, blah..
What’s wrong here?
If you decide to be a developer in the context of a startup, you MUST understand that you work for a business and for your clients.
And if the person in charge of the product thinks that this feature for this date is a very great added-value to the product then you should try your best to make it happen.
Also, if the plan slightly changes in middle of the development, you should be a bit flexible to take these changes in consideration.
This said, what makes you so averse and why are you on your guard?
- You don’t master the code
- You can’t identify the impact of the changes
- You not backed by a good test coverage
These are mainly the 3 issues that I encountered during my freelancing missions.
Note: feel free to let us know in the comment section if you identified another potential issue.
How to fix this?
There are no miracle solutions..
You’ll need to read, understand and document the legacy code.
Also, write a consistent test suite and ask you the following question when your tests are done:
Do these tests make me comfortable to modify this code in few months?
If the answer is yes, then you tests are relevant.
Also, producing a consistent documentation (comments, docs, etc..) is an important part of the code review.
These processes take time to be assimilated by the team. But once it’s done, all the team will be more comfortable to enhance and modify the existing codebase.
Also, you’ll create a real tech culture in your team by raising their standards.
Finally, every member of the team will be able to comfortably intervene on the project.
Conclusion
In the context of a startup, you need to put your product in the hands of the potential clients ASAP. This involve that you codebase won’t be the best.
But as you’re trying to understand your target and you’re not certain about what’ll be your product, you can’t over-engineer and waste your time with processes.
But once your product meets its audience, then take the time to rewrite or enhance the few thousands LOC that you’ve already written.
Then, become more disciplined on processes that can maintain your code flexible and build the confidence to modify it safely.
Voilà!
RubyCademy is now available on Youtube! ▶️ 🚀 🤩 💎
We publish short videos (maximum 5 minutes) that talk about technical notions, quick wins and tools (..and a couple of geek stuffs 😅).
Feel free to click on the image below to access our Youtube channel
