|
PureBytes Links
Trading Reference Links
|
--- In amibroker@xxxxxxxxxxxxxxx, "Paul Ho" <paultsho@xxx> wrote:
>
> Tomasz is a one man band. So I can appreciate and am very happy with
> the product direction he has taken.
I agree with this. The capabilities of AB, and the speed at which it
evolves are most impressive.
At the same time, I've got definite empathy with folks who "only need
just these few things, but need 'em really badly".
> I don't think Brian's suggestion of hiring a few more programmers is
the answer.
But I think the notion of getting some small number of programmers
beyond TJ engaged in the maintenance and growth of the code base is
something that does deserve serious consideration (for multiple
reasons, some of which I'll mention below).
There are different possible models for this, some of which would
require some amount of revenue compensation, but it is too simplistic
(IMO) to say that a 2nd programmer would necessarily double the price
of AB, while a 3rd would triple it.
As laudable and impressive a job as TJ does with AB, there are risks
of single-developer/complex-project development which _cannot_ (IMO)
be mitigated without adding people:
1. As code piles upon code and the product gets continually larger
and more complex. There _will_ be more bugs present (whether latent
or discovered) as the project grows. Eventually, the burden of just
dealing with the bugs exceeds the efforts of a single person (unless,
of course, the bugs are ignored).
2. Unpredictable situations-in-life can sideline the principal,
partially or fully, for any amount of time. Development then drops to
a crawl, or halts altogether, because there is nobody else with access
to the codebase, or the acquired-over-time knowledge to use it.
3. _Major_ efforts in multiple areas (beyond a single person's
ability to multi-task) cannot be undertaken simultaneously.
Competition which successfully operates with a well-led,
highly-competent team _will_ eventually produce a superior product
with a better value proposition.
IMO, the biggest issue with AB going multi-developer would be the
change in TJ's daily lifestyle. The particulars of dealing with a
coding/development team (even a team of 2) would require a percentage
shift from "code time" to "people time", and involve new elements of
coordination, flexibility and patience that are not necessary for a
single coder working alone.
To say it can't be done (in general) is incorrect, else all software
companies would be one-man shops. We all know that there are many,
many successful software companies that started singular and grew
larger, successfully.
OTOH, maybe TJ loves his role as-it-is (it certainly seems so!), and
simply doesn't want to make much of a change to it. I can quite
understand if this is the case.
I would still contend that it would be possible to structure the AB
organization (as a whole) in a way that preserved TJ's "visionary
primacy", allowed TJ to architect and write code most of the time, and
involved one or two or three more developers (in some capacity)
back-stopping TJ and contributing to the base product in very useful ways.
What I cannot contend is that this would not still be a significant
change - it would be. Perhaps it is just too much of a change to be
on-the-table.
At current prices, people can afford to buy AB to fill a "niche" in
their suit of tools - and many do! That's a significant advantage in
itself.
Even just thinking about all these issues could be quite a time-taker!
One might easily decide - "Best not to spend time on that, best to
keep writing code!" :^)
> What I would like to see is that Tomasz opens up the hand
> drawing capability to third party contribution through the use of
> plugins, much like the AFL and data plugins.
Agreed. TJ's got a knack for this plugin stuff. It's a great way to go.
Any form of leverage that keeps _everything_ from falling on TJ
personally is a good idea (IMO).
- Progster
------------------------------------
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/
|