Re: Why has the Metrowerks sign been taken down?

> Like anybody was going to tell Steve "We need more engineers for this
> transitional technology support".

Someone should have told all those NeXTies that the Mac was not going
to be their next chance to prove they were right all along. Again, all
you're doing is explaining *why* Apple screwed up. Frankly, I don't
want to hear it. Explanations don't fix bugs or make amyone more
productive. What you're saying is that they screwed up because they
were arrogant. Arrogant to think everyone would junk all his old code
and jump on the Cocoa train, which justified giving Cocoa second-class
treatment.

> Now there are other
> decisions that need to be made - if every developer wrote up a bug on IB
> importing MENUs, you can bet that it would be worked on and improved

I agree. But what I've noticed is that most developers feel they are
too busy to write up a bug whose fix won't do them any good. By the
time you figure out you can't import menus with IB, you don't have time
to wait for Apple to add that feature in response to a feature request.
So most people just slog away at converting them by hand and muttering
curses at Apple under their breath while they do it. I once say another
developer say that if you use IB for any length of time you'll find
something to write up in Radar every few minutes and that he just
didn't have time for that. FWIW, most of the bugs--as opposed to
enhancement requests--I've written up against IB are for 100%
reproducible bugs that never should have even been shipped.

> So given that this hasn't been improved means either:
> "They" don't want to work on it no matter how much people file bugs
> Other items have higher priority (because of more requests, or
> corporate direction, or however these things are prioritized).

It could also be that too many developers just worked around it without
filing requests for a feature they knew would come too late to help
them.

> How about let's just reference "Mythical Man Month" and say that
> throwing bodies at a problem is usually an incomplete answer at best.

Agreed. But that in no way means that additional manpower isn't an
essential part of the solution for a particular problem. If your house
is on fire, are you going to tell them to only send one truck and two
firemen? Sometimes, and I believe this is that case here, additional
manpower *is* part of the solution. Do you think they couldn't produce
more and better documentation if they had more people in tech pubs? Do
you not think their sample code could be better if they had more people
reviewing it? Do you really think one QA engineer for 30 coding
engineers is enough?

> Adding toolbars would take significantly more than a day (either for a
> developer in their application, or adding them to IB). Most
> applications have (or want to have) toolbars. Most new applications are
> not converted from rsrc based MENUs.

That may be true now, but what about five years ago?
>
> I think the math of "most applications" > "applications converted from
> rsrc based MENUs" (since the latter is a subset of the former).

These things should be evaluated on a cost/benefit basis. If importing
menus could be done in a day and it would help 1000 developers, it
should still be done. If toolbar construction would take 60 days (note
that a change like this requires not only changes in IB, but
corresponding changes in IBCarbonRuntime and Cocoa as well to support
it), then something of that magnitude should clearly be weighed against
other features that might have to be left out.

> You're saying they should have made other choices on what to
> add/fix/work on in IB than what they did. That sounds like "second
> guessing" to me.

Second guessing or not, the point is that they dropped the ball and we
had to pick it up. I would like to think they've learned from their
mistakes, but I haven't really seen any evidence of that, or that they
even realize they made mistakes (after all, their stock price is up and
iPods are selling like wildfire, so what mistakes could there have
been?). Everything is slowly, gradually getting better, but I haven't
heard about any changes within Apple to address any of these issues
more aggressively, and I certainly don't expect them to do any better
if everyone just accepts the status quo. By getting better I don't just
mean getting better at the same old pace, I mean *change* for the
better inside Apple, such as hiring more QA engineers, more tech pub
writers, increasing their commitment to IB, and so on.

Larry

.

Relevant Pages

  • Re: Why has the Metrowerks sign been taken down?
    ... IB has so many bugs I doubt one or two more would make much difference. ... - You're basing this on the assumption that this feature would take one ... to read 'MENU' resources and convert them into menus in a nib. ... Well, the point is that Apple should have loosened the purse strings, ...
    (comp.sys.mac.programmer.codewarrior)
  • Re: Towards a responsible vulnerability process
    ... in tremendous improvements in developer education. ... But the best example we have of code that is nearly bug-free is the ... The very best developers create few bugs, ... learn after some number of unpleasant experiences. ...
    (NT-Bugtraq)
  • Re: HEADSUP: ibcs2 and svr4 compat headed for history
    ... That includes kernel interfaces and security bugs. ... The svr4 code was apparently not written ... If we opt to have it off by default, mainstream functionality ... the hard thing to tell from a developer perspective is whether ...
    (freebsd-current)
  • Re: TDD: Test-Driven Design or Test-Driven Development?
    ... You are allowed to cause friction on USENET - that's what it's for. ... The TDD cycle is very good at preventing bugs, and making the few that slip ... > also be mandated that every developer should document ...
    (comp.object)
  • Re: Delphi for IPHONE
    ... if Apple allows the application to remain in the AppStore once ... to be honest, if nothing else, id expect Apple to require applications being kept up to date, which would sort of imply a renewal of the developers program, anyhow. ... for example, i hear the "Mac Downloads" page on Apple.com requires apps to be updated within at least 3 months, to keep showing them. ... developer, ...
    (borland.public.delphi.non-technical)