Comment by JKCalhoun | Hacker News Reader

Comment by JKCalhoun | Hacker News Reader

Parent Full thread

Imagine that the last Major OS release was going to be a bug fix release ... but then AI happened. And imagine this happens every year with some new feature demanding it be shipped.

Having said that, here's the reality of bugs that are assigned to a team. Feature work comes first. The (older) engineers don't want this — they want to fix bugs, refactor code, get rid of tech debt. But ever since Jobs returned to Apple, it's become top-down and the engineers are no longer driving the ship. Management want the features.

So, the slippery part is this: once you defer a bug for an OS release and ship your product, deferring that bug in the next OS is a no-brainer. You already shipped with the bug, why is it so important this time around? So users/devs learn to work around the bug.

Occasionally, as an old-timer, I would on a whim just fix an arbitrary bug that was "bugging" me. Sadly though, the process had become so top-down though that I would also need: 1) someone to code-review the changes (and so already you are encountering your first obstacle requiring "buy in") and then 2) get permission from "management" (this might be the BRB, bug review board) in order to submit the fix and the Radar. (There are periods though when they are lax and bugs can be submitted with little justification — or we would just make up some bullshit to get the bug fix in).

I recall the early days with fondness when a dev just checked fixes in.

Me: Craig, are you working on the Crop tool in Photos?

Craig: Yeah, why?

Me: How does it pick the default for whether to use Portrait or Landscape? Half the time I think the default it picks is wrong. Why not look at the image bounds and default to Landscape if it is wider than it is tall?

Craig: Good idea. I'll make the change now and write a Radar for it later.

Also, a shout out to Brendan who would push back when in a feature meeting with something like, "Okay, which of these features can we drop? Because we have some serious technical debt we need to address that was not own your feature list."

> But ever since Jobs returned to Apple, it's become top-down and the engineers are no longer driving the ship. Management want the features

Were you using Macs before Jobs came back? The entire operating system for PowerPC based Macs was technical debt with parts of the OS running under emulation.

It was a buggy unreliable crash prone mess.

>Were you using Macs before Jobs came back?

I think he was :)

https://en.wikipedia.org/wiki/Glider_(video_game)

Well I feel dumb for asking him :)

Yeah I had that game on my Mac LCII back in 1992 and Parena was great too.

The point still stands though. The operating systems were horrible back in the mid 90s and both Macs I had back then - the Mac LCII and PowerMac 6100 - were cripple by being a half speed bus. Back before it was necessary.

You're objectively right. I have been running emulators recently with System 6.0 and was surprised at how much crashing I must have just tolerated. I shouldn't have made it appear that I was defending the quality of pre-OSX Mac OS. (Although we were talking about how quality has come down of late.)

As an engineer before Jobs came back — and for a few years too after he was back — there was still a sense that engineers could call the shots with their own frameworks/apps. Copland, Pink, all that — you can dismiss them as failures but they were engineering trying to toss off the "technical debt" of no true multitasking. So, again, it was bottom up and was at least a joy to be an engineer working on the OS at the time.

As I say, for a few years Jobs let engineering call the shots as NeXT became integrated in the OS. I was on the Graphics team then and a whole new graphic architecture and window server were created more or less from scratch (heavily borrowing from NeXT of course since most of the graphics engineering team were NeXT).

At some point though the major changes were in and management began to take over. "Quality" was eventually measured in unit-test code coverage, for example. (Sigh.)

I was in college in the mid-late 90s. There was this brief period where all of a sudden it became painfully aware how much Mac OS was crashing. I was regularly using SGI, Sun, and IBM Unix workstations and Linux had just become available. I don't think I ever saw any commercial unix workstation "crash" and Linux the crashes were usually my fault.

If you were only using Windows you barely noticed, but if you used much Unix Mac OS got pretty painful. I mostly remember this from taking a digital music/video class and that was basically the only thing I used Macs for at that time. You never really got through an hour or two editing video or audio without a crash or two. We had Avid workstations where they controlled this by tightly controlling the software on the Macs, but I never actually got permission to use them.

There were also behavior patterns. If you only used Mac you were in a behavior pattern where you'd crash the machine less. If you were using Unix workstations a lot your behavior subtly changed and you tried to do more stuff at the same time. If you then went back over to the Mac and overloaded the Mac the same way it was a bad time.

> As an engineer before Jobs came back — and for a few years too after he was back — there was still a sense that engineers could call the shots with their own frameworks/apps

That’s a bug not a feature. Engineering led companies rarely ship good consumer products. What happened to Apple before there was a product guy at the top is a prime example.

Another recent example is Google. Google has the best technology in the industry but can’t ship and sustain a good product to save its life.

When your customers are nerds like you, I think engineers do fine.

I should qualify it somewhat though — I mean I was, for a spell, working on the ColorSync framework. So the "customer" was also an engineer using our API.

At the same time, when I worked on Preview initially I added features that I wanted and I think it dovetailed what users wanted. I am also a user I rationalized.

Further, many of the old timers like myself, were hung up on Tog and his Human Interface Guidelines. We would argue over lunch the Right way to handle UI for a specific feature, etc.

Jobs comes along and with Design at his side, and they decide that the address field in Safari should also be a progress bar (that appears to select the text as it loads?). Some poor engineer was told then to implement that. (I hated what I came to call one-off UI.)

Reply on news.ycombinator.com