By Yann Le Roux Falvey
Startups and smaller companies often run into the same software development trap of developing solutions too quickly in order to sell and generate revenue. However, this approach often means trouble as it can pose significant difficulties in the long run.
Among developers, when something needs to be rushed into production like a fix for an urgent defect, we use the term “quick and dirty”. And it means exactly that. When code is rushed and is not properly checked, reviewed and tested, it can “rot” over time and become unmaintainable very quickly. When a “quick and dirty” fix is deployed, the developers will typically promise to have another look at it later, but because of other priorities, it usually never happens.
In the case of startups, new products are rushed into a production state because they need to generate revenue quickly. The problem is that whatever code makes it to production first will remain for the years to come, even if the quality is substandard.
Startup companies are often characterized by a higher proportion of staff turnover than more mature companies. The higher the turnover of developers, the more likely the code base ends up becoming an inconsistent set of coding styles and approaches. Different technologies can also be introduced without proper agreement, just because one or another developer likes it better. The same issue can arise when the development is outsourced, without any rules being specified or guidance being given as to quality or design.
If the startup is successful enough, after a few years, the development and delivery processes usually become more structured, but by then the code will have become difficult to maintain. And enhancing the code at that stage will require a considerable time and resource investment (that the company may not be able to afford) just to bring it up to scratch. In some cases, products may need a complete rewrite so they can somewhat “be future proofed”.
So how do we address these issues and how can we try to avoid them or at least minimize them?
In order to avoid the issues and traps described above, a few simple steps can be taken very quickly by someone with experience in development and project management (Agile style). A checklist of these steps should be drawn up before any code is deployed.
1) Define a simple development process from day one
Make sure your developers do not have complete freedom when developing your applications. You need a set of rules defining the development process. Those rules should include key points such as coding style and naming conventions, and some level of unit testing and integration testing. The quality of your code is key from day one as it will ensure the code will be future proof. The tests will serve as quality control and they will define a certain level of documentation to explain what your code is supposed to do.
2) Adhere to some level of normalization/standardization in code writing
As mentioned in the point above, you need to set in stone a list of rules regarding coding style and naming conventions. This will allow you to make sure that your code is consistent regardless of who was involved in writing it. It should be easily understood by anybody new coming on board. This point also targets the technologies you are using. Try to avoid multiplying the frameworks, and keep your code simple. A new technology which looks “cool” might be discontinued in a few years and make your code fragile and unmaintainable if not carefully considered before being used.
3) Protect your code and your business logic
When you design and implement an application, you must define requirements and an architecture. The business logic is where the most important part of the system is defined. You must protect it, as this is the heart of the business. The GUI (Graphical User Interface) is always very volatile and changes a lot. The data layer (Database or other source) can also change often. What is in between is the most important part of the system, this is your business logic. Its quality should be proven and tested and the source should be protected and backed up. Source control systems are available to avoid mistakes where a developer’s laptop might crash, and the code disappears. Code should never get lost!
4) Use some tools for quality checks and automated testing
Today, we have a lot of choice of tools to use to check the quality of the code and to automate its building, testing and deployment. Many of those tools are free and offer a lot of functionalities and possibilities. Decide on your SDLC (Software Development Life Cycle) and choose a list of tools fitting your needs for each level of the SDLC. When defined, make sure that all developers comply with the agreed use of the tools. This will make your development process faster, smoother and most effective and again it will give all your developers a consistent approach to software development.
5) Encourage code reviews and peer programming
Code reviews and peer programming are very useful. They allow developers to be familiar with what other developers are doing in their team and elsewhere. It also allows them to be more critical about the code of others so that obvious issues can be detected early. This will also force all developers to be aware of the coding standards, highlighting when others are not complying. Peer programming is very interesting and useful when a developer is stuck on some task and the solution seems to be trivial. I have often experienced the case where I was staring at a piece of code for hours, trying to find a solution to a problem. Then suddenly, someone would look over my shoulder and suggest something new in a few seconds. A second pair of eyes gives a fresh perspective which is usually very useful. When new developers come onboard, code reviews and peer programming should be a key part of their training.
6) When possible, training on clean code is very useful
Clean code is a philosophy which takes time to fully understand and master as a developer. Training on clean code is very useful and it will make your developer’s life easier and their coding styles more consistent and compliant with your standards. As a lot of it includes unit tests and refactoring, it is also important for the quality of the code which is delivered. Test-driven development is also a route you may investigate.
7) Define a simple and clear technology stack
As mentioned above, you need to define and agree on a simple technology stack. Developers can “go wild” on this front as new technologies are always very attractive, but introducing a new technology always has a long-term cost. Pick simple technologies and investigate how difficult they are to upgrade and/or replace in the case you want to be able to change later on. If you create simple small/micro services, do not use big heavy frameworks as they may have a very negative impact on performance. I would recommend looking at technologies which are already around for a while and have proven themselves. This way you will get a lot of support in case you face obstacles when implementing them. Of course, if you are working on POCs (Proof of Concept), the use of new technologies may be advised to prove their use to you.
Always be aware of your “technical debt”, and set up a simple approvals process when introducing new technologies or upgrading/replacing existing ones.
In this article, I tried to explain that when we start developing new products in a rush, we may forget some important steps which will have a negative impact in the long-term. Applications are expensive to develop but they can be even more expensive to maintain and enhance if not implemented in a sensitive and efficient way. By going through a simple and quick definition of principles and rules and enforcing them amongst your developers, you can avoid a lot of problems and mistakes in the future.
Of course, this will not avoid everything, and lessons will still be learned along the way. But you should have the right tools and processes to deal with issues and improve on them when the time comes.
The quality and safety of your code should be your top priority. And given that today there are so many tools out there, available for free, there is no excuse for poor code anymore.