[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Diverging applications
- Subject: Re: Diverging applications
- From: David Tangye <..hidden..>
- Date: Wed, 13 Sep 2006 14:46:55 +1000
On Tue, 2006-09-12 at 22:53 -0500, Darrick Hartman wrote:
> The limited resources of two people is more than the limited resources
> of one person...just a thought.
Agreed. The two would like more developer helpers too. (If I knew perl
or tex I would help code.) Of course its more than a question of total
number of developers, ie one full-time might compare with two who might
be less than full time. Then there is the communications overhead of
multiple people. Clear goals (scope and requirements), responsibilities,
development process and standards quickly become the key, plus goodwill
within the project. These aspects are automatically catered for in a
team of one.
> If by some chance the entire database cannot be ported forward, at the
> very least some tables such as customers and parts need to be portable.
Yes. In any application, the general rule is that non-temporal (eg not
timestamped such as static/summary/lookup/master) data might be
migrated, whereas temporal/event-journalled/transaction/timestamped data
does not.
> Perhaps a good idea would be to have an irc meeting where several people
> can discuss some of these ideas. It's pretty easy to start a channel on
> freenode.net for this purpose. It only makes sense though if the
> developers are willing to use the resource.
I began to write 'Great idea. One or two meetings at this time might be
a big help.' However on reflection: you have this list where you can
freely converse, or if you think you might have an issue that you think
might be sensitive, simply do what I have done recently more than once:
simply email directly to whoever you think its relevant for. Ideas from
there can easily be brought back here, or not, as appropriate.
> The fork/spoon/spork has
> been made. What we as a community need is a clear vision of what the
> plans are for the future. Both immediate plans and long term plans. If
> no roadmap exists, the project may not be as successful as we all hope
> it will be. (openpbx is a good example of this where several develops
> left the Asterisk project to create their own project which hasn't
> really done much)
Agreed. Actually this industry is littered with thousands of projects
that started by coders and went almost nowhere, other than perhaps
demonstrate a good idea or two, then died. My guess at the statistic:
well over 90%. It seems to me that in >90% of those cases, the problem
was lack of a clear published and agreed vision, goals, scope, plans,
and process for how the goals will be realised/implemented. This leads
to no buy-in from other potential helpers, so momentum got lost.
Of course many projects are too far off mainstream, or just plain goofy.
This one is not, because it is based on a proven need (web and
open-database based accounting), whose implementation has already been
somewhat successfully demonstrated by SQL-Ledger.
PS the commonly agreed statistic for IT project failure in the western
commercial world was 85%, so 90% including one/two man moonlighting
startups would not be bad in that context. Whatever the figure, the
point is that failure is the much more common result. The best advice I
consistently got in the IT world and outside it was 'Failure to plan =
planning to fail.'