Component oriented development

Component based software development is not only good for boosting reuse in your project, it also has some other benefits like simplifying project management. Yes, splitting up your software depending on the number of developers or their abilities doesn’t look like a good idea, but correctly dividing the whole system into meaningful modules looks better and at a certain point in time will help in splitting up responsibilities.

Some projects will face component division from day one (creating different libraries which will follow their own release cycles), and will even put different groups in charge of each of the components. In other projects software is started as a whole (and it doesn’t mean it is not correctly designed but it is all built and released together), but time and the ever growing feature list will force the team to divide it into independent pieces, and sometimes the team itself will be splitted to work on the different parts.

We've just published a whitepaper telling how to implement different component oriented scenarios using Plastic. Selectors, one of the core pieces in the system, will enable users to run both single or multirepository projects, and the doc explains when we recommend going for one or the other.