It's a bit disappointing that with iOS12 as a maintenance release rather than feature release, they managed to introduce so many issues with iOS13 which arguably should have had a stable base from iOS12 to build on.
I think the rigorous annual release schedule doesn't help the bug problems. They need to decouple the iPhone hardware releases from the major iOS release, because it means the OS is rushed out to support the new phones, even if it's not ready. New Macs just have a special version of macOS - and always have done, even in the OS 7.x days. Software is done when it's done, it's not something you can really speed up by throwing people at it, the only thing to do is have a feature freeze earlier in the year. And since features are generally set in WWDC (and even then they still drop some usually) they need to have have WWDC earlier, or less features, to give time for more testing.
I don’t like that idea at all. A major benefit of iOS is that every new product receives the latest OS. On Android, you almost always get a phone with an older OS, and can wait anywhere from weeks, to a year before getting the one that was current when your phone came out. You’re always behind. And then, updates stop, usually after that first one.
a big problem is that an article I read years ago, before phones were getting any OS upgrades, said that the problem with bugs, and this was about traditional personal computers, was that consumers would rather get buggy software with new features, quickly, than much less buggy software, where new features came slowly.
this is in opposition with mainframe computing where new OS updates can be tested for years before being released, and where companies spend tens of millions of dollars for a 5% hardware performance improvement, every few years. Stability is expected there, but not in consumer devices.
yes, I know that some people say they would be happier if everything slowed down, and things were much more stable. I can’t disagree, on a theoretical basis. But competition abounds. And if Apple slows feature releases down, there’s no guarantee Google will. That will result in more unhappy customers than happy ones. Apple is often accused of being behind in features as it is, though it’s not really true, as that accusation is a very selective one.
Time to bring Forstall back as Chief Software Technology Officer. He worked for Steve for almost 20 years and knows Apple’s software inside out.
Well, he was responsible for the Maps debacle, and was disliked within Apple, so—no.
"and was disliked within Apple"
That would depend on who one talked to. He was well-liked by the iOS teams, the other teams not so much. From my understanding from Tim Cook's memo, one of the major reasons he was fired was due to creating a dividing wall between iOS teams macOS teams.
So he was empire-building.
Just as well he was given the push then.
He was very specifically accused of that from a number of people in Apple. Some of my own contacts were very unhappy with him, accusing him of being dictatorial, and not open to suggestion, or criticism.
we should all be amazed these things work as well as they do.
Not really, I say this as someone who's working with Catalina production version on a 2016 MacBook Pro which KEEPS verifying every single app before use and sometimes during use.
It's clear during the beta process every summer that there's something wrong with the way they push out code to builds, this confirms it (good work AI).
That’s ridiculous. Unfinished code or known buggy code should never be checked into the daily build. That’s software development 101. Something is seriously out of control if developers have been checking stuff in prematurely.
This is the problem with Agile processes. You end up with one line drawing masquerading as requirements which leads to shipping code that was barely tested.
This can actually work if you have REALLY good QA. But QA is ALWAYS the first thing to get cut when the schedule runs out of time.
Agile does deliver software MUCH faster than waterfall where you spend a year writing design documents that are outdated and wrong before you ever start coding. But like everything else in life there are trade offs.
If Apple went to a 3 year release cycle on iOS it would be absolutely rock solid. But you still wouldn’t be able to browse the web while you were on the phone.
TANSTAAFL - There Ain’t No Such Ting As A Free Lunch.
This is why it has taken a decade to build new manned space capsules. Conversely it is why 346 people died on 737 Max jets plummeting from the sky.
Apple went to agile when Craig joined and I think that it has in fact reduced quality. Artificial sprints force early releases. There is always a 2 week cycle or so. You have to justify your day every day. This heads to early releases.
In the days before sprints you went away in your room (also gone in the new campus) and released your feature when done. In fact if I recall there used to be testers per project in Apple. Embedded testers on a team would get released versions of the local product (ie mail, Xcode or even lower level frameworks) and it would be committed to the build when verified on a local build. I’m sure that could be done on iPhones.
this doesn’t excuse the testers though. The background app issue should be obvious.
Waterfall never existed much, if at all, by the way. The agile processes are tilting at windmills that never existed.
That’s ridiculous. Unfinished code or known buggy code should never be checked into the daily build. That’s software development 101. Something is seriously out of control if developers have been checking stuff in prematurely.
This is happens when people with no engineering background become the senior management at a tech company. At least Jobs was familiar with the challenges of engineering hardware / software. Cook is a process guy (how to build / distribute things) and not really familiar with engineering. He wouldn't know a resistor if you threw one at him.
The fact that things got to this point at the biggest tech company in the world is staggeringly alarming. Tim, less streaming and more engineering, eh?
Time to bring Forstall back as Chief Software Technology Officer. He worked for Steve for almost 20 years and knows Apple’s software inside out.
Yep, they should do that now that the prima Donna Ive is gone. I would also say they need to replace Cook with a real (hardware) product guy so we don’t get the designers dictating crap like the 2013 MP and the butterfly keyboard fiasco. I used to think that Federighi would/should be the next CEO but the iOS mess has invalidated that idea.
That’s ridiculous. Unfinished code or known buggy code should never be checked into the daily build. That’s software development 101. Something is seriously out of control if developers have been checking stuff in prematurely.
This is happens when people with no engineering background become the senior management at a tech company. At least Jobs was familiar with the challenges of engineering hardware / software. Cook is a process guy (how to build / distribute things) and not really familiar with engineering. He wouldn't know a resistor if you threw one at him.
The fact that things got to this point at the biggest tech company in the world is staggeringly alarming. Tim, less streaming and more engineering, eh?
If you think Tim Cook isn’t an engineer you seriously don’t know his background and why Jobs recruited him. He is one of the best industrial engineers in the world.
AI, headline should read: “Apple allegedly...” because it’s a rumor. Framing it as fact the same way actual factual stories are does a disservice to readers.
Are you taking issue with Apple reorganizing its software development structure, or the insinuation that iOS 13 was something less than absolutely perfect? The number of bugs in iOS 13 and Catalina is well known. Besides, as Gator said, the 3rd word of the article is 'allegedly.'
Whatever it takes I’m good with. I just asked Siri to speak screen for this article and after a few lines she started reading it in a language I’ve never heard before.
AI, headline should read: “Apple allegedly...” because it’s a rumor. Framing it as fact the same way actual factual stories are does a disservice to readers.
First sentence reads "Apple is allegedly adjusting how it develops its operating systems internally..." and the source article words it as "according to people familiar with the shift". Neither one states it is a fact. As for the headline it is just that. You always have to read the accompanying paragraphs for an explanation and details no matter who writes it.
He was specifically talking about the headline which is dressed as a statement of fact. If I read headline then I expect it to reflect the story, so if it’s a rumour then they should say so in the headline, and if they’re sourcing a story from Bloomberg then they should say so in a 40-point font.
Time to bring Forstall back as Chief Software Technology Officer. He worked for Steve for almost 20 years and knows Apple’s software inside out.
Well, he was responsible for the Maps debacle, and was disliked within Apple, so—no.
"and was disliked within Apple"
That would depend on who one talked to. He was well-liked by the iOS teams, the other teams not so much. From my understanding from Tim Cook's memo, one of the major reasons he was fired was due to creating a dividing wall between iOS teams macOS teams.
So he was empire-building.
Just as well he was given the push then.
He was very specifically accused of that from a number of people in Apple. Some of my own contacts were very unhappy with him, accusing him of being dictatorial, and not open to suggestion, or criticism.
Which ties in with his refusal to apologise for the mess he made of Apple Maps.
Folk who whinge on about bringing back Forstall need to realise p that wearing a black polo neck doesn’t make him Steve Jobs.
What’s being proposed as a process improvement sounds to me like putting a band aid on an open chest wound. Allowing builders or testers to selectively turn features on and off is a delaying tactic that builds a false sense of accomplishment during testing. The absolute best thing that developers and testers can do during their unit, integration, and build testing is to crash their code when it encounters a critical error and use a debugger to discover the root cause of the crash. Fail fast and fail early. The worst thing a developer or tester can ever do is to do anything that will mask errors or delay having to deal with critical errors immediately, i.e., kicking the can down the road.
Allowing testers or builders to selectively turn features off in hopes of “making progress” against a test or release schedule may result in critical errors/bugs being addressed later rather than sooner. The cost of fixing bugs increases exponentially the later they are dealt with. Not 2X, not 3X, but 100X or worse. From a software architecture perspective having features in the codebase that can be selectively turned on and off, whether as part of the build process, in a config file, admin settings, or in the runtime environment is a recipe for disaster. Release software should have zero dead code. Building software has to be a very intentional endeavor, with 100% commitment to releasing a product that does exactly what it was designed to do. Any time and effort put into speculative features that are sloughed off late in the cycle because they don’t survive the quality gates is a waste of time, money, and human capital.
Agile software development is neither inherently good nor bad. It always comes down to the execution of the strategy and the appropriateness of the strategy for solving the problem at hand. The textbook and one-week long agile training class flavor of agile has serious issues with scalability. Scaled agile addresses some of the scalability shortcomings, but it’s not a panacea. The biggest problem with Agile or Scaled Agile (SAFe) is the same as the biggest problem with other heavily promoted software development processes - those who are stakeholders in the process are never on the same page with respect to expectations. The first time a senior executive hears that Agile is going to reduce time to market and/or reduce development costs while improving quality their eyes glaze over as they swallow the kool aid and apply staff and budget to exploit the supposed improvements. A year or two into the execution of the process not much has changed and disillusionment sets in. The sad thing is that this over promising and under delivering pattern has been repeated time and again in software development.
I wish there was a clear path forward. But software development has never been and will never be a true engineering discipline backed by mathematical principles and absolute constraints like electrical or mechanical engineering. Software is a machine executed expression of human intellect and humans are inherently flawed. Developing solid software is more about compensating for the inherent flaws that humans are prone to express, enforcing artificial constraints, and taking a very pessimistic view of any assertions of correctness. Also, don’t miss Steve Jobs' very telling discussion with Robert Cringely regarding the competency gap between good software developers versus average software developers.
AI, headline should read: “Apple allegedly...” because it’s a rumor. Framing it as fact the same way actual factual stories are does a disservice to readers.
First sentence reads "Apple is allegedly adjusting how it develops its operating systems internally..." and the source article words it as "according to people familiar with the shift". Neither one states it is a fact. As for the headline it is just that. You always have to read the accompanying paragraphs for an explanation and details no matter who writes it.
He was specifically talking about the headline which is dressed as a statement of fact. If I read headline then I expect it to reflect the story, so if it’s a rumour then they should say so in the headline, and if they’re sourcing a story from Bloomberg then they should say so in a 40-point font.
Point me to newspaper headlines that start with "according to rumor". Read what the purpose of headlines are as you plainly don't know, then come back and criticize the AI editor again if you think he should handle it differently than print media has for decades. http://www.smartmoneydaily.com/diy/4-functions-of-an-effective-headline.aspx
Whatever it takes I’m good with. I just asked Siri to speak screen for this article and after a few lines she started reading it in a language I’ve never heard before.
Whatever it takes I’m good with. I just asked Siri to speak screen for this article and after a few lines she started reading it in a language I’ve never heard before.
Time to bring Forstall back as Chief Software Technology Officer. He worked for Steve for almost 20 years and knows Apple’s software inside out.
Well, he was responsible for the Maps debacle, and was disliked within Apple, so—no.
Steve Jobs was disliked by most people he insulted, and he too made mistakes. Yet no one would say Apple was better off without him. It's also interesting to reflect on the story of how Steve Jobs literally saved Scott Forstall's life. He's been away from Apple long enough for him to Think Different. And goodness knows Apple has been Thinking Different since the death of Jobs, and not all for the better. (Wherefore art thou, SD card slot, on MacBooks called "PRO"?) I say bring Forstall back. Apple needs a good kick in the pants and he has the grit to do it, especially while Cook is out playing politics most of the time now. I like Apple like the rest of you, but I'm no yes-man who worships the status quo in Cupertino. It's time to rock the boat.
Time to bring Forstall back as Chief Software Technology Officer. He worked for Steve for almost 20 years and knows Apple’s software inside out.
Well, he was responsible for the Maps debacle, and was disliked within Apple, so—no.
"and was disliked within Apple"
That would depend on who one talked to. He was well-liked by the iOS teams, the other teams not so much. From my understanding from Tim Cook's memo, one of the major reasons he was fired was due to creating a dividing wall between iOS teams macOS teams.
So he was empire-building.
Just as well he was given the push then.
He was very specifically accused of that from a number of people in Apple. Some of my own contacts were very unhappy with him, accusing him of being dictatorial, and not open to suggestion, or criticism.
Which ties in with his refusal to apologise for the mess he made of Apple Maps.
Folk who whinge on about bringing back Forstall need to realise p that wearing a black polo neck doesn’t make him Steve Jobs.
Comments
a big problem is that an article I read years ago, before phones were getting any OS upgrades, said that the problem with bugs, and this was about traditional personal computers, was that consumers would rather get buggy software with new features, quickly, than much less buggy software, where new features came slowly.
this is in opposition with mainframe computing where new OS updates can be tested for years before being released, and where companies spend tens of millions of dollars for a 5% hardware performance improvement, every few years. Stability is expected there, but not in consumer devices.
yes, I know that some people say they would be happier if everything slowed down, and things were much more stable. I can’t disagree, on a theoretical basis. But competition abounds. And if Apple slows feature releases down, there’s no guarantee Google will. That will result in more unhappy customers than happy ones. Apple is often accused of being behind in features as it is, though it’s not really true, as that accusation is a very selective one.
He was very specifically accused of that from a number of people in Apple. Some of my own contacts were very unhappy with him, accusing him of being dictatorial, and not open to suggestion, or criticism.
It's clear during the beta process every summer that there's something wrong with the way they push out code to builds, this confirms it (good work AI).
In the days before sprints you went away in your room (also gone in the new campus) and released your feature when done. In fact if I recall there used to be testers per project in Apple. Embedded testers on a team would get released versions of the local product (ie mail, Xcode or even lower level frameworks) and it would be committed to the build when verified on a local build. I’m sure that could be done on iPhones.
this doesn’t excuse the testers though. The background app issue should be obvious.
Waterfall never existed much, if at all, by the way. The agile processes are tilting at windmills that never existed.
Anyone want to bet how many devices will be abandoned by iOS 14, when it’s now “the last hope of stability and bug fixing” for some users?
http://www.smartmoneydaily.com/diy/4-functions-of-an-effective-headline.aspx
https://macperformanceguide.com/blog/2019/20191124_0835-iOS13-fiasco.html
https://www.macobserver.com/columns-opinions/editorial/apple-intersection-of-technology-liberal-arts-doesnt-include-elevator-music/
With the exception of macOS 10.14 & iOS 12, it feels like the quality of OS releases has been like a roller coaster ride since Forstall left.