By Yann Le
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.
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.
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.
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!
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.
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.
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.
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.