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