Andrew Kluthe wrote:
> Richard,
>
> It's not an issue of earnestness or integrity but of what has been
> delivered vs what we were told was going to be delivered.
>
> There is a huge gap between the way things looked when they were
> presented to us in April 2013 and the way they look today.
...
> Will things all be delivered? Yeah, probably. But how many more major
> version numbers will it take?
We agree that the Road Map as presented and added to since April 2013 is
being followed faithfully, and the only question you and I have (in
contrast to those who try to raise doubts about their integrity) isn't
at all about "what" is being delivered, but merely "when".
I mentioned Steven McConnell because not since Fred Brooks have I found
a writer whose explorations of software project management are as well
researched. In his book Code Complete he notes that more than 80% of
software projects are over budget, many by a factor of four and
significant minority by a factor of 16, sometimes more.
Variance between estimated time and actual is affected by many things,
but one of the biggest is the scope of unknowns introduced by dependency
on code beyond the control of the team. With seven platform APIs to
map LC's internal logic to, we can expect variance to be on the higher
end of industry averages.
Software project estimation remains a key focus of some of the best
minds of our industry specifically because getting it right consistently
proves elusive.
There's a lot that could be said about the challenges inherent in
estimating, and methods to reduce variance. And anyone here who's been
able to consistently beat industry averages is encouraged to share their
demonstrated experience here.
For myself, when I'm able to beat industry averages in large part it's
because 90% of my code was written in Edinburgh over many years by
people much smarter than me. That's a big part of what keeps me patient
with the anticipatable delays with LC's Road Map delivery.
> How many of them will turn into additional kickstarters when their
> revenue stream dries up?
I doubt there'd be much ROI in a third crowd-funding effort, so I'm not
all that worried about that.
As for the second one, they promised a proof-of-concept build within a
year of closing, and it was delivered last week. Sure, it has a long
way to go until it's production-ready, as we would expect. But until
it's released any contributions to that campaign for licenses haven't
kicked in yet, so that one isn't a concern for me.
> Are many of these features going to end up being mac specific when
> it gets down to finding out how hard they are to make cross platform?
As much as I enjoy my Macs, I'm doing so much more work on Ubuntu these
days that that's an ongoing question for me too.
But in practice I've been relieved to find that I'm just not seeing that.
So far most of the 2500+ fixes and enhancements put into place over the
last year and a half benefit all platforms. Any Mac-specific work at
this point seems to be limited to the minimum needed to maintain that
platform as a viable deployment option, such as replacing QT after Apple
deprecated it and moving to Cocoa as that became necessary.
On the contrary, as an Ubuntu user I've been more than pleased by the
team's efforts with greater GDK integration in v7. And since like many
of us here I make most of my money from Windows deployments, it's been
good to see how much attention they've been giving the rendering
subsystem to maintain compatibility there with newer display APIs.
> That's what I mean when I say trust. Brand fetishism just isn't
> enough to live on anymore. The actual performance as a company
> lately, frankly, sucks. Since, I know you are going to want examples
> of why someone might feel this way:
>
> - On-rev (do I really need to say more? Search the list for on-rev)
On-rev is a separate service that doesn't affect my use of LiveCode, and
given how cheap and plentiful hosting is these days I've never used it
as I'm already up to my armpits in servers.
That said, it is course run by the same company, so I can appreciate how
subscribers to that service may have a different view of the company
than I do, because we rely on them for different things.
There's a lot to be said for the "bowling alley" strategy Geoff Moore
describes in The Gorilla Game. But I don't run Kevin's company and he
doesn't run mine, and we both like it that way. I got out of the
hosting business 15 years ago when the margins plummeted.
On balance I feel compelled to note that I have several friends who are
quite pleased with the service, and since I've never used it myself I
have no opinion about it beyond that.
> -The documentation is scattered, sparse, and most of the code samples
> are images. Fun.
A complete overhaul of all documentation has been underway for some time
(it's not a small task), and as recently as last week I met with Kevin
to discuss ways we can speed that along by leveraging the community
documentation team we've assembled. Yes, it would be nice to have that
more quickly, and with any luck we will.
As for images, the code examples I see are in the Dictionary and the 78
tutorials included in the install, all in plain text. Where are code
examples provided as images? I agree that those should be text.
> -The website is going down an awful lot rendering the point above
> moot as it's not available.
Yes, the DDoS attacks were annoying for everyone, but it seems the
safeguards they put into place last week have held up well since.
The taxonomy definitely needs further refinement, and in addition to the
work Steven Crighton is doing on that I discussed concerns like yours
with Kevin last week, and with Steven we're working out a plan to not
only make things easier to find, but also keep them easier to find as
the inevitable changes are introduced.
That said, if you have specific examples of resources you'd expect to
find there but haven't, it would be very helpful to hear what you were
looking for and how you went about looking for it, so we can try to
incorporate those expectations into a revised taxonomy.
> -Everything i mentioned above about the disappointments that followed
> the "delivery" of the kickstarter campaign.
No argument there; behind stated schedule is simply behind stated
schedule. Given that any estimate cannot reflect actual costs the best
alternative might be to follow the path most companies take by keeping
their development schedule concealed. Personally, I prefer the
openness, though apparently it could do with more caveats well communicated.
> Runrev's track record isn't dishonesty, it's being confident that
> they can follow through on the things they set out to do and do them
> well. So this admittance from Kevin that they spent 2x what they
> raised on the kickstarter to build Livecode 7 continues to point to
> that.
All things considered, compared to industry averages a 2x variation for
the scope they bit off isn't bad. :)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
