Brian,
I spent 10 years as a "one man engineering show" designing whole
computer systems, including the peripherals. Once I had my modular
design methods in place, I generally designed, built. tested, and put
one new product into production each month. I often made special
products to order from customers requests. This was before the IBM PC
and large corporations got into the small computer business. I worked
12x7 with super low overhead. I had others who helped with
mechanical, programming, assembly, or other tasks, but I was the
electrical engineering, sales, and customer support person (swept the
floors too).
Late in the game, a customer came to me and asked for a complete all-
in-one motherboard computer system (think iMac) using a different
Motorola processor than I had used before. It was 6 weeks from
request to running prototype. Another customer saw that and ask for a
4 card, 4 user time sharing system based on intel chips which I had
not used before. It was 8 weeks from request to delivery of a
production prototype. I had to pull a few all nighters, but it made
it just in time for the Paris
computer show deadline.
Then, my company and I were bought out by a large corporation (I had
to come as part of the deal). After a year, projects were getting
behind because they had so many engineers working on it and it seemed
that everyone was in meetings all the time discussing plans, or
interactions with support groups, suppliers, manufacturing
engineering, quality control engineering, or corporate overhead
meetings, progress reports like performance reviews, training, and
general BS.............
I figured that each engineer was at best 25% effective. The larger
the team the worse it got.
So what did I do? I hired an independent contractor to work on
software for me. I banned him from all meetings. The only
interaction he had was with me reviewing his progress, making higher
level tradeoffs, and directing his goals. The fellow cost me twice
what an employee would cost per hour, but he got four times the amount
of work done (and he only took up the space of one). A bargain! We
got back on track during the next year. But lobby as much as I could,
I could not get higher management see the wisdom of fewer meetings and
smaller teams. It just was not possible for them to comprehend that
less is more.
Needless to say, that is where I get my bias in saying that I prefer
Tomasz's approach --even though I would also be willing to pay more
for a fully polished program with all the features I need. There are
only a few ways that adding more people can speed up development. It
has to be on completely independent tasks with well defined goals.
Initially, there is a hit to efficiency for 6 months to a year for
training unless the person is of very high caliber and can work
independently out of the critical path.
Say, what if I buy two Licenses for AB. Do I get twice the influence
in the suggestions box? LOL
Best regards,
Dennis
On Jun 21, 2008, at 8:06 PM, brian_z111 wrote:
> 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@xxxxxxxxxps.com,
<bjagow@xxx> wrote:
>>
>> Red Brooks' "The Mythical Man-Month".
>>
>> ----- Original Message -----
>> From: "progster01" <progster@xx.>
>> To: <amibroker@xxxxxxxxxps.com>
>> Sent: Saturday, June 21, 2008 6:57 AM
>> Subject: [amibroker] Re: Study Charting dare I say bugs...
>>
>>
>>> --- In amibroker@xxxxxxxxxps.com,
"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
>
>
>