Red flags to look out for in badly written projects.

Let’s talk about common red flags or alternatively, how to define badly-written project.

Many of us have experienced a project which is crying and begging for something drastic to change, or even for it to be put out of its misery altogether, but alas; we don’t have the heart or the resources to “pull the plug” as it were. From year to year, this poor project grows and grows; each day with new fixes and features being added. It can become so painful and cumbersome in the end, it simply isn’t tenable anymore. You fix something in one place, but in other parts something crashes, and so on…

In this post, we’ll help you work out at an earlier stage if a project is bad–without checking source code (excluding project structure).

So, how to define a project that should be rewritten because of age or quality?

There are some red flags to look out for:

1. Lack of or no communication When you open a project for the first time you should be able to:

• Understand what is the project about.
• Be able to see the technologies which are used in it.
• Have an overview of the project structure or an overview of the main business workflows.
• See the team that maintains the project.
• See how the project relates to other teams/services.
• See how to run the project.

At the very least you should see which team maintains the project, then if you have any of the other enquiries listed, you will be able to contact them and ask them about every detail you need. If most of the above points are missing, this is a major red flag.

2. No tests When you’re finished with the documentation, you have some information to think about. If it is good documentation, you will be able to understand if a project is covered or not. But if you have no documentation, you should check the project structure.

If a project is good you will see a “tests” folder or “.spec files” within services or components with some code in them.

The red flag here is if there are no tests, or there are created folders or files for tests but they are empty. Even worse, is a situation where there are tests, but they are commented out.

3. Repository state and activity A project should have a remoterepository. If a project is deployed locally, that is not just your everyday red flag it is a huge sign that something is dramatically wrong with this project.

A sample repository is a GitHub repo.

When you go into the repository, you should check for the following: a) Huge numbers of branches:

• Developers are not cleaning up the branches they deployed to production.
• Too many features developed at the same time.

b) No README.md:

• Without the help of contributors, you won’t be able to run the project or deploy it correctly. Sometimes instead of a README.md, it will be Wiki page or GitHub Pages; this is ok.

c) Number of issues and how fast they are approached:

• You can check the latest issues (about the last 10) and check their dates and comments flow. If contributors answer fast that means they are supporting the project and you can easily use their code in your own codebase.

d) Last time any changes were made:

• You can check latest Pull Requests or open issues.

Some rules for open source repositories when a project has already been in production some time:

• Small numbers of contributors.
• Small numbers of stars and forks.

If you follow the above guidelines, you'll find that you can spot red flags more easily and hopefully save yourself some time!

We're hiring! Do you like working in an ever evolving organization such as Zalando? Consider joining our teams as a Software Engineer!