This isn't a problem of "eating your own dogfood" . . . Its not enough to use your own product. (I think) the point of the article, is that you should observe UNexperienced users and how THEY utilize (or have difficulty utilizing) the product.

I encountered the same thing this weekend using a popular "drawing" type product . . . watching the videos on the Company site, or on Youtube, made it seem easy. When I tried it for myself . . . I couldn't draw lines in an color but BLACK for TWO HOURS. The "experienced" users . . . unwittingly skipped over many basics a newbie user . . . just doesn't know.

It should almost be a "interrogation room" "through the glass" observation. So the developer can't "train" and can only see the suffering the new user experiences while trying to "find" the features they need.

For the tool I was using . . . its ultra powerful (once you know it) but . . . even the simplest features are maddeningly difficult to initially find. Easy and Powerful once found, but tortuously difficult to find.
That's the kind of "observation" I believe the article spoke of.

(Story aside) I'll second the ". . . we need smarter editors!" part . . .

I'm tired of articles titled "First ever PHOTO taken of planet around a distant star . . ." (Then reading the article with . . . NO PHOTO attached. Even if there is a copyright issue, that's fine, just tell me.)

"Study finds that men with a shorter than average distance between rectum and scrotum will have fertility problems." (With nothing in the article mentioning . . . what the average distance is . . . so even if I bothered to measure, I'm left with nothing of tangible use from the article.)

I've grown to give high praise to those reporters that end their articles with "We asked them xxx, yyy,and zzz . . . but they refused to respond." (At least I know they TRIED to ask the relevant questions and give me a full story.)

My father (gone now, former KY state police) always said . . . "I could see he was going 10 miles over the limit . . ." never stood up in court.

But even a farmer out in a field can look up and say about distant driver "he was just going too fast to make that turn" (placing blame for an accident squarely on the driver) . . . usually was upheld.

This guy . . . will never be convicted. Without explicitly being caught . . . he'll pass under the same reasoning drug dealers do. (If 1 in 100 that take cocaine die from it, and you've just sold 100lbs . . . then . . . you're "defacto" guilty of murder. Its that "defacto" and not "nameable person" that makes all the difference.)

So, its an impressive feat . . . but still incredibly careless and stupid.

I've seen the ball . . . and stopped to save the child.
Until they can show me a car that will do the same . . . No! Just . . . No!

I've said it in similar articles . . . I'll repeat it again.

What happens when its a 50lb child, instead of a 100lb deer?

The goal isn't to "survive hitting the deer" the goal is to "avoid hitting the child".

The last time I pointed this out, the response was "the car can react 1000 times faster". True, but that's confusing "response time to apply the brakes" with "stopping distance of the car."

It doesn't matter who applies the brakes . . . stopping distance for a 25mph car on dry asphalt is about 30ft. If you begin slowing/stopping upon seeing the ball, the child might live. If you wait until you see the child. Prepare for a big lawsuit and lots of guilt therapy in your future.

I'll vote/allow the autonomous car, when it stops for the "ball rolling out into traffic, and can 'guess' that a child will follow, and 'anticipates' to stop for the child it can't see yet."

I've had friends see cattle come out thorough a fence and lay on the pavement at night, because it was warmer.
I've had friends know to stop because NOTHING was wrong with the SURFACE of the road . . . but the raging stream underneath it . . . had washed all the underlying support away . . . the asphalt simply hadn't collapsed yet.
Sorry . . . we've just got WAY too many years of AI ahead of us before autonomous cars are ready.

Out in the "left lane" of a Interstate . . . "maybe" . . . through a city . . . we're 50-100 years away from even a remote prayer of that.

Maybe France too . . . didn't they mention that an actual Dr. came standard with the ambulance when Princess Diana's time was up?

Not so in the U.S.A. (Don't get me wrong . . . EMS and ALS is WAY better than just hoping "Bubba" can keep them alive on the trip to the hospital . . . ).
But some countries do staff "Doctors" in ambulances.

Many above mention the 4th amendment.

In general, the older I get, the more I become a "strict constitutionalist in favor of small federal government", but . . . while I respect the constitution more, it does seem to lag in one aspect . . . when your rights are tempered, because others have rights as well.

The constitution doesn't seem to address the distinction when one persons "right" comes into conflict with others "rights".

As in . .

If I walk out into the desert, away from all other people and property, with 20lbs of explosives strapped to myself and detonate it . . .
That's quite different, than if I walk into a crowded room and do the same thing.

The first, simply exercises my rights . . . the second, disrupts (in a violent and irreparable way) the rights of others.

The aspect most leave out of the discussion about searching your person . . . it isn't being performed to "find out" something "about you" . . . its to "protect others" rights.
In an odd way, in this case . . . the searching of "you" has nothing to do with "you".

Having said that . . . (though I flew lots earlier in my career) I don't think I've flown commercially in the "scope or grope" era. Partially because I think I'd feel "violated" to do so . . . I'm just not sure (in light of the fact that its being done to protect "others rights" . . .) even though its being done "to me", that it technically is a violation of "me".

Because, driving through a neighborhood at 25mph, stopping distance is about 30 ft for a typical car on dry asphalt.

Yes, the car might react 1000 times faster than the human, but if the "car sees" the child dart out when they're 10ft away, then yes, it'll stop faster than a human could (20 ft after its run over the child.)

This is one of those cases you have to "anticipate" what will happen (based on seeing the ball), not "react" to what has already begun (seeing the child).

Sorry, waiting to react to the child . . . just isn't good enough.

I'll vote for the "car that can drive itself" if it'll pass my one test.

When passing a row of cars, and seeing a ball roll out into the street . . . the car comes to a stop. Because it knows a child will soon be following along behind the ball.

Heinlein rests a little easier tonight.

(I've done other things too but) Having worked now for 26 years on one application . . . (monitoring system for manufacturing machines), no one ever asks the question first . . . Should we even be looking at frameworks?

I know the "xyz" framework for Java will allow me to generate 2 trillion lines of code in 30 minutes that will run on any device known to mankind, but "xyz" wasn't around last year, and if this is another "20 year" project . . . will "xyz" even be around in five years?

If you're writing "conversion" code to move data off one system to another new one . . . that conversion is a "one time" deal. Use anything, Forth, Haskell, APL, heck, use Java . . . I don't care. And don't care what Framework you use to go with it. But if this is to be an application that will run for five (or ten, or . . . more) years, maybe that "xyz" framework or toolkit that came out last month, isn't the best choice.

No one ever seems to first ask "how long will this program/solution be around . . .?", then . . . base the language/framework choice on that.

Yet another case of . . . "we tend to solve the problems we've encountered before". If you're like me, supporting an ancient code base, the "flavor of the month" framework or toolkit, loses most of its merit. I suppose, if you're grinding away on "one time" solutions with overbearing requirements of "fast more so than better or maintainable" . . . frameworks look much more appealing.

jkh

I've never bought a house (the one I own, I acquired after my parents died.)

Are you saying: If I were buying a house, and had been "on time" with all my payments and have 10 years to go on a 20 year loan . . . the bank can "call in" the loan early?

Surely not!?

I'm assuming you mean for people already behind on payments.

I would add . . . its not just pure "research" with the superficial understanding of programming.

I've seen personally (and "Dilbert" would seem to confirm as universal) the generalized business belief that . . .

"programming is easy."
"quality is easy."
"expand-ability is easy."
"maintainability is easy."
"If I just had a Project Management tool to keep a death grip on delivery time . . . all those other "easy" things will just naturally fall into place."

I keep thinking the opposite . . .

Quality, Suitability of Purpose, Expand-ability, Maintainability, Inter-operability, the delivery of promised features . . . those are the "hard" things. If we had a true handle on those . . . we wouldn't need the death grip on deliver-ability. Because we'd deliver a reliable version of what was needed the first pass, and spend less time maintaining it over the long haul to have time for the other projects and future expansion.

(Its been how many years now . . . and we're still not accepting the basic concepts from the Mythical Man Month?)

jkh

Right . . . "symptom not cause" . . . the whole discussion hides the implicit lie . . . that if you got out of the house, . . . "You're practically guaranteed to find the perfect mate, and live happily ever after with 2.5 children in the two story house, in a good neighborhood, with the white picket fence. (And good resale value.)"

Sure, you "fall off the horse, you get back on" . . . you, get thrown from the horse and kicked in the face 200-300 times with a shod hoof . . . even the densest person begins to realize a promising career in equestrian events, might not be in your future.

It may be bitter but . . . you may not find the perfect mate. Even if you do . . . she may not be interested in you.

Its not so much that its "easier" in the house . . . its that the alternative of eternal emotional self-flagellation outside the house, with no guarantee that if you "try just a little longer" you'll find what you've been waiting for . . . ultimately loses its appeal.

("Out of the house" for over 30 years, but no "perfect mate", no "2.5 children", and the house (inherited from two dead parents) has no picket fence.)

After all . . . the series did end with Charlie Brown NEVER getting to kick the ball . . .

So . . . why not just stay "in the house" where you have at least some control/guarantee of your level of happiness?

It has always been explained to me (by the zealots) that the "joy and beauty" of Java (and Python) is that . . . "You don't need to write lots. Someone has probably already done that, just reuse their code."

Fine, so I get the, lets see . . . Windowing API from vendor_A, the DB API from author_B, and the Serial I/O API from freewareProject_C.

Great, now all I have to do is write the core, and utilize the API's that have already been written.

But vendor_A used WhatYouCallCamelCase, author_B usednocaseatall, freewareProject_C used_under_score_variables.

Now your central core, must reference/utilize variables/functions/objects/etc . . . of all three types.

It'd be nice . . . if each language (like the K&R book did for "C") at least suggested a Preferred Standard Format.

From my own experience (or just read the preceding 800 posts) indentation can become a holy war. (Seriously, I don't see how Python survives more than one coder's reformatting . . .) Be it a good or a bad standard . . . if each language at least proposed a preferred . . . then you have a shot at all the independently developed API's . . . utilizing the same format.

Then, your core and all its references are at least "consistent" for pure visual readability. Allowing you to focus on "what it does" not "how it looks". It also has a "shot" at depersonalizing the choice. ("I know you like it like that . . . but we try to adhere to the Preferred Standard here, so . . . though I'm very sorry it disturbs you, my hands are tied." Yes, its a cop out, but it can be utilized as an argument deflating position for the better of all.)