Another problem unfactored code causes with open source Rails projects, is lower participation.
Before getting into that, why do we even care about project participation?
Why participation matters
Lower participation in open source projects can kill it. Developers care about code quality and will leave if the quality gets too low. Users don’t care about code quality, as long as it still works. This means that you can have poor quality code that does a job (i.e. unfactored code).
So the number of users can keep growing, but with a stagnant or declining developer interest, work will start to pile up. Once this starts, it’s a difficult trend to reverse since now there are less developers to share the growing workload (the developer to user ratio). This might cause quick “hacks” and “patches” to get added, further decreasing the code quality, decreasing developer participation, cycling down and down.
Developers as a group don’t like to work on code that is difficult to understand. Attracting volunteer developers to your project is hard enough, but if your code isn’t well factored they might run screaming back to their own project (or write a competitor application). I know this from personal experience; after talking with dozens of developers who were interested in contributing to Redmine and many of them complained about how old and complex Redmine’s code is. I don’t blame them, if I was asked to help out and saw a bunch of unfactored code that I wasn’t familiar with I’d raise complaints also.
I’ve seen three ways poorly factored code has affected participation:
- it distracts developers
- it confuses developers
- it gives the impression that quality doesn’t matter
Distracting developers
Developers want to work on fun and interesting projects. When a potential developer is attracted to your project, they want to enjoy working on it. But if they have to spend their time wading through a bunch of unfactored code, this will interrupt their fun and will prevent them from contributing. No one wants to spend four hours going through a mess of code just to find where to put a five minute feature in.
Getting that first contribution is a major hurdle already. You want to do everything you can to keep from distracting someone from making that first contribution.
Confusing developers
When a developer starts on a new project, they know nothing about how the project is setup. The project documentation and processes might help them get a feel for how things are organized but there will always be parts of the code that aren’t documented or informal processes passed around verbally.
This means that new developers will have to read the code in order to learn about how the system is organized. Unfactored code, as a whole, will confuse developers and throw them off track. Even simple things like method names that don’t match what the method does will cause confusion. You might expect a method called #visible_by to check if something is visible to someone, but not in Redmine. It’s used to build a SQL string so you can query the database yourself.
Quality matters, or does it?
The third blow to participation from poorly factored code is that it will give the impression that the project doesn’t care about quality. There isn’t any real metric for this but it’s easy to find out just by listening to the comments people say (or aren’t saying) about your project. If you’re getting a lot of comments like “I’d like to contribute, but the code was confusing”, then you might have an underlying problem.
A collateral problem from these opinions about quality is that they will eventually make their way to the users. The users will have no experience to judge the code quality themselves, so they might take these opinions as fact. And no one wants to use low quality software.
Keeping your project well factored is a difficult task, but as a software developer you don’t really have many choices.