|
PureBytes Links
Trading Reference Links
|
Love it!
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
Mind you, only an engineer could formularise personal interaction:
(from the book?)
Assigning more programmers to a project running behind schedule will
make it even later, due to the time required for the new programmers
to learn about the project, as well as the increased communication
overhead. When N people have to communicate among themselves (without
a hierarchy), as N increases, their output M decreases and can even
become negative (i.e. the total work remaining at the end of a day is
greater than the total work that had been remaining at the beginning
of that day, such as when many bugs are created).
Group Intercommunication Formula: n(n − 1) / 2
Example: 50 developers -> 50(50 − 1) / 2 = 1225 channels of
communication
I particularly enjoyed this line:
"It should be kept in mind how much of the work-week will actually be
spent on technical issues, as opposed to administrative or other non-
technical tasks, such as meetings."
since I was excommunicated in my (past) company when I
suggested 'meetingless management' (as in physically going to a room
for a 'business discussion') - my brilliant career was all downhill
from there.
brian_z
--- In amibroker@xxxxxxxxxxxxxxx, <bjagow@xxx> wrote:
>
> Red Brooks' "The Mythical Man-Month".
>
> ----- Original Message -----
> From: "progster01" <progster@xxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Saturday, June 21, 2008 6:57 AM
> Subject: [amibroker] Re: Study Charting dare I say bugs...
>
>
> > --- In amibroker@xxxxxxxxxxxxxxx, "Tomasz Janeczko" <groups@>
wrote:
> >>
> >> ... adding 2 more developers for core development
> >> would SLOW DOWN the development
> >
> > Depends what is meant by "core" (IMO).
> >
> > I think there are dozens of UI oriented (or other) "nice-to-haves"
> > that would really save hundreds and ultimately thousands of hours
on
> > the user side that will never be prioritized for implementation
while
> > AB has a single, sole developer.
> >
> > Faced with a practical hard-limit of, say, 2500 developer-hours
per
> > year, there are many useful potential enhancements that won't ever
> > make the cut - and for perfectly defensible reasons - given the
> > assumption of fixed maximum effort.
> >
> > Even worse, of course, if the developer-hours per year drops off
for
> > unexpected reasons.
> >
> > IMO, it would be possible for another developer(s) to add
specific,
> > helpful functionality without "diluting" core architecture
extension
> > and design work.
> >
> > Anything that saves time for users is leveraged across thousands
of
> > users. It is unfortunate, IMO, whenever thousands of users endure
> > daily hassle or expense-of-time for something that could have been
> > corrected at the source with, say, a dozen (or 2) hours of
developer
> > effort.
> >
> > The experience of open source (in general) proves that multiple
> > developers can do alot of good for a product by working on
different
> > items in different areas.
> >
> > I'm not suggesting AB go public open source. I'm only saying
that the
> > same tools (revision control systems, etc.) can be used for a
> > business's development to enable contributions by multiple
developers
> > to be made to great benefit, with minimal (but non-zero!)
disruption,
> > under terms set by the business in question.
> >
> > Anyway, those are my thoughts, and they are all offered in general
> > terms. Some things do go undone under the current model, and
> > certainly some of what goes undone would be very nice to have.
> > Personally, I think it's a subject worth considering.
> >
> > Nevertheless, AB remains the single best value in TA software
> > available. (The new Optimizer plug-in capability is FANTASTIC,
but
> > that's another post :^).
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Please note that this group is for discussion between users only.
> >
> > To get support from AmiBroker please send an e-mail directly to
> > SUPPORT {at} amibroker.com
> >
> > For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
> > http://www.amibroker.com/devlog/
> >
> > For other support material please check also:
> > http://www.amibroker.com/support.html
> > Yahoo! Groups Links
> >
> >
> >
>
------------------------------------
Please note that this group is for discussion between users only.
To get support from AmiBroker please send an e-mail directly to
SUPPORT {at} amibroker.com
For NEW RELEASE ANNOUNCEMENTS and other news always check DEVLOG:
http://www.amibroker.com/devlog/
For other support material please check also:
http://www.amibroker.com/support.html
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/amibroker/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/amibroker/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:amibroker-digest@xxxxxxxxxxxxxxx
mailto:amibroker-fullfeatured@xxxxxxxxxxxxxxx
<*> To unsubscribe from this group, send an email to:
amibroker-unsubscribe@xxxxxxxxxxxxxxx
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|