|
Be patient - these are all AI aided devices... With time they will learn and improve...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
|
|
|
|
|
Then retire to the Caribbean.
|
|
|
|
|
Always check the quality stamp before buying.
It starts with: "Made in..."
|
|
|
|
|
don't be so harsh, you know there are some quality goods out of china,
but out the back door of the same factory are all the below/failed spec "same same, we only change name" versions of the identical product.
(they can do quality, just that their pass yields are still not good.)
Message Signature
(Click to edit ->)
|
|
|
|
|
You're the one that filled in the dots.
But generally it's a question about getting what you pay for.
|
|
|
|
|
Not in my experience.
The Garmin forerunner 310xt for instance, it is a very precise device. I've extensively tested it (my running companion since 2012). The Garmin fenix 5 (far more expensive than the forerunner) might be a cool smartwatch but is a completely failure for thge runner. The distance mesurment error of 5% I experienced (meaning about 2 km in marathon) is inacceptable.
|
|
|
|
|
Sounds like you're not having it in gps-mode.
How long does the batteries last?
|
|
|
|
|
Of course the GPS is ON (and 'ready') while I am running. The tracks are actually fairly accurate, but the distance measurment is poor.
The batteries performace is within the specifications as far as I can say (I didn't focus my attention on such an aspect, yet).
|
|
|
|
|
Had to ask.
A guy at a previous job was running in battery save mode for half a year before realizing why the gps was all over the map.
Is i always showing a too large distance by any chance?
|
|
|
|
|
On the contrary, as a matter of fact is (almost) always showing a too small one (making the poor runner breathless in order to keep the pace ).
|
|
|
|
|
Managers.
Latest Article - A Concise Overview of Threads
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
|
"Population aging is a shift in the distribution of a country's population towards older ages."
(From wikipedia)
It will only get worse.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Most people in software arent engineers, they are nerds.
|
|
|
|
|
Hey man, the 1980s are calling, they want their "insult" back...
|
|
|
|
|
If the shoe fits...
It is true though, like no other form of engineering IT has too high a nerd content to be done professionally.
|
|
|
|
|
I agree with you here. I've notice a number of old school mechanical devices that are poorly designed. For example, they've put in some new paper towel dispensers in the bathrooms and kitchens at work. On the dispenser it says 'pull down slowly with both hands'. Yeah, that's not going to work. Every person I see using the dispensers just grabs the paper with one had and pulls down fairly quickly. Half the time, the paper gets jammed or tears off inside the dispenser. So now you have to resort to the dial on the side of the dispenser to get the paper to a place where you can reach it. Kind of like they only let the designer test the dispenser.
|
|
|
|
|
Yeah, I really hate those dispensers. They expect you to pull on something with wet hands that is just going to tear easily once you grab it. It's gotta be the worst design on the planet.
What the hell ever happened to just keeping things simple? Maybe you remember or maybe you don't, but there used to be towel dispenser that had a crank with rollers. Just grab the crank, rotate it out for the amount of paper you want, then tear it off. Easy, simple, mechanically robust, always worked.
For a lot of stuff, the problem is two fold: First, they gotta make things break so you'll have to buy more of 'em, and second, they have to constantly change things on them (usually to worse solution) to make you either have to buy the new model because old consumables are no longer available or no longer fit - or just to make you think that if you keep the old stuff around, you are no longer "cutting edge" or whatnot.
Basically the automotive sales model.
|
|
|
|
|
I think you got my point very well.
|
|
|
|
|
Business needs trump good engineering. Get it out and start the revenue stream ASAP. And plan for quick obsolescence so that we could sell you the next version. It’s all about the money.
|
|
|
|
|
Quick obsolescence is certainly part of it. However there are other factors I believe. For instance, some products are unsatisfactory from the very start. In such cases is more the 'hurry to put the product on the market' factor.
|
|
|
|
|
Either, the great majority of the repliers to your post didn't understand what you were referring to, or, if they did, made rather indirect and obscure followups
Or possibly it is me misunderstanding...
In the days of traditional engineering, you studied the requirements, architected the principal aspects of a solution, then went on to designing how you would build a real world solution, and then, when you knew and had documented how to do the building, you set off to do that.
"Software engineering" today is "Well, let's start with 'int main(void) { return 0; }', and develop it further from that point on. ... Done; we have something running. Now, tell me what your problem is!"
The current plus-word for lack of architecture, design and implementation plan is "agile". Any trace of planning is labeled with the double-minus-term "waterfall method", that noone dares to touch with a ten foot pole. "Documentation" is known as "the source code".
You may (mentally - please don't try it in real life) imagine "agile" building of a new house: Let's start digging a hole in ground, so we can use that as a starting point for a concrete foundation. Once we've got the outer walls in place, we can start making a basement floor plan. Since we don't know yet where we will need water, we will simply label the drilling of a hole through the outer wall for the water pipe as a "technical debt"...
Your new GPS watch, blood pressure monitor, TV soundbar or vacuum cleaner rarely fail mechanically. They fail from extremely poor and uncoordinated software development. Even though I am a software guy myself, I fully support the hardware guys claiming that no matter how good quality the hardware is, the software guys (that is us!) manage to mess it up.
An essential part of it is that SW people generally Know The Answer. They have very little tradition for asking the user about his functional needs, work patterns, terminology etc: The SW guys sit in their ivory tower deciding what the user shall like. For the HW part, they don't look at how the hardware actually works, how it is intended to be used, but go ahead programming for how they think the hardware should work, in their opinion, and then they start bitching when it is different.
I know from personal experience, the most explicit one on a library software project when I tried to bring forth some wishes from the libarians themselves, but was cut off by the project leader: "F**k the librarians!"
Yes, there are exceptions: Some of the really huge corportations became huge by actally working together with users to create proper architectures, designs and implementations. Companies like IBM and MS has used large test panels of users, capturing thousands of hours of video and countless megabytes of logs to decide between different choices. Which open source project ever did that? (Generally, they made a direct clone of a product in the market, and when MS, say, decided from their video captures that a UI change would reduce the frequency of user errors, the open source people bitched because then their clone would be looking outdated until they managed to clone the new UI as well...)
I have rejected a quite long list of free, open source software, and spent hundreds of dollars on commercial products that obviously were developed together with users: Steinberg WaveLab as a sound editor and CD authoring package. Adobe CS for video and photo. SketchUp origniated as a professional tool (I bought it before it was bought by Google and provided for free). For years I fought with OpenOffice/LibreOffice, but had to give up: The software is plain rotten compared to MSO, maybe not in socalled "code quality", but in what it gives me as a user (do I need to say more than "help system" for an example?
And SW people all do it in their own way - even wihtin a single project. I replaced my car radio wiht a modern digital one, offering a zillion functions. Each functional area has a menu system, selection logic, cancel logic etc. completely different from the others (e.g. four different menu systems). Make selections in the wrong order, and the radio locks up. The only way to reset the radio is by turning off the car's ignition: The radio does have a "power off", but only as a software button that you can't get at when it is locked up...
Over the years, I have become more and more ashamed over the typical product quality delivered by my own profession.
|
|
|
|
|
Well, I think I understand your point, that is, roughly, 'unreliable software stuff mess up products'.
What I don't understand is the reason driving companies to put on the market such bogus products. I mean there should be solid engineering methods aimed to the final product trustworthiness (hence applied to both hardware and software).
The final customer usually don't care if the hardware is wonderfully built while, due to software failures, it can't be properly used.
|
|
|
|
|
|
|