On 8/16/04 10:00 PM, "Entourage:mac Talk"
<[EMAIL PROTECTED]> wrote:

>> No...it's not expected. I see nothing in the notification preferences that
>> suggest you can turn off all notifications of any kind. In fact, there's no
>> control implied or explicit for error alerts. The only alert behavior you
>> can control is new mail and sounds. There's no implication whatsoever that
>> you can mute error dialogs.
> 
> Fair enough; I stand corrected. I should have looked at the dialog again,
> rather than recall my frustration that it should be there, that a similar
> pref is there but has no effect, before posting. Would you not agree,
> though, that one might expect to find such a preference under the same
> 'Notifications' tab?

Five minutes of checking saves a lot of frustration due to incorrect
assumptions. Almost like all the people who insisted that MS promised the
FULL Outlook featureset with E'rage 2004, yet an examination of the actual
announcement shows nothing of the sort. (note, I'm NOT saying YOU did.)
Memory is not just fallible, but about as reliable as a sieve is a water
glass.

> 
> For the vote counters, I still strongly support the improvement; I consider
> it an oversight in need of address, as the Dock bounce on errors is a
> serious CPU killer; it is not merely cosmetic.
> 
>>> And as we all know, if it's of no use to JCW, anyone expecting it to work as
>>> advertised is just plain silly, and he'll make a point of telling you that.
>> 
>> Nice try Fred, 
> 
> Who is Fred? My Father goes by Fred, but he doesn't subscribe to this list.
> Have you met my Father? Very nice man; damn fine soul, even though he swears
> by XP.  (;

I'm giving your name PRECISELY the same courtesy you give mine.

<more lame attempts at wit snipped, since they have little to do with
E'rage>

> 
>> My point was, you have this, or appear to have, this idea that the
>> things that bother you are so blatantly obvious and necessary that they must
>> be fixed first. 
> 
> No, I have never claimed they were obvious to everyone; but I have claimed
> to have made the advertised channels, as well as they unadvertised channels
> aware of them. And I have no trouble making a distinction between cosmetic
> issues that are merely annoying, but that I can live with if I must (ref:
> icon control lacking; space wasted; more; same thread and others) and
> terrible or inconsistent behavior that directly effects and deters
> productivity (ref: Spell Check window; Search Options; ON window; more; same
> thread). Not sure what is clouding your vision and leaving you any other
> appearance, unless you are too pressed for time to thoroughly read and
> understand the position of other posters prior to joining in.

I understand you position. I just think you're completely blowing it our of
proportion, and think that fixing things like this take no time at all.

> 
>> You also think they can be fixed with nor more effort than
>> two days, a single programmer, and a case of jolt.
> 
> Please point out the quote where I said that. Not only did I not say that,
> let alone think that, but I never once stated that every critical, or
> moderately critical bug can be fixed in two days, Jolt or not. I would
> expect such an effort over the whole of Mac Office to take weeks and months,
> if not longer. Witness the delay in XP SP2, a publicized effort to squash
> bugs and patch holes; publicly expressed reasons for said delays, a giant
> marketing effort because the powers that be smelled the auspices of just
> such a fantasy rebellion on that side of the fence in the works.

You're right. You didn't say you can fix some of these problems in two days.
You actually said hours, and I quote:

"I can nextKeyView away more than a few problems (read: existing features
that are incompletely implemented) in short order, and I think they can, if
they wanted, as well, in a very short period of time, costing very, very
little money comparative to genuine "new features". If I couldn't resolve
the Accounts popup access in less than an hour, and the responsible
programmer, but for it not being on his approved to-do list, couldn't do it
in a third or a sixth less than I, I'd be extremely surprised. "

Of course, this hour includes all necessary QA testing and regression
testing to ensure that no additional bugs are introduced, installer
packaging, etc. Why am I not seeing this happening.


> 
> What I did say is that two bugs -- just two, mind you -- referenced in
> another side of this debate could be fixed in fairly short order, and I was
> willing to help do it. I'll even provide the Jolt (but make mine Dr.
> Pepper).

You said one hour. So, you could walk into the MacBU, and sit down at a Mac,
and from a cold start on the code, no meetings, no briefings, you could fix
that and do so in a manner that would QA and test PERFECT within an hour.

> 
>> But then, when you don't know all of what's involved, everything's easy.
> 
> And that is indeed what speaks to the overall problem, isn't it? Because the
> majority of people have absolutely no idea what is involved in writing a
> single line of code, compiling it, testing it, and then adding to it (never
> mind the complexities of seed money and bringing it to market) that they
> just blindly trust that the marketers and apologists are right, and that
> they just have to accept poor quality because best quality is simply
> impossible to deliver; that to fix one bug is to assuredly risk a dozen more
> created by the fix; that a better product in favor of less features would
> take twice as long and cost ten times as much.

Actually, I DO know, and I'm impressed that, considering the multiple
masters the MacBU must serve, that things work as well as they do, and have
seen the real improvement over the years. But then, "What have you done for
me lately" is not how I deal with the world.

> 
> Then there are the people who do know a bit about programming, enough to
> know that some bugs, even show stoppers, as well as niggling behavior gaffs,
> are truly minor and easy enough to fix, despite the tedium and effort
> required to go back to ground zero and validate every function over again --
> at least every function which receives a complaint. And let's not forget
> that virtually every software developer has an army of willing, unpaid
> testers more than happy to test out their particular areas of focus and
> provide adequate feedback in detail well prior to any FC compile.

In a product as complex as E'rage, there are NO simple code changes. Anyone
who knows programming on a large scale knows this.

> 
>> Hell, if you don't know what's involved, going to the moon is simple.
> 
> Oh, if only MS would apply the same rigorous testing, retesting,
> submissions, QA, and repeats galore that NASA and its contractors employ.
> Sure, Mac Office would cost several thousand dollars, but, oh, the bookshelf
> of documentation it would come with!  (:

We are of course talking about the same NASA that missed a planet because
they couldn't convert English to Metric correctly.

> 
>  I even once read an article they participated in wherein they bragged (my
> word) about their automated testing labs utilizing dozens(?) of Macs of
> nearly every possible or probable configuration to insure quality; that they
> had countless people going over and over the software to make sure it was
> all up to par. Why then, do so many glaring omissions  and errors make it
> past the gate? Sigh. It's just the way of things, I guess. Perhaps it is
> because people become too close  to the project to see clearly that which is
> obvious to everyone else. It's certainly true with many other things; in my
> own experience, in coding, scripting, as well as writing, one becomes blind
> to errors obvious to others; typos, GUI mistakes, et al, are all inevitable
> as part of the human process. Again, this is why we employ editors,
> proofreaders and beta testers. Then there are the beta testers who pay you
> by buying your defective product; all you need do is actually take advantage
> of their time and effort.

Yes, because they're testing things past their own pet peeves, and would
never allow those pet issues blind them to anything else. Because as we all
know, computer users are the ultimate shining examples of reasonability and
objectivity.

> 
>> The AppleScript slowdown maddens the HELL out of me, along with the alert
>> dialog. But I am not even close to being so delusional that I think everyone
>> thinks it's a major problem. Not everyone uses applescript, not everyone
>> minds an error window. I also don't think that everything I don't like is a
>> bug.
> 
> Who does? I know I made a *specific* point of stressing at least the former
> as a *feature* addition to which I favored, as well as you. While I did not
> stress the same on the latter, I named it an expected behavior, which is
> very different from a bug. But you already knew that.

Dude, you went on a multi page rant and along the way insulted the hell out
of Paul B, me, and the entire MacBU. You managed to not insult MS as a
whole, Apple, and the Masonites, but I figure given a week, you'll get
around to it. 

> 
>> Oh really...it's unethical? So you are now saying that MS is deliberately,
>> and with forethought and planning, deceiving you.
> 
> There you go again, putting words in my mouth. Please go back and reread my
> clearly qualified assertion of the level of ethics involved. One is not
> necessarily guilty of intentional deceit or contractual default until one is
> put on notice of issue, and such issue is verifiable. Both qualifications
> have been met here. Is it still intentional? Not at all likely specifically
> at any level, of course; I'm neither a conspiracist nor paranoid; but in
> practical result, the offense is still clear.

Prove that they have a contract with you to define such features to your
satisfaction. The pertinent paragraphs will do.

> 
>> Again, you have yet to
>> make a case for this with anything resembling proof, so I'll guess your
>> annoyance is blinding you.
> 
> I'm not sure what is blinding you to the contrary that is fact, that others
> have already supported in this same thread and other threads, as well as
> privately, but, I do have my suspicions that it has something to do with
> contrariness for contrariness sake.  (:   I'm sure you'll correct me if I'm
> wrong.

The other folks have pointed out they'd like things changed, and left it at
that. They didn't decide to insult a lot of people while doing it.


>> Well, there's a lot of things that a lot of people have wanted for years.
>> But you don't get to, even as a developer, (something I did once for a few
>> years at the enterprise level, and never again) fix the bugs that you want
>> to fix. Esp. when you aren't a small squad of independent devs who can base
>> everything off of a list developed by you and your customers. When you work
>> for a company Dilbertian in scope, you don't even live in the same galaxy as
>> the priority setters.
> 
> But then again, the MacBU is often publicized as being relatively small,
> relatively independent of the mother ship (something you state implicitly
> yourself in this very thread), aware and responsive to their customers
> feedback, and absolutely committed to bringing the best possible products to
> the Mac. My intent is to help them meet that stated set of goals.

Relatively. Please note that word. *Relatively*. There's a lot of choke
chain in the word "relatively".

> 
>> I wonder what would happen if customers were willing to wait for this
>> perfection and pay for it? There's two sides to that coin.
> 
> Yes, indeed. I long to see the results of just such an experiment with this
> particular product line. It has worked time and time again with other
> products. I have great faith in this venue that both sides would win; at
> worse, MacBU would make no less profit than they do now, but would stand
> head and shoulders above all, legitimately proud of doing the right thing
> for the right reasons.

It's been done, and those who take longer for perfection lose. MS gained a
90% market share from making windows "good enough" OS/2 was far better in
every way, but IBM delayed it until it was as perfect as possible. What
happened? Well, nice idea, but while they were waiting, they needed to do
work, and MS provided NT, which, while not as good as OS/2, was "good
enough". 

At some point, it has to ship, because people have work to do.

> 
>> And who requests the features? The people writing the checks.
> 
> And who requests the quality?

And who pays for fast and perfect?

Good
Cheap
Fast

I can give you any two.

> 
>> Name ten features you'd be willing to remove from E'rage to get the ten
>> things you want that aren't working the way you'd like.
> 
> Interesting challenge. I'll put some thought into it when I have time. Of
> course, your predictable response is what I don't need and am willing to
> forgo will make someone else unhappy, even though that is not the stated
> premise of your challenge. Tell you what, get me the list of new features on
> track for the next release or update of Entourage, their allocated man
> hours, versus an allocation report of my top ten bug and behavior fixes, and
> I'll make the hard choices then. I'll even go that one better: as stated in
> another post, I'll invest real sweat equity, directly or in kind, to defray
> the costs of any of my personal top ten.

Well, that would require me to work for MS, which I don't. So you present a
totally impossible challenge. Nice tactic, but it's silly. No, I'm serious.
What features would you *remove* to get the ten things you want. No
weasiling. For ever item you get, you have to yank something else. I'm
curious. 

The "Well then someone else gets screwed" is a given. "Feature Bloat" is
always defined as "What that person who isn't me wants that I don't, so
screw him" "Feature Bloat" is the ultimate expression of cognitive
dissonance in the software world.

> 
>> the MacBU is [...] small [...] has to remain a cash cow. If it suddenly gets
>> unprofitable because it's trying to double the number of programmers, then
>> maybe it no longer makes business sense to do another version of Office.
> 
> I'd like to see proof that fixing bugs requires doubling programmers.

Show me proof that fixing every outstanding bug quickly wouldn't

Good
Cheap
Fast

Which two?

> I assert that dropping one bold new feature, or lessening its scale or scope,
> is more than sufficient in trade for going back over and polishing any
> number of existing features.

Fine...which feature are you PERSONALLY willing to give up for what bug?


john

-- 
"Lo Que Sea, Cuando Sea, Donde Sea"
(Anything, Anytime, Anywhere)
7th Special Forces Group (Airborne)


-- 
To unsubscribe:                     
<mailto:[EMAIL PROTECTED]>
archives:       
<http://www.mail-archive.com/entourage-talk%40lists.letterrip.com/>
old-archive:       
<http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>

Reply via email to