Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Apple Plans to Root Out Bugs, Revamp iPhone Software

bloomberg.com

Post reply on HN
Print view View original

221–230 of 234 posts

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#221

Post by techdragon »

throwaway7187 wrote: post #63
askafriend wrote: post #7

This comment from a former employee on the iOS team provides some more context around the software quality issues. 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...

Perfect time for the ol' throwaway... 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 g…

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.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#222

Post by closeparen »

zimpenfish wrote: post #161
closeparen wrote: post #122

Earlier quoted context omitted.

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 wor…

> 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 f…

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.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#223

Post by [deleted] »

rowyourboat wrote: post #140
closeparen wrote: post #122

Earlier quoted context omitted.

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 wor…

So, you guys are all developers and product managers rolled into one? How do you decided what gets worked on?

[deleted]

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#224

Post by newscracker »

savoytruffle wrote: post #206
gurkendoktor wrote: post #160

Earlier quoted context omitted.

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…

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).

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#225

Post by closeparen »

rowyourboat wrote: post #178
neolefty wrote: post #173

Earlier quoted context omitted.

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.…

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.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#226

Post by closeparen »

vlozko wrote: post #164
closeparen wrote: post #86

Earlier quoted context omitted.

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.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#227

Post by rowyourboat »

closeparen wrote: post #225
rowyourboat wrote: post #178

Earlier quoted context omitted.

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.…

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…

That sounds like a normal organization to me...

> Engineering managers assign projects to engineers

So engineers do only work on tasks handed down to them. We just did not agree on what "task" means.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#228

Post by closeparen »

rowyourboat wrote: post #227
closeparen wrote: post #225

Earlier quoted context omitted.

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…

That sounds like a normal organization to me... > Engineering managers assign projects to engineers So engineers do only work on tasks handed down to them. We just did not agree on what "task" means.

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?

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#229

Post by rowyourboat »

closeparen wrote: post #228
rowyourboat wrote: post #227

Earlier quoted context omitted.

That sounds like a normal organization to me... > Engineering managers assign projects to engineers So engineers do only work on tasks handed down to them. We just did not agree on what "task" means.

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?

Task. But a three-month project is, at the abstract level, also a task. I misunderstood you, that is all that is happening here.

Re: How Apple Plans to Root Out Bugs, Revamp iPhone Software

#230

Post by harrygeez »

jrs95 wrote: post #107
hyperrail wrote: post #24

Earlier quoted context omitted.

Steven Sinofsky wasn't in charge of Windows Phone when that division decided to have no device upgrade path from WP7 to WP8 (or, for that matter, no upgrade path _or_ application compatibility from WP6.5 to WP7.0). The person in charge of Windows Phone then was Terry Myerson, who had an entirely different reporting chain to Steve Ballmer from Sinofsky's. Myerson was later promoted to run R&D for all Microsoft operati…

The death of XNA is pretty disappointing, if they'd invested more in that then Microsoft could have basically made Unity.

The problem isn't in the tech but devs these days are reluctant to write for MSFT platforms, can't blame them though.
Post reply on HN