I have a slightly different perspective (I worked on iOS 7 - 11). One of the things about Apple that's different to many of the other tech conglomerates is that engineering teams are given huge freedom to work the way they want (for better and for worse). Because engineering is so fragmented you should always take what one person says about the process with a pinch of salt.
So that means there are hundreds of source repos, patch review systems, and the like. When I was there I saw teams using Phabricator, GitLab, GitHub, plain e-mailed diffs, and more. In the same way EPMs and project process varies massively across teams, so what that employee experienced is by no means the norm. Certainly I didn't find this to be true at all:
> Nothing could be worked on if it wasn’t in Radar with a priority number attached and signed off by the teams’ EPM. No room for a side project or time away from your daily duties because there were always P1s to fix.
In fact, I worked on a major feature that was keynoted one year that came out purely because of my side project work. If anything it was a frustration to enter the "real world" where PMs had so much more power and influence than they did when I was at Apple (where PMs didn't really exist, and EPMs existed only to manage project timelines and drive features that HI / ID came up with).
Based on your experience there what would you say is the cause of the recent slip in software quality in both iOS and macOS? As an outsider it looks to me like they're just pushing too hard to keep up with a yearly release schedule but that's based on no inside knowledge at all.
> Based on your experience there what would you say is the cause of the recent slip in software quality in both iOS and macOS?
It's not clear because there have been absolute shit-show releases going back to the early days of OSX. Even the fondest-remembered releases were only so after a ton of polish, and that was with releases slipping significantly (you might see 3 years pass between major updates, and the new version would still be completely unstable).
I'm sure yearly releases don't help, especially if there isn't a postgres-type culture of "we ship what's ready", but software engineering issues at Apple go back a long time.
What has definitely changed is the pace with which people are expected to upgrade. When OS X Snow Leopard came out, you had to visit a store to buy the DVD. Nobody would look down on you for running a "legacy OS" if you only upgraded when .3 was out.
The ways in which this has changed affect both tech-savvy and casual users:
1. Older versions of iOS (which didn't exist back then) don't receive security fixes, so the only way to stay safe is to upgrade within days of the initial release (ideally before Apple publishes its security KB article).
2. Older versions of macOS often lag behind when it comes to security fixes. There is no clear policy on whether it is safe to stay on release n-1. Apple needs to be nudged to even document macOS security issues[1]. If you are moderately paranoid about security, you have to install all updates on day one (as on iOS).
3. iOS and macOS automatically download OS upgrades and nag you to install them.
4. There is a narrative on community sites that Apple's products are only good because Apple relentlessly kills legacy code and features (I don't even agree with the latter part). Dropping support for anything older than a year is considered a badge of honor because it means there will be "progress". The more paying customers you inconvenience, the edgier you are.
5. Apple feeds into this "old software is bad" meme by publicly LOLing at Android's adoption curve every year.
6. Emoji. I wish I was kidding, but only seeing squares when other people go out of their way to express their emotions is actually annoying.
7. If you are already on an OS that is buggy, you are more likely take the plunge and update to a brand-new OS in the hope that this time, things will be better.
> 3. iOS and macOS automatically download OS upgrades and nag you to install them.
This annoys the hell out of me. So much so that I feel like throwing the device every time it happens. What a waste of energy, storage, and network data limits! I've had to delete the iOS 11 download on my device manually several times already. I make sure WiFi is off whenever I'm charging for fear that it would automatically install the update too (not sure about this) and would not be able to revert back.
If anyone on the iOS team is reading this, I'm not moving out of iOS 10 unless you provide a way to turn off the WiFi radio from Control Center (not just disconnect from the network and connect automatically when I'm in a different location, which is not what I want). And also fix the slowness issues with iOS 11. I have it on an iPhone 7 and the performance is bad. I can't spend several hours erasing the device, reinstalling the OS and re-downloading all the apps (several tens of Gigabytes) once again now that you've not only removed app transfer and sync with iTunes but also removed the apps section from it. Stop assuming things about people's connectivity and data transfer quotas and start designing for real users!
Using an Apple device has never been so frustrating for me like it has been in the past two years.
When Snow Leopard 10.6 came out in August 2009, it only supported Intel Macs, which were at earliest from January 2006, about three and a half years earlier. Typical Mac OS X releases up to El Capitan (september 2015) supported 10 years of Macintosh computers. Sierra/High Sierra still do, essentially.
The support for older machines depends on multiple factors, like the multi-year transition from 32 bit to 64 bit for the OS, including 32 bit EFI, 64 bit EFI, etc. Some older machines were not supported by newer releases (not talking about security patches) for longer than five years, IIRC. That's a long period of time, but still quite short when compared to Windows support of older machines during that time (this is not a great comparison because of differences in annoyances and quality in the OSes, but more about the companies' work).
Right, but engineers probably are going to have some level of conviction and judgement when it comes to something they helped build. They're personally invested in a feature they've worked on.
If I was an engineer at Apple who worked on iMessage, and I heard acquaintances talk about the bugginess about iMessage, I would probably start out being defensive but then I would regret that we didn't ship a better product.
I think an EPM is less likely to feel like that, as they are not so closely tied to the actual product, which is what the Reddit poster was saying.
It's easy to blame "the other". Having worked at Apple I never felt like it was the EPM causing quality issues for us. It was us setting an aggressive schedule ourselves and, more importantly, having poor testing. The EPM was mainly just making sure tasks didn't get missed, reprioritizing them as the schedule moved based on discussions with managers & other engineers etc. Sure at some point in the schedule the central EPM committee for a release would start locking things down & punting less critical issues, but that's something that's done for every single release even for engineer-driven companies because you have to ship at some point.
Keep in mind also that these EPMs themselves tend to be fairly competent engineers in their own right so these aren't MBAs making decisions, they've just moved on as their career evolved. They care about quality just as much as anyone. The difficult part is making the call of cutting a feature especially if it's a keynote feature because there's just not enough time to actually ship it because that's predicting the future. Another difficult call is what bug constitutes a delay of an OS release, especially when the bug report may not have the necessary details to indicate it might be more critical than it seems.
TLDR: It's not as easy as saying it's all the EPMs fault. There's plenty of blame to go around because nobody is perfect & predicting the future (which is what scheduling is) is very hard.
It's really hard to put any single root cause on it. Firstly, mobile OSes are massive beasts with lots of different teams working on it. Co-ordinating this becomes very difficult. Additionally, you typically get about 1 build a day which means there's a long lead time to find a bug that's managed to propagate out and then a long lead time for it to get fixed (at least 1 day). I think this decrease in quality has been seen across all OS vendors, it's just that Apple has become one of the dominant OSes so there's more press about it than there was about previous Apple releases.
So now you have a larger volume of bugs since bug count is based on the amount of code written, assuming best case that developer quality is roughly consistent across all teams. Since you have a larger volume and only so many hours in a day, trying to ship all software at once at an annual cadence means your bug count will go up regardless of how much QA you throw at the problem (since in addition to finding issues you have to fix them).
Automated testing might help because you could catch bugs before they're even submitted. Well, automated testing is still very hard on these devices when you're building the OS. For example, how do you do something as simple as build & run unit tests? If the answer involves loading code onto a mobile device that means (at Apple scale) you need a farm of devices. Moreover, your test isn't valuable if it's running against yesterday's OS. Might not even build/run because you've now acquired a dependency on an API made available in the new OS. So now you have to co-ordinate building the software using an SDK that may be unstable (build breakages happen), run it on an OS you somehow have to pre-validate works otherwise & then have some confidence that the bug found was introduced by your commit & not some combination of build issue, compiler bug (oh yeah - the compiler changes drastically too while your building your next OS), or downstream dependency bug. Finally, on top of all this you need to make sure you can recover bricked devices in an automated fashion so that the maintenance overhead of your automated testing cluster is manageable. All of these aren't impossible problems to solve. The problem is that it requires a lot of effort & physical infrastructure. Additionally, Apple has had a very ad-hoc development environment where no 2 teams are the same (it was slowly changing to unify large pieces of infrastructure when I left) which complicates the ability to roll out central infrastructure. Additionally, there are different needs - the kernel has different testing requirements/strategies from system daemons, from drivers from 1p apps from backward compatibility testing.
When I left a couple of years ago Craig had actually directed his teams to improve the automated testing infrastructure but at the end of the day the software is growing more quickly than the investment that was made in QA. There's also only so quickly you can roll out central automation infrastructure to an organization as large as Apple so it's not as simple as "do more QA" or "add more QA resources" not to mention that "QA resources" in automated testing typically requires very skilled software engineers to design & build the systems. Allowing a longer bake time is exactly the right move here as it recognizes the need to decrease the volume of bugs while infrastructure catches up.
However, the contradiction is that single giant releases help in three ways. The first is it enables you to make 1 big splash of a years worth of work to customers rather than it being dribbled out of the course of a year across different components, which is super important because it dove-tails into the release of the next flagship phone. It also makes the messaging because you can build themes for your releases that are co-ordinated across many apps/services.
The second is that it co-ordinates large-scale changes across the company (e.g. major UI redesign, some major UX improvement, etc) which would be more difficult to co-ordinate with smaller releases or if apps were split out.
The third is that leaks/previews can be better controlled as managing a bunch of different releases that contain functional differences is harder than just maintaining bug fixes (i.e. prepping UI changes for 50 different apps that are released throughout the year in preparation for the next OS that makes it possible for those apps to run).
Finally, it simplifies development in a sense because you don't have to worry about 1P backwards compatibility. 1P apps don't have to worry about supporting more than 1 OS and OS changes can confidently break 1P apps (within reason) with new APIs without worrying about apps that haven't been updated. The latter part about breaking apps doesn't matter as much if the apps are bundled with the OS unless those apps can also deliver updates via the App Store as now you have to launch vehicles that can be tricky to co-ordinate.
Yes, a lot of this is pure business reasons for why the SW is co-ordinated but that doesn't mean that it's not valid. Business practices & SW are symbiotic aspects of a tech company as neither can exist without the other. Everything is a list of tradeoffs and priorities. Apple is apparently first experimenting to see if they can keep all the business pros of their current approach by altering their program management practices which they've already done - iOS & OSX today have far more dot releases in 3 months than they used to between major versions. Reducing scope is the approach they're taking in the interim to make the major releases more stable - will be interesting to see if this is a long-term shift or just an interim one until their QA infrastructure investments catch up to be able to keep up with development. If those approaches fail & the brand becomes at risk that may outweigh the other business reasons & result in independent app & OS releases (seems unlikely IMO).
Hmm... I think Kim came in towards the time I was leaving. Last name? When I was there our immediate QA was embedded within SW & reported up through the SW chain. Craig took over all OS SW development early 2015 IIRC. Have things changed? FWIW software quality of iOS has always been a concern in the media and I don't see that iOS 11 is particularly better or worse than other releases. iOS 8 had horrible performance issues for example to the point where iPhone 4S lifetime had to be artificially extended to iOS 9 instead of being EOL'ed in iOS 8 as originally planned. Every release has had its own share of embarrassing/severe bugs. Except for maybe iOS 1.0 which had no 3P features, a very small feature-set, & no competition to be evaluated against, each iPhone release has always been received as having stability issues, at least initially.
> The iOS 5 update was the subject of criticism for iPhone 4S users, as the upgrade caused problems with battery life, failures of SIM cards, and echoes during phone calls.
https://en.wikipedia.org/wiki/IOS_5
> A study by Apteligent (formerly Crittercism) found that the rate at which apps crashed in their tests was 3.56% on iOS 8, higher than the 2% found on iOS 7.1.[81]
> Forbes published several articles focusing on problems in iOS 8 regarding Wi-Fi and battery,[82] Bluetooth,[83] and calendar.[84]
https://en.wikipedia.org/wiki/IOS_8
Except for iOS6 & 7 which appear to have had a milder reaction, if anything I think iOS 11 may be a more stable release compared to iOS 8, 9, & 10 in that while there are more frustrating UI bugs you can hit (auto-correct, iMessage message ordering) but the overall performance & stability hasn't suffered as badly. Also iOS has knock-on impressions from OSX stability which has had similar UI embarrassments + a couple of security-related missteps.
My point is I don't think there's any single particular cause that's identifiable as the reason behind poor SW quality. If it were the hundreds if not thousands of really smart people Apple employs would have solved the problem. At this point it's all higher-level issues & more often than not tradeoffs (e.g. reducing the features you ship every year & going away from a waterfall development model)
When I've seen "always follow priority order," it's always been somewhere between "[wink wink] that's a good idea, figure out how to link it to the top-priority stuff" and "all priorities are negotiable" anyway. Was your experience similar, or just more of a team truly without external priority ordering?
Do you think some level of standardization of process would help apple as a whole? Would it help eliminate the relatively poor experience of reddit-OP?
I think it's both a blessing and a curse. On the one hand it makes it very easy for teams to find an approach that works for them, and does away with a lot of bureaucracy.
On the other, it promotes a lot of inefficiencies (I knew of at least 8 separate instances of Phabricator being used by different teams), and makes it very difficult to centralize core tooling and operations. It also makes it very hard for engineers to have internal mobility (you typically would have to do a full interview loop as an internal transfer, which is in stark contrast Google / FB's approach).
When I left there was talk of centralizing more tooling to attempt to alleviate some of these issues, but I don't know if any progress has been made since then.
There have existed teams at every company I have ever worked for who argue that this is the Very Best Way (tm) to develop code. It allows for the True Gatekeepers to keep their hold over the perceived software quality and quickly routs any sort of outside interest from modifying the project in any way the True Gatekeepers don't desire. In entirely broken organizations this is an effective way to allow 2-3 good developers to produce software in spite of the culture. In any organization beyond entirely broken, this prohibits a team from scaling beyond 2-3 key core members and tends to allow that small group to become the BOFH, maintaining a reign of terror over all non-blessed developers, regardless of seniority or title, who dare contribute to the product. In some senses this is the Linus "benevolent dictatorship," but in most, it's a despotic system that collapses as soon as one of the core contributors moves on or retires.
In my experience most attempts to move these sorts of teams towards real revision control and development practice lead to an extinction event in which they practice every form of hazing possible to maintain control, requiring careful management. Think extreme code-format nitpicking (combined with a lack of automated tooling or a styleguide that would let "others" get it right), followed by appeals to whichever authority maintained their team, outright hostility, and eventually ultimatum or holding the code hostage.
But how is emailing different from something like eg. Gerrit or pull requests. Ultimately, it's always the maintainers who get to decide what gets into the repo.
What you describe is a problem occurring independent of the way changes are merged. I agree that it can be a real problem.
I think your sibling post is similar in sentiment and it comes down to transparency. In the "patches-to-a-list" model, there's no running status page or record of exactly what patches were rejected or ignored, and by whom. Anyone wanting that information would have to go to a lot of work parsing, searching, and analyzing the mailing list.
With Gerrit or pull requests, reviewers are clearly assigned and patch states are managed in a centralized dashboard. This makes it a lot easier for external stakeholders (managers, other development staff, etc.) to gain insight into how a team's working and whether or not they're being accepting or effective. And that's why, to me, these kinds of toxic maintainers seem to suffer an extinction event when moved to a more transparent system. The maintainers are the same, but their tool - quietly rejecting patches with little accountability - is taken away from them.
Git itself is developed this way, so saying it could be fixed by "real revision control" is silly. Maybe you worked with someone who misused this model, but there's good reason Git and Linux use it.
Git hasn't been run by Linus for over 10 years, and uses this workflow. Is it flawed in some ways? Sure, but it works and has its advantages.
Furthermore the way patches are submitted, discussed and reviewed has little to do with the process by which they're eventually accepted or rejected by a BFDL maintainer, unlike what the GP is claimnig.
If the kernel used say Github pull requests you'd just have Linus rejecting some of those instead of refusing to accept patch serieses submitted by E-Mail.
The GP is just railing against some bad experience with the "True Gatekeepers", as if a company that was dysfunctional enough to use E-mailed patches as some unreasonable filtering mechanism wasn't able to do so via other methods.
The advantages of the E-Mail workflow is that it's fully distributed (aside from the ML hosting), bug/patch discussion can naturally flow into one another, everyone can use their favorite client that they can script etc., and you don't need an active network connection to participate (do all your patch review on the plane), all as opposed to using some opaque web UI.
The advantage of the Pull Request system is that it lends transparency. Especially in a corporate environment, a team can easily ignore and reject a lot of code sent to a mailing list. When each patch is tracked using tooling built for that purpose, this gets a lot harder.
Yes, the BFDL maintainers can continue to operate in whatever system they're given, but the more transparent the system is, the more likely they are to be discovered and the issue corrected.
I do agree that the E-mail workflow offers (a few) advantages, but the lack of inherent transparency in the tooling tends to be quite troublesome. It also doesn't inherently offer easy integration with automated testing systems or easy audit and compliance logging.
I certainly wouldn't recommend it for most situations, especially something like a corporate environment where most people have problems with basic E-Mail workflows like inline quoting and preserving In-Reply-To headers.
It's more suited for free software projects like Linux & Git where the participants don't want to be locked out of all their historical discussions just because some company does badly in the stock market, as opposed to being 100% archived in hundreds of places via an open protocol, and trivial to migrate somewhere else.
I'm just saying the problems you had with it seem to come down to a completely dysfunctional corporate culture, not patches over E-Mail.
Sure if you're working with such monumental assholes that they're just going to passive-aggressively and conveniently discard whatever you tell them over E-Mail / IM / at the water cooler that's pertinent to their work area and need to essentially CC their manager on all correspondence, and are using PRs as a way to do that.
Then sure, then an E-Mail-based workflow probably isn't for you, although you could use git-format-patch to CC both your and their manager on every patch you send to achieve similar results.
What's not to like? Lightweight, multiple interoperable tools (MUAs and editors), no barrier to entry, easy to review and comment. Compared to shitshows like Gerrit and the awful clunky workflow of Github, I'll take an emailed patch every time.
Does it scale to huge patchsets? ... well not so much. However Gerrit is not the answer to that (in fact, no tool I've found provides a good answer).
The major problem with the email-patches workflow is that it is a pretty poor experience for the new and occasional contributor, who will generally find that their email client makes a complete pig's ear of their patch. What I'd really like to see is a web UI that seamlessly interacted with the trad email workflow, so people who prefer a web UI and especially people who are just making a single drive-by contribution could work that way without having to start by setting up git-send-email. You could also make the web interface keep track of which patches are still unreviewed so things drop through the cracks less often...
I'm a former iOS EPM (not speaking for Apple, obviously, since I don't work there anymore), and although the Reddit commenter got the atmosphere of constant crisis right, he/she is misplacing the blame and misunderstanding the power dynamic. EPMs at Apple essentially have zero power over engineers' workload. They take the list of stuff the engineering managers said they want to get done this year and say "You guys are crazy, you'll never be able to do this without 3x the hours/manpower." Then they proceed to drive the team as hard as necessary to make sure that they actually deliver what they said they were going to deliver. That's it. The idea that there is this cabal of mighty EPMs twirling their mustaches and loading developers down with work is pretty far from reality.
It's true that you shouldn't be working on anything not in Radar (the bug tracker) but this is true anywhere you'll work. Project managers however do not sign developers up for all those radars--on the contrary--we're usually trying desperately to help you get rid of scope and get the task list down to what's actually do-able!
One of the great things that IMHO sets Apple apart is how engineering-driven they are. I've never worked anywhere else where engineers had so much freedom to decide what they're working on. The fact that they always decide to work on 3x what they can actually achieve is kind of on them. But that drive to try to do so much is part of what keeps innovation strong at Apple.
The comment was half-right in describing the situation radar-obsessed culture (Radar-Driven Development?)
It places the blame on EPMs because EPMs are just the bearer of bad news, middlemen who carry out the whims of the UI Gods and VPs. The original commenter couldn't see those above the EPMs, the ones overseeing the BRBs and other inquisitions.
We use the bug tracker for coordination and collaboration. If you have a customer-affecting bug or a stakeholder-facing feature you’ll use the relevant task to discuss it, but we certainly don’t let the bug tracker dictate how engineers spend their time. That sounds like hell.
That's the norm in any medium to large sized engineering organization. PMs set out what needs to be worked on and want to know the progress on these tickets. How is that unreasonable? Maybe it would help if you referred to it as a sprint board rather than a bug tracker?
Within the project I was assigned this quarter, I decide what needs to be worked on. Most of the tasks on my screen were created by me and represent details that my product manager neither understands nor cares about. They're involved in master tasks for deliverable units of functionality and inbound bugs/feature requests. My PM and EM like to hear progress and like to have some idea of what I'll be doing in the coming week, but I'll pretty often have and scratch an itch in the same day, without necessarily going through the motions of writing up a task. (We do have code review, and I'll probably mention it at standup). The existence and level of detail in a task really depends on the number of people who need to be involved and how much we need async communication.
If this is atypical, I'm terrified to ever leave my large engineering organization - it's a pretty great model for the work we do.
I think the craziest thing about this comment is how juxtaposed it is to the original one. How you could have such divergent opinions on org structure or team dynamic is mind blowing.
The fundamental unit of team dynamics is what, maybe 8 engineers? Companies like Apple have thousands.
Even working somewhere, sure, you'll know what the adjacent teams in your org are like, and maybe you'll meet some internal transfers, but the truth is you have no idea what life is like for the thousands you'll never meet. There might be broad strokes that differentiate the company from its peers, but only the vaguest outline is going to be universally or even mostly true.
Well this just further convinces me that Apple’s problem is lack of man hours. If the problems are due to trying/wanting 3x what your capable of... you’ve got two options. A: reduce your expectations. B: increase your capacity so you can achieve it.
Given Apple has a pile of cash so large it could do pretty much anything it wants... and have had for several years now... I’ve begun viewing their continued unwillingness to aggressively pursue opinion B as a failure of “upper middle management” who are clearly either suppressing the needs coming up from below, or in the very least, not pushing hard enough to their bosses that their teams are under resourced for achieving the companies goals.
Breaking: Engineer Thinks PM is a Bozo. Film at 11.
It's not really context. The real problem here is the premise that "Apple has software quality issues" is taken as a given, without support.
Sinofsky makes the point that Apple is operating a such a huge, unfathomable scale and depth -- and this is coming from one of Microsoft's top guys in its heyday -- that even rare bugs that affect 0.01% of users translate into a "stadium full" of people, affecting their lives deeply. So, combine that with a sensationalist, anecdote-driven news cycle and you get an optics problem. He observes that "in any absolute sense," Apple's SW+HW quality has "exceeded everyone else."[1]
It's not "Engineer thinks PM is a bozo", it's a post explaining a very concrete, objectively negative behaviour from the PM team. I've worked at companies where that sort of behaviour was rampant, I've worked at places where it wasn't, and the difference in the end product is palpable.
Second, even if it's just anecdotal, I have personally been experiencing issues with my tMBP at work that I haven't had with any previous laptops going back to a G4 iBook. Stuff like random crashes, parts of the screen failing to render properly, etc. IT says that they're experiencing more of that sort of complaint with the current gen than they have with others in the past. The "sensationalist anecdote-driven news cycle" is blowing things out of proportion, to be sure, but there does seem to be some measurable degradation in their Apple's standards as of lately.
> It's not "Engineer thinks PM is a bozo", it's a post explaining a very concrete, objectively negative
> behaviour from the PM team. I've worked at companies where that sort of behaviour was rampant, I've worked
> at places where it wasn't, and the difference in the end product is palpable.
Yeah, I'm not a fan of dismissing complains by saying that its normal for engineering to think that way about PM. There are different mindsets involved and it is definitely normal for them not to see eye to eye all of the time. It is also normal for them to want to prioritize things differently and there are some delicate balancing acts to be played between meeting legitimate engineering needs and pragmatically driving a product forward.
But sometimes, the PM really is causing problems by preventing those things from happening or by getting in the way of his own objectives.
> even if it's just anecdotal... there does seem to be some measurable degradation in their Apple's standards as of lately
You just characterized anecdotal evidence as "measurable". That's exactly the logical fallacy at work here.
Non-anecdotal evidence of Apple's quality standards: The super long iPad upgrade cycle. It's stretched out and impacting Apple's bottom line because >3 year old iPads still work perfect.
It funny, while rare bugs are part of the problem, fundamental design is a problem that confronts me much more. The epidemic spread of animations that reduce functionality and responsiveness are pretty unforgivable. This is something that affects all users that try to interact with their phones, and I'm getting pretty sick of modal switches between "accepts touch input" and "doesn't accept input" when there are no visual indicators of the modality of the current moment. Oh how I long for the old iPhone 4 and it's greater responsiveness and more fluid UX.
Animations are one of the reasons I use Android. iOS is just littered with gratuitous animations that needlessly slow down the interface. My two least favorite are the home screen zoom-in effect you get every time you unlock the device and the animated text on typing autocomplete suggestions. And you can't disable either of these without disabling system animations entirety.
This stuff is symptomatic of Apple's love of form over function, also manifested in dumb and costly UI gimmicks like 3D touch.
Properly designed animations are function: they give a sense of place and help in creating a navigation hierarchy instead of having things pop into and out of existence.
> iOS is just littered with gratuitous animations that needlessly slow down the interface
Their gratuitousness is evaluated by you by the "slowdown" they bring. The only slowdown they bring me is when they're not interruptible/concurrent, but that's a bug, like the calculator app's one.
> My two least favorite are the home screen zoom-in effect you get every time you unlock the device
Unless I'm literally trying to race the beam, by the time I move my finger from the home button to a position over the screen the animation has completed. The animation is interruptible and you can tap or swipe right through it.
> and the animated text on typing autocomplete suggestions
How is that slowing you down? You just type <space> which triggers the animation yet merrily continue as the animation proceeds while you are already inputting the next words.
> costly UI gimmicks like 3D touch
To each his own: I use it everyday to peek at things and multitask, it's a real timesaver.
My issue with 3D Touch is that there doesn't appear to be any language for when you can use it or what it will do if you can.
90% of the time, I forget it's there.
A specific case of where it was a problem for me is that tapping the lockscreen icon for the flashlight does nothing. I thought it was broken for a week till I accidentally discovered that you had to force push it.
Unless I'm literally trying to race the beam, by the time I move my finger from the home button to a position over the screen the animation has completed.
My brain can't identify the icon I want to tap while the animation is in progress. I have to wait for it to finish then parse the screen for my target.
You just type <space> which triggers the animation yet merrily continue as the animation proceeds while you are already inputting the next words.
Again I can't identify the word I want to tap while it's moving around. I have to wait for the animation to complete, then figure out if I want to tap any of the suggestions or keep typing.
I agree animation can be functional, but both of these animations are purely there for aesthetic reasons, get old very quickly, and actively slow down my use of the device. If I have to use an iPhone for any extended period of time I turn off animations at the system level and use GBoard for typing.
As for 3D touch. I always forget it even exists because it has zero affordance. It increases the manufacturing cost of the device for very little user benefit for the typical user. I think it also forced Apple's hand on FaceID and drove the cost of their flagship device out of the range of a lot of people that would otherwise buy one.
> My brain can't identify the icon I want to tap while the animation is in progress. I have to wait for it to finish then parse the screen for my target.
Interesting. I sure don't parse each icon precisely as it moves but the colors and layout allow me to intuitively have my bearings and know which page I'm on and then it's muscle memory. I can see it being an issue though.
> I have to wait for the animation to complete, then figure out if I want to tap any of the suggestions or keep typing.
Oh my bad, I thought you were talking about the autocorrection bubble that has the word come down on <space> but this is really about the predictive words above the keyboard. I turned them off entirely because I basically never used them and it seems to make the keyboard itself terribly slow after some time as it computes suggestions.
> As for 3D touch I always forget it even exists because it has zero affordance.
So are keyboard shortcuts, 3D Touch is not a requirement for using the phone but it allows one to be more efficient without cluttering the interface. Also, you typically don't forget that you can scroll or pinch to zoom on an image or map or whatever, it's kind of the same deal.
Oh one more I just can't live without now: force pressing on the keyboard turns it into a touchpad for the caret, and re-forcing it starts a selection.
> It increases the manufacturing cost of the device for very little user benefit for the typical user.
When I saw it demo'd I thought "what a gimmick", yet now it gives me so much value that any device without it feels gimped to me.
Regarding keyboard shortcuts, at least, on a desktop there are standard affordances for showing what keys will trigger an action.
When browsing a menu bar or looking at a dialogue, labels will usually have an underlined letter (sometimes revealed by pressing Alt) that indicates you can press Alt+<letter> to trigger that action. Items from the menu bar will typically list their corresponding hotkeys directly.
This is true across pretty much every desktop UI toolkit, even, surprisingly, in the Electron based Slack client I have open right now.
Android has a lot of gratuitous animations as well. To give an example, the Clock app on my Pixel animates the tab icons, which I find dumb and annoying.
At least macOS gives you the option to disable gratuitous animations with their accessibility settings. I'm hoping eventually Android will wise up and follows their lead.
> developer mode which comes with its own set of drawbacks
Not really, you turn on "developer options". There is no developer mode as such, just many separate options, all with defaults that don't change things from non-developer behavior.
I have animations set to 2x regular speed, it's nice.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses" - Bjarne Stroustrup
I've found that quote to apply to everything. Familiarity breads contempt, even just from boredom, or wanting to shift blame for the monotony of the task you're using the tool for.
For example I think Excel is a great piece of software, but I know someone who spends all day every day in it doing dull but important spreadsheets. They're what I consider an Excel expert. But they hate Excel because every little minor issue is magnified for them because they spend all day every day in it.
I agree that this kind of criticism exists. However, that doesn't mean that all criticism is invalid, or that a large amount of criticism is necessarily a marker of success.
Some software examples: Internet Explorer has not been winning the browser wars for a decade. I've deleted Skype after its interface had been sufficiently ruined, and I don't know anyone who still uses it for business. When iTunes got too annoying, I left its ecosystem for Spotify. It's not looking good for Siri in the battle for the smart home. Speaking of programming languages, I complain a lot about Swift, don't use it, and am moving in the general direction of IntelliJ IDEs.
Excel and C++ got lucky, they will be hard to replace.
Absolutely agree with Sinofsky here to a large extent - there is little precedent at the scale some of these companies are operating at in 2018. My original comment was to more spark a certain type of discussion more than anything else.
It's cool to see other Apple engineers and PMs chime in with their perspective.
It sounds professional to need permission to spend time on something? I typically associate professionalism with the model where you’re accountable to the functionality, impact, quality, and health of your components, with an EM supporting your negotiations around scope and timelines, and letting you budget your own time.
I mean, nothing in the quote suggests that programmers can't submit items to Radar, that they can't lobby for them to be assigned a high priority, etc. Pretty much every software project beyond a certain scale uses an issue tracker of some sort.
If you need to lobby for permission to work on something broadly within the scope of what you're paid to work on, you aren't being treated like a professional.
An issue tracker is a communication tool for use in the context of a largely self-directed activity. The only role at my company where your day-to-day activity is dictated to you by the tickets on your screen is customer support.
On my team, if you're only working the asks handed down from above and not proactively taking initiative to make things better, you're barely pulling your weight.
> On my team, if you're only working the asks handed down from above and not proactively taking initiative to make things better, you're barely pulling your weight.
The problem with a lot of engineers is that "make things better" often doesn't translate into "keeps customers happy and money coming in".
I could work on making our internal software "better" for the next two years but it wouldn't bring in enough money from customers to justify paying me to do it. And I'm smart enough to know that I have zero idea about what will make things "better" for the actual customers.
The customers will eventually suffer a death of a thousand cuts through quality and reliability issues if direct attribution to revenue / customer requests is a requirement to work on anything. But of course you can't rewrite ever time you hear about a new language. Obviously there's a balance, and striking that balance correctly is a huge part of the job.
If engineers really ran a company, progress will often slow down. For example, if you're surrounded but a lot of young talent, the phrase that you just constantly hear is "refactor". Not as many developers enjoy bug hunting as they do new feature development. I suspect that those of us who've been in the field long enough end up growing a much greater appreciation for PMs and they decisions they make make than when they first start out. Or maybe I've been fortunate to work with really great PMs?
It is important to strike a good balance. One should neither ignore input by the engineers, nor give them a completely free hand. Refactoring can be a benefit for the future, but it should not grind progress to a halt. Senior engineers should give valuable input there. And of course, sometimes a seemingly crazy idea by a young talent is actually a good one :).
By broadening your vision. As an engineer, it's easy for me to focus only on technical details. So I make an effort to see beyond that -- what is our org's broader goal; what are our industry's issues? It's not always easy, and sometimes I'm overwhelmed, but it helps build a common vision, which can be the foundation for teamwork across disciplines.
What I meant was: How do other parts of the organization know what's being worked on? How do marketing, sales, product management influence the decision making process? GP made it sound as if engineering on its own decides what improvement to work on next. How does that work in the context of the larger organization?
Taking the bigger picture into account when designing a solution is simply good engineering practice. I don't think that's what the GP was talking about.
The organization communicates extensively to select a set of projects (at a fairly abstract level of definition) each quarter. Engineering managers assign projects to engineers. As a project lead, you design an architecture and implementation, circulate an RFC, break down the work, write much of the implementation, and maybe delegate components to 1-2 more junior colleagues, mentoring them in the process.
The EM and PM are often in the room with you to support conversations with stakeholders/dependencies, absorb the brunt of cross-team communication, make tough prioritization calls, and to monitor the progress you report via the bug tracker and in weekly sprint planning sessions. The engineer is responsible for determining what part of the project to work on next, and how to spend each hour/day/week in the service of its completion. PMs/EMs are only going to challenge your plans if they're egregious, and it would be unwise to create a sprint plan that would require 100% of your time.
Most people have interviewing and mentoring to do, several previous projects that occasionally need their attention, code reviews to give, operational incidents to attend to, etc. even before you consider the undocumented tech debt fixes, refactors, and productivity investments that aren't necessarily even mentioned to PMs.
If you spend too much time on that, of course, you'll fail to complete your projects, stop getting interesting assignments, and have no hope of promotion. If you spend too little, however, your projects will turn out to be operational/maintenance nightmares that may even be worse for your reputation and prospects than vaporware.
Each engineer is their own architect and project manager, with the scale of the project tailored to the engineer's level. (You advance by earning and then succeeding at increasingly complex project assignments). Product managers help determine the vision of what the product ought to be; engineers get it there.
Well ok. If "task" to you means a months-long initiative with hundreds of constituent parts, what do you call the items that take a few hours to a few days?
That post is not particularly useful - each team/org works differently. “Working on iOS” is such a vague introduction, it doesn’t really give any indication of his/her role or a feel for how every team/org operates.
I can claim the same, and my own experience has been far from that poster’s experience. Any time I have volunteered to spend extra time to accomplish a goal, I have been told by my manager that it isn’t necessary for me to do so. We also do our own planning on our team and the management chain is there to help us be successful.
Based on this comment, it sounds like engineers are more like line workers.
"EMs at Apple are powerless to push back. Every engineer's performance is tied to the number of Radars fixed and closed. Every EM's performance is tied to their team's total Radars fixed and closed, so they have an incentive to keep everyone focused on the prize."
Always take comments like that with a grain of salt.
The people who feel they are being ignored or feel they aren't being used to their full potential are going to look for someone or something to blame.
I'm sure there is some amount of "higher number of fixes is better" going on (any larger company has it), but i've seen poor team members read into things like this way too much in order to justify why they aren't doing well in comparison to others.
It may be true that apple weighs stats like that too heavily, but we aren't going to get a good picture of how heavily they weigh them from a few anecdotes.
Never saw or heard anything about my performance being tied to the number of radars I fixed or closed, and I never heard anyone else I worked with say that either. Doesn't mean it didn't happen, like every big company there are managers who are good, and managers who don't really get it.
Thanks for the perspective Klathmon and objclxt. The person's comment hits a fear of mine that people still draw the false analogy of manufacturing for software development.
I think this is the more interesting point around which we should have this discussion.
https://www.reddit.com/r/apple/comments/7x0eif/how_apple_pla...