In AreLongAndDescriptiveRelated, one of the more important side passages was about the correspondence between "project size" and "required descriptiveness". In FactoringLargePrograms, I argue that a project should never '''be''' "big". Some other pages, like DefinitionOfProjectFailure, also try to clarify the concepts of big software projects. All these topics seem to come down to the single question: what is a project, actually? Usually the term "project" is used interchangeably with the project's results, like the code the programmers have produced, meetings, and organisational structures. However, the connection between these and the "project" is usually quite weak, and all of them have an independent life from the project. I'd like to reflect on the code, in particular. Why is some code deemed part of a project? That's because someone who wrote the code got his salary from the project budget. Now, usually a project is deemed "big" if you have a lot of programmers, and consequently, usually a lot of code. But this doesn't tell a ''thing'' about whether the code is actually interrelated, or anything. I hold the opinion that a project is a social and management structure that should not be confused with the structure of the project's products. The only way (to date) to actually manage a big project is to divide it in parts; however big the project in total, it's the size of your "part" that counts when you do the actual work. I advocate the term "biggest inseparable component" to catch the concept of "technical project size" (in a well organised project, this is tiny. Any person might have several (hundred) of them). I would also like to have something like "area of fragility" as the set of people you have to inform when you change something. This should catch the concept of "social project size". But what about the project? What is that term good for? What does it tell? I'm more and more of the opinion that claims about "project size" are empty claims that are thrown in the air to impress people. I have worked in a project with hundreds of people and more than 10MLOC, but I never saw more than a few of the people and more than 15KLOC of code... so? Should those 15KLOC have been written with "big project" style, or "small project" style? So, I rest my point that the style of writing code does not depend on "project size", that biggest inseparable components should not exceed say 30KLOC, measuring project "successes" and "failures" tells little of what actually happened, and that usage of the term "project" in estimating anything technical should be abolished. BigProject seems to have similar tones. -- PanuKalliokoski ---- CategoryDefinition