Joel Spolsky's point: They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.
Statements like that, while powerful are dangerous as they turn into baseball bats for people to hit each other with.
And they become an excuse for ignoring things and becoming an absolutist religious zealot.
There are legitimate cases where rewriting the code from scratch can be the single BEST strategic decision.
(And of course, vice versa)
If I have strong rational reasons to believe that a rewrite is warranted quoting Joel Spolsky or anyone else is not going to change my mind.
I love that analogy.
I see it again and again with so many of the "classics" - phrases like "premature optimization is the root of all evil" and "adding manpower to a late software project only makes it later". Sure, these statements are right more often than not, but the zealousness with which they are often applied leads to an enormous amount of mistakes.
There ARE cases in which optimizations aren't premature. System architecture is all about designing a system for optimal performance in some area or another. And in some cases, bringing in more people to a late project can speed things up.
I will quote you a lot from this time on. It is such a true and widely applicable judgement.
The problem really is that the new Disk Utility is a minimal viable product, rather than an app that can actually do everything the diskutil command line utility can do.
And then you have terrible bugs like this, which is presumably a non-security engineer writing a bit of UI code that they shouldn't be. I doubt this bug actually came from the APFS encryption itself.
(this is 75% speculation on my part and 25% confirmed by conversations with 2 ex-apple engineers.)
Consider: Terminal.app comes with macOS, not with Xcode. If the BSD environment was just there for developers, would this be true?
Today's Microsoft seems to increasingly think sysadmins would rather use PowerShell than MMC snap-ins; I'm inclined to think that today's Apple is similar. And there's nothing inherently hard about CLI interfaces; "regular people" used MS-DOS PCs for ~two decades.
I would bet Apple just thinks the CLI is the optimal Human-Computer Interface for doing some things.
CLIs are opaque by definition. With a GUI you can click around menus until you find what you're looking for; with a CLI you can't even begin unless you already know what you're doing. Man pages are no help to newbies; they're either uselessly terse, impenetrably jargon-packed, or both.
It's probably possible to make a CLI that's relatively easy-to-use and newbie-friendly, but I've never seen anyone attempt it. People used MS-DOS for years because it was the only way to access the large majority of software, and abandoned it as soon as there was a viable alternative (Win9x).
In contrast, even features in pretty poor GUI apps are by default generally discoverable.
Even just, say, MS Word. If I don't know a feature exists, clicking around through dozens of menus isn't going to get me anywhere. For both CLI and GUI, Google or official docs are the only reasonable way to discover.
I find that clicking around through menus often teaches me about great features I didn't even know I wanted.
Regardless of the cause, in practice, I find that it's much easier to get basic functionality out of a new-to-me GUI app than a CLI app. That may not be a fundamental properly of CLI, but it certainly is how all significant CLIs are written.
Without google, I'd have never learned any CLI stuff, and even as it is, I have no idea why the flags can't just be words instead of letters.
Conversely, novice use of even complex GUI apps rarely requires looking up a tutorial first, because you generally can just click or tap around and at least figure out minimally how to use it.
Inexpert users (ie. nearly everyone) stop there. Obviously further reading is needed to make more extensive and/or efficient use of any tool. But at that point in my opinion we're beyond the reasonable boundaries of 'discoverability'
If you can’t spend time on one of your main tools docs to grasp what “merge -r 403:480 -c -473 ^/branches/rt0” does and how to command it, then sit there and code, folks will do maintenance for you.
Still, GUI programs are very clearly more discoverable than cli ones. How far and where discoverability is the best approach to educating a user is a separate question.
Not exactly. Wrappers can (and tend to) “enhance” and hide details from those who actually have idea. This kind of breaks discoverability into confusion, that’s what my rant was about.
Perhaps not, but they easily could. The Description section at the start of the man page says:
"See gittutorial(7) to get started, then see giteveryday(7) for a useful minimum set of commands."
And if you do `man gittutorial` it has, as you might expect, a tutorial on how to get started with git.
To counter that with an example of what I consider really good man pages look git.
I've learnt loads about rebasing, etc. from the examples in the git man pages.
Personally I've always loved a good CLI.
Is this not true any more? Where does ex-Apple dev talent tend to go? (Microsoft? Indie app development?)
I know lots of people who have spent their entire careers there because the work is challenging and interesting. I also know teams that handle anonymous backend infrastructure e.g. AppleID or ADC where there was higher turnover.
No different to any other company.
Anecdotally, Chris Lattner is a high-profile recent departure. :-)
You know the sort of thing that happens to developers: Every. Single. Day.
These are in the first page of tests I’d write. NIST SP 800-111 asks for forensic pre-release testing—can you really believe such happened here?
This isn’t a failure of the engineer who wrote out the wrong buffer. Everyone makes mistakes like that. It’s a failure of the Engineering culture and engineering management that shipped without reasonable testing, or manual pre-release examination. It’s a failure of the culture that accepted bugs like this, rather than asking (appropriately, for an Apple FDE product): let’s assume that it will cost someone $1B or a thousand lives if this fails. What should we do to assure its correctness?
Force quit, reopen, loads fine.
Go to the Today tab. Scroll through. Notice that sometimes your scroll doesn't get registered. Why? Because if you try to scroll over an "Open" or "Get" button, it steals the event and breaks your scrolling. Amature mistake, and the kind of detail Apple used to always get right.
Watch OS SDK: When the user performs an action on a notification that arrives on the watch, it calls a callback on the application on the phone. What happens if the user's phone is not reachable? The action just gets dropped on the floor, and to the user the app looks buggy. (Maybe/hopefully this is fixed in the latest version of watchOS; I haven't checked.) Flawed, poorly thought out API design.
Go to the updates tab on the App Store app. Pull down to refresh. No updates, but the "Available" headline disappears and then weirdly reveal-animates back into place, an overall feeling of flicker.
Huge issues? No, but a very real drop-off in quality and polish from what Apple used to put out.
(The password bug is a little different -- obviously bugs can and do happen. But not having a testing procedure in place for the core paths through a piece of software is a huge process failure, especially for something critical like security. Every release of the software should have testers going through a plan like, "enter password hint. attempt to access volume. verify password hint is correctly shown." &c.)
(Also, to be fair, I think after taking a huge dive the quality of Apple software seems to be slowly ticking up again.)
Bear in mind the old version did need to be updated (new CoreStorage features, has to handle Fusion drives, now APFS).
I get the sense there's a lot of shuffling between teams in Apple, and teams are a lot smaller than you'd expect, and this is the inevitable result. The advantage (I'm guessing) is that they get to move quickly, and it reduces bureaucracy/politics, but ... yeah, this isn't great.
At least diskutil is still there, and is as powerful as ever.