7. The product starts to lose business to a newcomer (hopefully the
guys who left at 4b and 5). The newcomer can evolve faster and with
less bugs. Eventually the product dies.
yeah.
smaller teams or lone programmers can often outperform larger teams or
companies, even with considerably less resources available.
part of the issue I think is that with a larger team, much more time
ends up being spent debating things, "should X be done or not done", and
having meetings, ... than actually doing work implementing it.
from the POV of an external observer, they can watch as it takes a
course of many years for features to make it into the end product.
OTOH, a lone developer can throw together their own product which does
basically those things they care about, in a considerably shorter period
of time.
on the larger scale though, decentralized development (such as
Open-Source) seems to have a different problem though:
development tends to hit a "plateau" of essentially numerous half-way
working / not-very-good products.
so, it is a lot more of a landscape of "if you want something, do it
yourself". unless a person is an active participant working to develop a
given feature, they have almost no voice in the project.
likewise, unlike with commercial products, there are relatively few
"ready-made solutions", more often, parts need to be scavenged and
forced together into something that works.
additionally, if a person wants to work using an existing codebase,
often they may need to deal with license issues, and sometimes with some
particularly awful API designs.
so, a person may be left reimplementing a lot of things themselves,
especially if a person wants to do something slightly outside of "the
norm", like "Open-Source Proprietary", rather than the more typical FOSS
or "Closed-Source Proprietary" routes.
nevermind the issue of trying to address peoples' confusion over the
notion that the source code is available, but can only be used under the
terms described in the EULA.
Not that I ever heard "the code base sucked and talented people were
encouraged to quit" as the explanation for the failure of a company.
But I *have* seen, many times, 90% of the effort spent on stupidity,
and wondered about the useful things we could have done with that
money.
yeah, pretty much.
time spent on frivolous features;
time spent on keeping everyone locked up in meetings;
....
( all this is mostly from a mix of personal observations and
experiences, and need not be taken as a statement of fact. )
I am left to suspect from observation that many of the "usual" claims
regarding programmer productivity:
codebase size (1);
project complexity (2);
specific development practices (3);
choice of programming language (4);
....
are in-fact, largely irrelevant, especially for larger projects.
1: this could be called the "smaller is better" myth. namely that if you
can write the same code in fewer LOC, that it will also mean that work
will get done faster (under the premise that programmers spend most of
their time "drowning under the complexity of tangled messes of code", or
are typing-bound, or something). this doesn't really match with personal
experience.
2: IME, it seems that the "local complexity" is much more relevant than
the total complexity of the project as a whole. like, essentially, if
the APIs are moderately well designed, it just doesn't really matter
that there may be MLOCs just behind the door. the MLOCs of code are
essentially invisible, and the main determiner of the "complexity" has
to do much more with how well the API is designed.
this assumption seems to have a lot more to do with the idea that a
programmer has to keep the whole damn codebase in memory at once, rather
than mentally loading/unloading whatever parts they are working on.
3: I just haven't seen much evidence that specific practices, especially
regarding "detail" things (like naming or formatting conventions), make
really *any* significant productivity difference.
even more general things, like OO vs non-OO, don't really make a huge
difference AFAICT.
more relevant are "general" practices, like "don't leave the program's
guts hanging out all over the place".
4: basically the same issue as 3, especially when one considers the
dominant languages in use, and observes that, in general, they aren't
really *that* much different in many areas (usually, similar things can
be done largely independent of the exact language used, and as one moves
"beyond the trivial", similar amounts of code are generally required to
accomplish similar types of tasks).
even people criticizing C largely amounts to this IMO, with them either
equating language with specific development practices (typically
old-style procedural development), or claiming that certain things (such
as OO) are "impossible", rather than just "pretty damn ugly".
the ugly syntax of function pointers, things like
"obj->vt->SomeMethod(obj, ...);", ... may not actually be a huge
difference (may sometimes be wrapped though).
I suspect even things like the presence or absence of things like
"generic container classes" may be at most a modest difference.
or, IOW, for larger projects, most smaller-scale details largely end up
evening out (and may well become largely moot points, if all the
developers are mostly left arguing about things and stuck in meetings).
or such...
