I have worked in many different software projects. Some successful and some not. It turns out that bad software projects have similar traits. These are some I've been able to identify throughout the years:

Poor technical leadership

Chaos and poor decision making does not translate into quality. Good software does not happen by serendipity. It is the result of organization and decision making based on facts. Strong technical leadership also sets the habits for the rest of the team. People learn by example. Technical leaders have to set the example for others to follow.

Undefined responsibilities

People need to know what they have to do. What their basic responsibilities are. Otherwise, they will point fingers and accuse each other when things fail. Its important that we give people the opportunity to do great things. The way to achieve that is to give them opportunities that have a certain level of expectations.

No testing

There is a surprisingly big amount of software being written today without any sort of tests. No unit tests. No integration tests. Not even “does it work on your machine? tests. The code gets written (or copied from the web), compiled, and pushed out. I've seen companies fail due to abysmal product quality that is the result of no testing.

Unwillingness to train

We cannot expect everyone to know everything and to be up to speed on every single technology, so training is essential. A team of developers that does not get trained only grows at the rate of the least trained person. If you pay thousands of dollars a month for a developer, it is worth taking an hour or two a month and train them in some technical subject. Be it testing, coding, a new language, a new paradigm, anything at all.

I think environments that do not promote training comes from the corporate attitude of not investing in their people. They seem to fear that people will leave for better jobs once they acquire new skills. Which happens, but in my experience, is not as big of an issue as they make it seem. Not training someone out fear of them leaving is equal to not falling in love out of fear of being hurt. Open source projects should also train contributors, be it in the form of documentation, a video, or something else. If you train your contributors they will grow and produce better code. The scenario is win-win for both sides. I have only seen a small subset of open source projects that train people. Its no coincidence that these projects are also successful.

Toxic members

Some people are good at writing code but bad at dealing with people. Software is made by people for people. You have to make sure that toxic members are handled properly. Sometimes people become toxic because the leadership is poor (item #1). A lot of toxic people are just burned out. Dealing with toxic people is a complicated subject, but being able to identify a toxic member is enough to improve the conditions for those affected.

Focusing on the short term goals

Pushing code without tests in order to solve a “corner case sounds like a great idea at the moment, but developers must look at the bigger picture. You might have given the OK to others to do the same thing on a bigger scale. Have you ever worked on a project that had tests but now doesn't? Guess how it happened.

What if your project has one or more of these traits? Don't panic. It can be fixed. The important thing to understand is that bad software is a result of things within our control. Knowing and accepting that we can improve things is the first step towards turning around a project.

PS. Follow me on Twitter and Snapchat @pryelluw.

I'm available for Python,
Django, and Javascript projects.
Contact: pr@yelluw.com