dewme

I'm glad to see you hit the industrial design topic very hard. This is one of Apple's core competencies and goes largely unappreciated by those who don't understand full scale product development. Too many neophytes and clueless pundits believe that all the magic occurs in design studio and just automagically transforms into plastic wrapped products neatly packed into tidy white boxes with an embossed Apple logo on them. The great product designers, people like Jony Ive and companies like Apple, don't separate design and operations into walled off enclaves with throw-it-over-the-wall handoffs. They continuously iterate over all phases of the product development cycle from concept, through several design-for attributes, including industrial design, manufacturability (DFM), testability, serviceability, etc.

Viewing design and operations as separate and independent activities is so 1970s. Just look at where software development practice has ended up after 25+ years of believing that design centricity was king. We had structured design, followed by object oriented design, followed by component based design, with GoF design principles thrown in, and some SOLID principles to go with it. Where did all this design-is-king get us in terms of software maturity? How does decades worth of integrated processors produced with horrible security holes, blue screens of death on grandma's laptop, multi-million dollar space probes cratering Mars, an entire generation of defense programs that couldn't get to step 1 because of the prospect of unmanageable defect rates. Maybe design was not really King, but more like a Jack - or a deuce. So where did software development go to soothe their burned egos? DevOps - or development operations, the unification of development (including design of course) and operations. There's reason that companies like Apple can handle huge beta programs, deliver new builds nearly continuously, and address field issues in hours or days versus what used to be weeks or months. Putting together software builds and releases used to be really big deals, now they are routine single click operations with high fidelity traceability as to where all the pieces and parts came from and what test case provided the required verification and validation. Sure, bugs still get out, but when you look at the volume of code that is shipping today versus the defect rates, the improvement is astounding versus the bad old days when design was thought to be our savior.

So yeah, operations is just as important as design, but it's also inseparable from design. 

wood1208 said:

Apple should have offered DTK at lower price and let them keep it. Not sure what Apple will do with returned DTK unless rip off processor,memory,etc from it and use in Macbooks products because of component shortages.

The DTKs were leased equipment, not purchases. In all likelihood, the lease payments are fully tax deductible business expenses for companies who run their development as a business and not a hobby. 

Mr Kiani is exactly correct in stating that the diagnosis of a serious medical condition such as Obstructive Sleep Apnea requires the use of medical grade equipment that has been certified (and quite likely calibrated) for detecting the condition in question. But then he goes on to rail against Apple's pulse oximetry implementation and its limitations when, in fact, Apple has never sought to certify or make any specific claims about the use of their pulse oximetry feature for diagnosing the conditions in question. Basically, he's criticizing Apple for not doing something that Apple specifically and officially claims they are not doing, and rightly, should not be doing at the level of their involvement.   

I do understand Mr Kiani's concerns from the standpoint of defining where devices such as the Apple Watch fall within the larger scope of health care. It's no different than the features in Apple Watch that detect irregular or abnormal heartbeats and heart rates. I have no doubt that many folks who are inside the realm of producing medical grade diagnostic equipment for helping doctors and healthcare professionals diagnose medical conditions have a negative reaction to seeing features in consumer products that may be implicitly seen as being valid medical diagnostic tools by users regardless of the many disclaimers put forth by the device maker. This is a legitimate concern, but it must be put into the broader perspective of individual's participation and awareness of their overall health and wellbeing. 

People are not like a herd of cows whose health, safety, and wellbeing depends on an individual like a medical specialist or doctor who is responsible for their husbandry. Most people are self aware and are responsible for participating in their own health care to a certain extent. If they don't feel well or notice something is "off," i.e., are exhibiting some kind of symptoms, they can and probably should seek the care of a medical professional. Unfortunately there are a lot of symptoms that can go unnoticed by an individual. For example, someone with obstructive sleep apnea may snore very loudly or stop breathing intermittently when they are sleeping. If there is nobody nearby, like a bedmate, to observe the symptoms the underlying condition may go unnoticed and not acted upon, which can lead to other serious health conditions. If their bedmate observes the symptoms, like obnoxious snoring, they can inform the affected person to look into what may be causing the snoring and bring it up with their primary care physician at their next visit.

In the example above is the bedmate a medical grade diagnostician? Unless the bedmate is a medical professional the answer is no. The bedmate is simply an observer who happens to observe something the affected person was unable to detect on their own, in this case because they are sleeping. Even if the bedmate observer was a medical professional they would still steer the affected person towards a medical professional who can properly diagnose the affected person's condition using all of the certified tools at their disposal. There's a huge difference between an observer and a diagnostician. The observer merely collects data. Turning data into information and subsequently turning information into action and response via diagnostic procedures requires additional context and appropriate reactive activities, including the application of medical grade measurement and diagnostic equipment and the consultation with other professionals. 

The Apple Watch is an observer that is capable of capturing, even if on a limited or intermittent basis, health related data that could otherwise go unnoticed by the wearer. No more, no less. The Apple Watch does not elevate the interpretation of the observed data and it most certainly does not attempt to diagnose the underlying condition. As a caring and responsible observer it does steer the wearer towards seeking professional help. When viewing healthcare from a holistic perspective, one that involves personal awareness and participation, and in concert with all of the other formal and professional layers, it's doing exactly what it can do and should do at this point in its evolution. 

All software seems to follow a common lifecycle model over time. As more bugs are addressed by more and more developers who were not part of the original design team it starts to accumulate a lot of cruft and quick fixes and workarounds to meet release deadlines. This accumulation of cruft, crud, and crappy shortsighted quick fixes is collectively known as “technical debt” because the current software team has literally taken out a bad loan to buy a bunch of shitty workarounds that some future team of maintenance developers is going to have to pay for, and pay for at loan shark interest rates.

When developers occasionally grow a little piece of spine they get up in front of management and talk poignantly about the dire need to pay down some of their technical debt, perhaps using “refactoring” or redesign, or god forbid, rearchitecting of the current code base. At some point in the spiel the management team challenges them with something to the effect of “so you’re saying you want us to spend a bunch of man-years of development resources, a boatload of money, and so many millions of dollars, and so many months of schedule to give us a refreshed code base that does pretty much what the old code  does, but without the hanging chads and dingleberries?”  At that point the little piece of developer spine turns to jelly with a “well yeah, pretty much.” So much for grandiose plans. The end result is that not only is the trash can of technical debt kicked further down the road, but the development team is tasked with adding a bunch of new money-making features on top of the shaky foundation that is like a rickety bridge waiting to collapse. Of course the new features introduce more technical debt and have to work around the shortcomings caused by the underlying technical debt. 

It’s rather easy for a startup like Tesla to feel emboldened by their software prowess because they haven’t had time and customer volume enough to suffer the indignities that accumulate over time when you’re serving a billion customers around the world and have the second and third generation removed teams poking into a business-critical code base that is handed down to them, a code base that is tied to business revenue that has to keep flowing no matter what. Designing new software is usually fun and rewarding. Maintaining existing software is usually a grind and a thankless struggle. Technical debt is like a slow growing cancer, but as long as the supply of band-aids, duct tape, and baling wire is cheaper in the short term than excising the tumors they’ll keep adding on more layers of bandages until they are forced to blow it all up and start over again. Or maybe buy a bunch of software and people through an acquisition.        

gatorguy said:

Thread was a very underappreciated invention IMO. I'm honestly surprised it's taken so long to gain traction. Outside of Nest devices I'm not aware of other high-profile devices using it so good on Apple including it with the new Mini. Perhaps that means Nest devices may soon be Homekit friendly. 

 Home automation should be much more straightforward than it has been and Thread will be a major part of making it so.

The main benefit of Thread is that it is IP based (IPv6 in fact), while ZWave Plus and Zigbee each employ their own non-IP protocol that requires a gateway/bridge to connect their unique protocols to IP based clients and other nodes. The use of IP has major benefits with respect to things like device discovery, device identity, connection management, and routing because everyone is speaking the same language. Bridging across protocols always introduces more complexity and delays because the intermediary (gateway/bridge) has to be a fully functioning node on both networks at the same time. It's far more than simply language translation, it involves things like managing communication timeouts, node health status reporting, maintaining routing tables, etc,. or basically doing everything a node has to do to be a good citizen on a network - times two.

Having IP everywhere simplifies everything and positions Thread very well for the emerging IoT challenges and opportunities.   

All three of these networks are mesh based, have device profiles to allow auto-configuration, employ self-healing techniques, have accommodations for optimizing their use with battery operated devices, support range extension, and have encrypted communication, so none of those things are really differentiators. The special sauce for Thread is the use of IP and the fact that it builds on 6LoWPAN, which has some degree of maturity.

I must add that one recurring challenge with device networks is that there are always too many standards from the customer's perspective. Despite claims of being a "game changing" new standard, the new standard rarely replaces all of the existing standards. Instead, it typically fragments the market even further. Every single time I've seen a new "one standard to replace all standards" come along, which I've experienced several times over a few decades of being involved in similar standards, the end result is that standard A and standard B do not go away or get replaced by standard C. You end up with standard A and standard B and standard C. In fact, standards A and B will even update and improve their standards over time to make them less vulnerable to being obsoleted. The end results is usually: Dear customer - please pick one, and can I interest you in a nice gateway? 

Pretty amazing for a 1.0 product ... but the price is going to scare away a lot of regular folks. 

When I see “bad” in the title I equate that with a functional deficiency. Maybe “overpriced” or “ridiculously overpriced” or “a bad deal” would be more appropriate since the cables do work as intended, but at a price that only true believers would find acceptable.

This is a bit of a spin and wordplay because they are focusing primarily on performance and efficiency and glossing over the reality that the size of running applications working sets cannot be ignored. Yes, having very fast backing store improves memory virtualization, i.e., swapping, but it’s still not as fast as having more real memory available.

They can certainly say that they are getting superior performance and efficiency with 8 GB compared to other competing platforms or architectures running with only 8 GB. But if you’re doing an Apple Silicon-to-Apple Silicon comparison and you would benefit by having 16 GB available due to the combined working set of your running applications, the benefits of having more memory available are real and there is no equivalence  between 8 GB and 16 GB.

Apple Silicon effectively rebases my expectations. I already know it’s better on so many levels (but not all) than other platforms. I don’t want to compare it to lesser platforms. Upping the base level Unified Memory to 16 GB would make the Apple Silicon argument even more pronounced, no song and dance required. We’re paying a premium for choosing Apple, so why not make the perceived value and useful lifetime of the products stand out from the crowd even further? Software is not getting smaller.