Big or small?
·2 mins
I’ve been thinking a bit about whether it is better to have one big code base that has a lot of different components and features, or whether there should be many small code bases that each do one thing well.
I don’t have any answers, but perhaps these half-formed thoughts will help: positive, negative and interesting things about having many small related projects. These thoughts are mostly inspired by working on a bunch of different testing-related projects.
Positive
- "Do one thing and do it well"
- Enforces a certain kind of interface discipline
- Avoids/postpones scaling problems with big projects - test suite run times - documentation navigation - bug triage - forking mailing lists etc.
- Newcomers only need to "buy in" to one idea at a time
- Aligns with conceptual understanding of the problem
- Better separation of commit privs etc
Negative
- Release overhead
- Duplication of infrastructure - buildbot / hudson / pqm - bug tracker - mailing list
- Duplication of license / copyright games
- Harder for newcomers to see the big picture
- Problems caused by interactions between different versions
- Depending on multiple libraries is a pain on many platforms
- Lag with commit privs etc
Interesting
- Perhaps smaller & self-contained means easier to upstream
- Some projects like adding only small dependencies, other projects like adding few dependencies
Do these make sense? What would you add?
Twisted is in a sense the opposite of the small/many paradigm, in that it includes a great deal of extra features along with its core.