Software development has transformed massively in the last decade. We have tons of tools now, which we didn’t have before. Methods have also evolved, things like CI / CD have changed the way we think about software development. There are even things like low-code or no-code systems, which have simplified software development.
But the holy grail of software engineering has still remained building long-lasting software and that is still insanely difficult!
Has Software Development Become Easier Today?
Easier from one perspective, because we now have more tools that have dramatically improved the software development life-cycle. Here is a short curated list of a few tools that have made software development easy (2022):
Design — Figma, Canva, Zeplin
Development — Visual Studio Code, StackBlitz
Communication — Slack, Discord
Project Management — JIRA, Basecamp
Marketing — Salesforce, Hubspot, Hootsuite
Hosting, Deployment & Scaling — AWS, Google Cloud, Azure
From a different perspective, I argue that software development has actually become difficult. I can cite a few reasons. The technology landscape is rapidly and continuously changing. Chances are pretty high that any software that gets developed today, will be obsolete in next two years. So developing something that lasts is really tough. Secondly, the user experience expectations have gone up like anything. Software has already touched the life of every person on the earth by now. With the proliferation of smartphones, everybody is using some or the other high quality software daily, may it be email or a messenger or a social media platform, or even a business related software. User expectations are already on an all time high, hence anything new that gets developed, needs to offer better features and better experience than the previous lot, to get adopted. This is tough! Thirdly, there are some legal hurdles for softwares, which were not there before. Many countries have now passed data protection and privacy laws, which mandate the user data to be handled in a standardised and specific manner. This has complicated software development.
Rules For Developing Long Lasting Software
Based on my experience in software consulting for more than a decade, I have arrived on two golden rules, for building softwares that last. These rules are easy to understand even for a non-techie, definitely not difficult to implement and easy to measure. If one sticks to these rules all throughout the software lifecycle, then yes, even in this big bad ever changing world, your software will still last long!
Rule 1 — Keep The Tech Stack Simple
This is the most important thing! The reason why most cloud softwares evolve themselves into history! It starts with the software architecture. Don’t start with a “highly sophisticated micro-services based architecture, that can serve more than a million users with a maximum response time of under 2 seconds for even stressed traffic conditions” type architecture! You get what I mean? Start simple. Pick one good scalable database, suitable to your business case, with a clean and simple database schema. Don’t introduce complexity unnecessarily. Follow the “build only when needed” principle. Then pick one API framework. Just one. Avoid using multiple API frameworks for multiple use-cases. Lastly, pick one frontend framework and that’s it! If you are developing mobile applications, go for cross-platform front-end frameworks. They have become really good and users feel no perceptible difference when compared with native frameworks.
Server-less technologies offered by AWS and Google are also a good option in my opinion, particularly for web applications, because they completely obviate the API layer.
For example, for a web + mobile app requirement, such as an e-commerce app, following could be some good options:
(1) PostgreSQL (DB)+ NodeJS (api) + React (web) + ReactNative (mobile)
(2) MongoDB (DB) + NodeJS (api) + React (web) + ReactNative (mobile)
(3) PostgreSQL / MongoDB (DB) + NodeJS (api) + React / Angular / Vue (web) + Shell app (mobile)
(4) DynamoDB / Firestore (DB) + React / Angular (web) + Shell app (mobile)
Why Simplicity?
In one line — Keeping things simple will allow you to build good quality software with a smaller team.
A smaller and more effective team will reduce your overheads. You team will survive longer and so shall your software.
Simplicity also means, you’ll be able to take decisions faster and move quicker. You won’t introduce complexity right at the start of the project. You would start minimal, build only what is required and introduce complexity on your way up, in a way where the complexity has already evolved into a fairly defined need or requirement and is naturally fitting in to your scheme of things!
Rule 2 — Insist On 100 Percent Code Coverage In Unit Tests
This rule might seem a little unusual, but allow me to elaborate. I start with with a well established fact.
Most softwares don’t last long because the code quality degrades over time. Particularly as the project passes hands, or even passes teams.
Often, new developers don’t refactor the code properly, when they work on code written by somebody else. Mainly because, they lack an insight into the thought process of the original developer. Over time, the software becomes buggy. Performance degrades as code optimizations are forgotten or lost over time. Eventually resulting in disastrous consequences.
What is the solution to this problem then? Solution is to create safety nets around the code to prevent unwarranted code changes.
Unit tests can be thought of as safety nets around the code. To prevent unwarranted code changes that have the potential to degrade code quality. While writing code, the developer can identify critical pieces of code and create fences around them with comprehensive unit tests. This is, essentially a structured method to educate the subsequent developers about what pieces of code are crucial. Basically, hey you new developer, don’t mess with this piece of code, unless you are able to pass all these tests!
Why insist on 100 percent code coverage? Just to ensure that every line of code has at least one safety fence around it!
I consider the following three as attributes of good quality code:
- Separations of concerns
- State management & balance between component-level and global state
- Clear separation between business and UI logic
Insisting on 100 percent code coverage will ensure that code quality remains good. This will compel your developers to write code that is nicely structured. As new features get added or bugs get fixed, the developers will have to regularly do refactoring. Because good code coverage cannot be achieved in badly written code, especially as lines of code increase.
To summarise, the secret sauce to building long lasting software is just two rules — keep the tech stack simple and insist on 100 percent code coverage in unit tests, as the software journeys ahead.
About the author:
Hrushi M is an entrepreneur by profession and software engineer by training. He has the experience of bootstrapping a software consulting company and leading as its CEO for more than a decade. He is currently the developer and maintainer of superflows.dev, a framework for developing cloud-based server-less applications.
