After a few weeks of using the final build and after speaking to colleagues and friends (as well as receiving email complaints and requests for help), its clear that the bugs are more numerous than I originally thought, deAgonia writes. Making matters worse, days after [it] was released to the eager public, engineers let loose an update [ ] that disabled [essential functionality].
[ the company] owes their customers quality, and if [their] engineers are biting off more than they can chew, then leadership needs to push for more accurate and realistic deadlines than the ones they keep imposing on themselves [ ]. Software (and hardware) should be released when ready, not due to some arbitrary and unrealistic schedule.
No, this wasn’t an article about Xojo, but about Apple’s iOS 8
I was talking to a prospective client the other day and he brought up several vocal community members that were angry about the bugs, lack of transparency, etc. I responded by saying back in my VB6 days our number one complaint about the product was bugs, lack of transparency, etc.
I’ve seen similar comments about Xcode, Xamarin, Visual Studio, and Eclipse. I guess it’s in the nature of software to always be a moving target.
I was fairly pissed at Apple last year with Mavericks being so buggy. This year it’s a public beta that will hopefully catch most of the most egregious bugs but I’m sure within a day of installing it there will be something found that millions of beta testers missed.
Have you ever looked at your old code and be amazed that a) you coded something so stupid b) wondered how it ever worked and c) why did it take years for someone to report it?
Unfortunately, we, the users, tend to get impatient for new releases. This causes pressure on companies to get new versions out quickly so we don’t get bored and go looking elsewhere for our thrills. There is actually nothing wrong with either aspect of this unless the company tries to stuff too much into the new release. That is when the fan gets plastered by the…you know.
Back in the “old days” software releases were generally scheduled for every 9-12 months. Six months was considered too fast. Companies actually preferred to be able to get things done with the software before having to update it. Then Al Gore invented the Internet ( ) and suddenly stuff was instantly available. Those pesky customers started wanting the bugs fixed and the new features more quickly. Companies have to respond and we get our new bugs even faster than before.
It takes time to get a quality product developed and properly tested and debugged. Apple learned this lesson, and forgot it, several times during the years I was there, and still more times since then. We, the users, have also been bitten by this phenomenon many times by many different software or hardware products and we really haven’t learned the lesson either.
[quote=132764:@Markus Winter]After a few weeks of using the final build and after speaking to colleagues and friends (as well as receiving email complaints and requests for help), its clear that the bugs are more numerous than I originally thought, deAgonia writes. Making matters worse, days after [it] was released to the eager public, engineers let loose an update [ ] that disabled [essential functionality].
[ the company] owes their customers quality, and if [their] engineers are biting off more than they can chew, then leadership needs to push for more accurate and realistic deadlines than the ones they keep imposing on themselves [ ]. Software (and hardware) should be released when ready, not due to some arbitrary and unrealistic schedule.
No, this wasn’t an article about Xojo, but about Apple’s iOS 8 ;-)[/quote]
In an effort not to be presumptuous, I’ll just ask you straight out, what is the point of your post? Is it that customers deserve better than what they’ve been getting from “some vendors” lately? Or are you trying to compare Apple to Xojo in terms of the quality and stability of their releases? If it’s the latter, then I would suggest that you are comparing apples and lemons (pun intended). Yes, they’re both fruits, but that’s about where the comparisons end.
They’ve never dealt directly with Apple or MS have they ?
Submit things to Apple’s Radar & its as good as a black hole - we got one case closed as it was a duplicate of a bug from 1997 or so
MS is not too far off
I think we still have outstanding tickets with both
And even if we go look at the cases there’s virtually no way to even tell if ANYTHING has been done
Folks might find this thread on Slashdot entertaining - its all about “transparency” http://ask.slashdot.org/story/14/09/28/1247252/ask-slashdot-software-issue-tracking-transparency---good-or-bad
I agree, but the key here is arbitrary and unrealistic . The entire world works on a schedule and we can’t be different. Thinking we can is asking for failure on many levels, IMHO. We developers have a great tendency to underestimate what it takes to complete a task. What we need is a large cultural shift in this area and get to the point where we offer more realistic time schedules. Then people will begin to trust us as a whole when it comes to scheduling again. This takes a large amount of training and can be more difficult than our programming task itself, that’s why we are in the state we are when it comes to scheduling.
Most devs I’ve encountered estimate based on “how long to write the code” not “how long to make it finished and shippable” which includes time for docs, examples, test cases, bug fixing etc.
One thing FogBugz did is track how good you were at estimating
It would get to “know” you better by tracking your estimates vs actuals & it would account for that when projecting delivery dates.
Basically it was trying to help you get better at estimating.
And it seemed to do that OK but there were a lot of things that for our use it was not great at.
The other aspect that is hard to deal with is there are
knowns - things we already know how long it will take
known unknowns - things we know we don’t know enough about to make an estimate about
unknown unknowns - those things we don’t know we need to know in order to make an estimate
and when someone asks for “an estimate” they all play into the estimate
Some times, I am amazed on how well some code is written !
Other times (last week as an example), I am amazed that I forgot to implement copy, cut, paste, etc. in an important window (if it was a dark, nearly useless window !), and why I do not saw that since I started that project (as a bug report displayer) from scratch ! And I was near releasing it (free software) !
Norman, is the linker / compiler / whatever (say Xojo) remove unused code when the Stand Alone is created ?
Possibles answers: I do not recall, Yes, No, Some but I forgot the conditions
