Whether you have a CTO or you don’t have one, this article is for you if you want to obtain more control over technology. Since technology is clearly the core of a technology startup :)

Yet another client came to our technology consultancy division to fix their bad codebase.

Written by several teams in the past, with different code styles and approaches, or rather lack of an approach towards architecture and scalability, her code was total crap, and we were very straightforward about it.

She didn’t have her CTO, and she came to us relying not only on execution of her technology business but also for acting as a strategic advisor on technology. To be her external CTO in a way.

Definition of a bad code

Bad code like this is not a problem. Say you’ve got a product that does what it’s supposed to do, and you don’t need to touch or modify it. Great! Just don’t touch it.

Bad code only worries us if:

1. The code is supposed to be touched now or in the future.
2. Its quality creates bugs in the product, and thus you have to touch the code to fix bugs.

It is impossible to talk about the matter without introducing the notion of technical debt.

Technical Debt

Wikipedia article defines it this way:

Technical debt (also known as design debt[1] or code debt) is a metaphor referring to the eventual consequences of any system design, software architecture or software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete or proper. If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on. Unaddressed technical debt increases software entropy. Also known as a feature gap.

The topic is quite versatile. For example Uncle Bob separates notions of tech debt and code mess.

I tend to agree with Martin Fowler though who basically merges major categories of flaws into a notion of technical debt, and introduces a quadrant based on two dichotomies: reckless vs. prudent and deliberate vs. inadvertent.

Thus, technical debt can’t be entirely under our mind’s control because some of it happens due to ignorance, and some of it can be actually defined as a debt only from a future perspective.

How you determine if the code is bad?

1. Your developers keep telling you something. The easiest way to determine if your code is bad is to really listen to what your developers are trying to tell you. It is the usual way of things that their voice is very much muted under the pressures of new milestones with hard deadlines.
2. Your developers are silent. Well, it’s also a bad sign if your developers haven’t mentioned anything like refactoring, code review, technical debt etc.
3. New features take more and more time. I’ve seen dozens and dozens of tech startups run into a situation where their code is just so bad that any additional feature development takes enormous amounts of time and leads to regression bugs which killed their user’s experience and made their produce impossible to use.
4. Slow run time. Your app runs slow and getting a more powerful server doesn’t help much.

Examples of really bad code

Forgive me for being too extreme, but bad code usually comes from outsourcing companies located in the developing and not yet developed economies.

Oftentimes you don’t know what you are buying, and while you think you got a great deal with low hourly rates, you end up paying more of your money and with more of your time. I’ve been on both sides of the table and I’ll write a separate crushing article about it later.

Some examples I’ve seen (PHP)…

1. Some database table names with upper case letters and some with lower case. Worked well on someone’s Windows driven computer, but apparently failed to work on any POSIX system.
2. All web app MVC controllers are gathered in a single file. Long controller methods with no separation of code into auxiliary methods or helpers.
3. A mix of HTML and back-end code with nearly no OOP.
4. No use of code version control systems. It’s scary to realize this still happens nowadays!
5. Task tracking in a spreadsheet with no collaborative project management software.

How could you have preserved code from becoming bad?

Key suggestions one can take into account to avoid bad code are:

1. Documentation. Documenting your process helps you think through all the details of the system, as well as identify the repeating parts of the system and its patterns, find meta-patterns and conceptualize better a project architecture that is abstract enough to still maintain good extensibility. Think roadmaps, sets of job stories, information architecture documents, technical architecture documents, technical specs, brand books and style guides, code guides, test cases documentation, release notes templates and many more.
2. Seniority on the project. You need to have enough senior developers on the project. They should use technologies they are familiar with. Having a senior developer who had a great experience with JavaScript and reactJS, but that now decides to use angular means they have a learning curve to go through and this creates a risk for wrong architecture which you cannot let happen.
3. Discovery and engagement sessions. No matter how good your documentation is — developers have to read it carefully. It is best of all to discuss documents with you and make sure they understand every bit of it. Oftentimes, developers are able to come up with suggestions that will save you weeks or months of efforts. It might not have happened if project documentation was not thoroughly discussed. In the context of the topic discussed, you ensure developers won’t miss important details, which could lead to the wrong architecture set in place.
4. Peer code reviews. Employ pull requests for your team members to review each other’s code before it gets to master branch on version control system.
5. External code reviews. It’s not uncommon to use external code reviewers to run through your code regularly and point out places worth attention and improvement. We found it relatively easy to reach out and gather world class experts in multiple technologies and involve them in our clients’ projects for a one time or regular code check.
6. Time for ongoing refactoring. We suggest you let your developers spend 10% of their time for refactoring and code cleanup. Practically what this will mean is that they spend every second Friday solely on improving the existing code — not on developing new features.
7. Automated tests. When you start the project, you will most probably think yourself or hear from your peers: “Screw it, we don’t have time for automated tests. We are going to be agile and change our functionality multiple times, so it makes no sense to write the tests”. And that’s fine until one day you turn back and realize, or someone else tells you, that actually you ought to cover your functionality with tests. I personally prefer to have the tests rather than not. However, limitations that force people not to introduce testing are understandable like limited time, your budget, and your knowledge.
8. Continuous Integration Frameworks. Overall it is suggested to use CI frameworks, Jenkins for example, with all kinds of modules plugged in to check code compliance, tests coverage, documentation, etc.
9. Keep your systems modular. You’ll try to separate functionality into modules, or services, that act more independently and communicate to each other through rather lean APIs.

If we wanted to go deeper, I can refer to quite an extensive list of factors of technical debt on Wikipedia:

Common causes of technical debt include (a combination of):

Business pressures, where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes.

Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications.

Lack of building loosely coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs.

Lack of a test suite, which encourages quick and risky band-aids to fix bugs.

Lack of documentation, where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid.

Lack of collaboration, where knowledge isn’t shared around the organization and business efficiency suffers, or junior developers are not properly mentored.

Parallel development at the same time on two or more branches can cause the buildup of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up.

Delayed refactoring — As the requirements for a project evolve, it may become clear that parts of the code have become unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.

Lack of alignment to standards, where industry standard features, frameworks, technologies are ignored. Eventually, integration with standards will come, doing sooner will cost less (similar to ‘delayed refactoring’).

Lack of knowledge, when the developer simply doesn’t know how to write elegant code.

Lack of ownership, when outsourced software efforts result in in-house engineering being required to refactor or rewrite outsourced code.

Poor technological leadership where poorly thought out commands handed down the chain of command increases the technical debt rather than reduce it

Last minute specification changes; these have potential to percolate throughout a project but no time or budget to see them through with documentation and checks

Scope Doping, unmanaged scope reduction or shedding of scope by project managers, or indeed technical staff. Subtly different to Business pressures in that, while business pressures may be a cause, Scope Doping will also cause business pressure due to unmanaged work scope that has been shed.

Now that it’s too late and your product is based on an reliable codebase, what do you do?

Now that it’s too late and your product is based on an unreliable codebase, what do you do?

The polar decisions to make are:

1. Develop the product from scratch.
2. Improve/refactor existing software.

Before we dive into an analysis of the pros and cons of each approach, the executive summary on it is: It’s eventually your decision to make. As the conversation on choices continues, it should signalize one thing for you. The choices are more or less equal, and the worst you can do is to drag on with a decision. The key factor for a decision? Big balls!

What are you taking into consideration?

How bad is the code?

If the code is bearable — have it fixed. This can be done by giving developers time to:

1. Cover the most critical functionality with automated tests.
2. Introduce more modularity and object oriented structure to the code.

If the code is really bad — nothing will save you from having to make the decision to throw it away. Take it as a lesson and include it in your knowledge base, and then design your product from scratch. (That might be a good opportunity to take into consideration all the feedback from users, all the plans you’ve had for a while, reconsider technology stack, dismiss a couple of team members who did not perform well etc.)

Constraints and Dependencies

Do you have a launch date you can’t miss? Do you have an investor demo?

Generally speaking, people tend to take into consideration the big events that should happen, and they serve as a good explanation to us as to why we should hurry, go for compromises etc. A significant event also convincingly explains why there’s no time for just freezing the existing software and build a new version from scratch.

However, in my books, businesses will always have significant events. This is the nature of any business that is succeeding. Either it’s thriving, or it’s dead. Those significant events happen with higher frequency than the time needed for redevelopment, and so you’ll end up never rebuilding your software.

The conclusion I’ve made from my experience is — technology is the most important thing in a technical business, and it should go first in terms of corporate attention.

How much money/resources do you have for your product?

That’s where you have to treat this technical debt with seriousness and firmly grasp the the interest rate you are paying on it.

Say you’ve invested 100 man-months into the project.

You are 2/3 of the way there in terms of functionality, so you suppose you are going to have to put in 50 man-months more and then the product is fully complete to the extent you have financing for.

Now, as you continue developing features, you see that velocity becomes lower and lower, and that during the last 8 sprints it has declined by 50%: your development team was only able to kill half of the features. More time was spent on debugging and closing regression tasks, as well as on figuring out the right place to write the new code on.

Thus your optimistic projection now in terms of resources needed to finish the project is 100 more man-months versus 50 you previously had, and pessimistically it will become more like 150 or 200 as the technical debt accrues. At this stage, you might make several decisions:

1. Decrease the scope by 3–4 times. It will give you an estimate of 50 man-months which will be within your capacity. You might not think much about it, but there are oftentimes ways to do that: (x) use pre-existing solutions (templates, white label solutions); (x) become a smaller piece of a bigger solution (browser or embeddable plugin inside of an ERP, CRM or CMS system).
2. Continue with the old system accepting 150–200 man months instead of initial 50 man months estimation. You will apparently run out of resources unless you go hunt for more (get investments, do development for equity etc). I consider this to be a no-go, as it will grow as the problem snowballs and you end up with a bigger disaster later.
3. Develop it all from scratch. This is one of my favorites. If you combine this decision with cutting the scope in a smart way, you may end up releasing something cool within even 20–40 man-months! At the end of the day, your team will be on the upward part of the learning curve with the product, domain and the architectural approach required for this product.
4. Isolate the product and develop further functionality as separate services/modules. You’ll try as much as possible to keep hands off the current code base and to write new functionality separately. You’ll keep modules separate, so even if one of them is suboptimal it is easier to replace it without destroying the whole system. Although this method sounds great on paper, it’s usually hard to implement because integration of various systems may be complicated unless the modular thought was put in place initially, and we had previously discovered it wasn’t.

Conclusion

In the conclusion, I can only add one thing. It’s sometimes better to make any decision than to make none. I’ve just heard this phrase yesterday:

The main function of a CEO is to make decisions.