As the saying goes . If you want to kill it, give it to a committee .
Or if you prefer . Brooks Law: Adding people to a late project makes it later . These at first seem somewhat amusing but there's a lot of truth in there . The problem for the consumer is . What happens when the one man shop gets hit by a bus . Buses come in lots of shapes and sizes . Sometimes they say Greyhound on the side . Sometimes they're only visible with the help of a CT Scan . _____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Brown Sent: Saturday, June 21, 2008 9:27 PM To: [email protected] Subject: Re: [amibroker] Re: Study Charting dare I say bugs... 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 <http://en.wikipedia.org/wiki/The_Mythical_Man-Month> .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 [EMAIL PROTECTED] <mailto:amibroker%40yahoogroups.com> ps.com, <[EMAIL PROTECTED]> wrote: >> >> Red Brooks' "The Mythical Man-Month". >> >> ----- Original Message ----- >> From: "progster01" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED] <mailto:amibroker%40yahoogroups.com> ps.com> >> Sent: Saturday, June 21, 2008 6:57 AM >> Subject: [amibroker] Re: Study Charting dare I say bugs... >> >> >>> --- In [EMAIL PROTECTED] <mailto:amibroker%40yahoogroups.com> ps.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.amibroke <http://www.amibroker.com/devlog/> r.com/devlog/ >>> >>> For other support material please check also: >>> http://www.amibroke <http://www.amibroker.com/support.html> r.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.amibroke <http://www.amibroker.com/devlog/> r.com/devlog/ > > For other support material please check also: > http://www.amibroke <http://www.amibroker.com/support.html> r.com/support.html > Yahoo! Groups Links > > > _____ I am using the free version of SPAMfighter for private users. It has removed 486 spam emails to date. Paying users do not have this message in their emails. Try SPAMfighter <http://www.spamfighter.com/len> for free now!
