I think the fallacy here is to assume that anyone working on
the project needs to be an as top-notch programmer as you are.
Usually, that's not the case.
Many projects only need "expert" knowledge for a fraction
of the project, but the rest is just "grunt" work.
For fun, let's analyze a specific scenario.
Let's assume that the "Perl 6 project" is "late" and
that we have some (below average) developers available to
throw at it with the goal of "finishing" it sooner.
For this hypothetical scenario, let's loosely define "finished"
as all Synopses
complete and all implemented in at least one Perl 6
implementation with similar performance and stability to perl 5.14.
I don't want to get distracted with nit-picking the "definition
of done" here. The point of this little exercise is to
gain insight into Brooks' Law: where does it hold,
where should it be repealed?
To simulate what I typically see in commercial projects,
let's further assume that these new developers have
little prior knowledge or experience in Perl.
Now, adding new "below average" developers to perform
highly skilled work, such as finishing
or improving the Perl 6 parser seems counter-productive
to me, a classic case where Brooks' Law holds.
In which of the following areas would adding more
people help finish the project sooner?
- Writing the Perl 6 specification
- Perl 6 development of parsing, compiling, ...
- Perl 6 runtime development (run machine, garbage collector, introspection, foreign code, parrot, ...)
- Perl 6 library development
- Writing Perl 6 documentation
- Development of installers
- Development of tools (e.g p5 to p6 translator, pod2html, ...)
- Development of Perl 6 CPAN
- Writing test suites
- Using Perl 6 and reporting bugs and issues found
- Maintaining the bug database, issue tracking, ...
- System administration
- Marketing, maintaining Perl 6 web sites, wikis, ...
- Release engineering
- Project management
I may have missed some key areas above or broken things down wrongly.
Please feel free to suggest improvements.
I suspect that most open source projects (such as Perl 6) are
well ahead of most commercial ones in terms of documentation
and in partitioning the system into independent components.
Accordingly, I feel Brooks' Law is less applicable to open
source projects than to commercial ones.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||