Re: Why has the Metrowerks sign been taken down?

> Right, but I beleive Larry's point is still very valid looking forward.
> I don't want to to put words in his mouth, but I think the logic goes
> like this:
>
> 1. Let's say it did take 2-3 days to covert those menus.
>
> 2. There were literally thousands of OS apps moving to OS X over the
> period of time Larry was was referring. Some much larger than File
> Buddy, others smaller. For the sake of argument, let's say it took an
> average of one full work day to convert an app's menu resources to the
> nib format.
>
> 3. 1000 dev apps * 1 man-day to convert the menu resources = 1000
> man-days of effort.

Only a thousand applications? ;-)

> 4. Apple could have invested, let's err on the side against Larry's,
> 30 man-days to properly implement a menu rsrs importer.

I'm thinking more like two or three. IB can already import menu bars,
so the core code of parsing a 'MENU' resource is already there.
>
> 5. Had Apple done 4., the Macintosh developer ecosystem would have had
> 970 man-days of additional effort available for other things to make
> apps better and/or releasing apps faster.

Exactly. But wait...why would I want to be adding features when I could
be copying and pasting menu item text into menus one at a time? Isn't
the latter just a salable as the former? ;-)

> And we're just talking menus here.

Add the costs incurred by developers doing way too much manually in IB,
working around bugs in Mac OS X, and time spent trying to track down
documentation and I'd claim we're looking at tens of millions of
dollars in total costs to the Mac developer community.
>
> This is an anecdote, but the generalization is that there is a massive
> leveraging effect wrt Apple documentation, dev tools and OS bug fixes.
> Any time Apple can spend X man-hours to improve any of those 3 things,
> it provides additionaly productivity to Mac Dev universe many orders of
> magnitude greater than Apple's effort.

This is *exactly* my point! I know Apple can't do it all, but IMO they
dropped the ball on some of the basics.

- Bugs in the OS is a big one. When a developer encounters a bug in the
OS, this is the typical scenario:

1. Write code.
2. Test code and see that it isn't working.
3. Check code for glaring errors. Reread documentation for clues about
what could be wrong.
4. Codes looks right, but maybe this is the wrong constant, or maybe
the port needs to be set first, or blah blah blah. So you try some
variations on the code.
5. Nothing makes it work, so you post something to the carbon-dev list
or here or ask a coworker and find out it's a bug in Mac OS X. Or you
skip asking anyone and just assume it's a bug.
6. Go back and rewrite what should be perfectly good code to work
around bug.
7. (Optional) File bug report with Apple.

Would anyone claim this process is going to waste less than an hour at
best, and a day or more at worst?

- Interface Builder is a big one. It's buggy and it has gaping holes in
its functionality that reduce productivity.

- Documentation is getting better now, but it's still not good. There
are still areas where it's minimal or nonexistent, and what we do have
is too spread out over web pages, PDF files, man pages, tech notes,
Q&As, header files, mailing list archives, and in some cases the Darwin
source files themselves, and to make a bad situation even worse, there
is no cross referencing between these. Who thinks this is the right way
to document Mac OS X? Not to mention the fact that it makes newbies
crazy. Windows programmers laugh at the state of Mac OS X
documentation, and they never even think to look in the headers, which
is the *only* place some things are documented. (Documentation quiz:
Let's say you want to limit the text an Edit Unicode Text control can
accept. Mac OS X is five years old and in its fifth major release.
Would anyone care to tell me where Apple has documented how to do
this?)

Addressing any and all of these areas would have required Apple to hire
a few more folks, but IMO, they should have accepted that as a cost of
being in this business. Does Chevrolet release a new model and not
provide service manuals for it because they don't want to pay people to
write them? The whole notion that hiring the people needed to get these
things right was optional is just ludicrous to me. If Apple can't
afford to hire them, what makes Apple think *we* can afford to deal
with the consequences?

And finally, I'd like to point out that some of the consequences affect
Apple as well. Apple uses IB in their own applications, for example.
Every bug report has to be read, compared to other bugs to see if it's
a new problem or a duplicate. If it's new, it has to be assigned to an
engineer. Some bugs are simple fixes, but others can result in multiple
exchanges between various parties within Apple. Somewhere in here it
has to be triaged; should it be fixed immediately in a security update,
for the next regular update, for the next major release, or never? Will
fixing it break existing applications? If it's to be fixed, then
someone has to fix it. Then the fix has to be verified. Who thinks this
process doesn't cost Apple anything?

The point here is that if Apple could reduce shipping bugs by hiring a
couple of engineers and more QA engineers, part of the cost of those
people would be offset by the need for fewer resources to address
problems later. Unfortunately, dev bugs and engineering probably have
different budgets, so the engineering bean counters can only see how
much they're saving by not hiring the people they need. I read about a
company once where support charged the development group for every
support call that was traceable to a bug in the software. If dev bugs
were going to start charging engineering for every bug reported,
engineering management would probably keel over en masse from a group
panic attack.

Larry

.

Relevant Pages

  • Re: Why has the Metrowerks sign been taken down?
    ... documentation is the *only* source of problems in software or even the ... to ensure I only call thread-safe APIs from a preemptive ... Apple engineers to get some of the answers I needed. ... good software engineering, but in the real world it's a lot ...
    (comp.sys.mac.programmer.codewarrior)
  • Weekly Python Patch/Bug Summary
    ... Patch / Bug Summary ... Help with Python codebase ... Update to Macintosh library documentation ... Segfaults on memory error ...
    (comp.lang.python)
  • Loginwindow.app and Mac OS X
    ... testing our EFI-based memory recovery utilities discussed recently. ... Apple originally didn't consider this to be critical because "you have ... However, any DMA attack ... A few details on how to find your own password (from the Apple bug tracker): ...
    (Bugtraq)
  • Weekly Python Patch/Bug Summary
    ... Patch / Bug Summary ... typo in liblocale.tex ... subprocess documentation ... Registry not updated by 2.4b1 installer ...
    (comp.lang.python)
  • Re: Dock and stack graphics still being corrupted by running games in 10.5.3 :-(
    ... and relaunching the Dock doesn't fix it. ... set off by games that Apple STILL hasn't fixed as of 10.5.3. ... in this bug, in the hope they will apply pressure to Apple. ... I'm getting the exact same problem on a brand new 20" imac... ...
    (comp.sys.mac.system)