3 ms·

I was just reading about something similar in the "Ask HN: What essay/blogpost do you keep going back to reread?" post Joel Spolsky's point: They did it by mak

I was just reading about something similar in the "Ask HN: What essay/blogpost do you keep going back to reread?" post 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. https://news.ycombinator.com/item?id=15407114 https://news.ycombinator.com/item?id=15407114

Dylan16807 9y ago
I reject that comparison. This is not rewriting a core product with tens of millions of lines of code. This is a small utility program. It's very often no problem to just make a new utility program. Especially one that's in the single digits on how many coder-months it costs.
- eradicatethots 9y ago
  There are no rules in soft dev
- Osmium 9y ago
  Yeah, I can see how a rewrite makes sense. It's not rewriting diskutil itself, it's adding a new UI, that presumably uses newer APIs that will be easier to maintain in the future. 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.
- DonHopkins 9y ago
  Yeah, I think the problem is that they rewrote everything but the disk utility.
- j45 9y ago
  I don't know if a rewrite is about whether it's large or small, it's about the years of hardening many scenarios.
  - Dylan16807 9y ago
    A simple utility doesn't need that much hardening against corner cases, and in this instance the bug is a main use case.
borplk 9y ago
> 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.
- diegoperini 9y ago
  >...as they turn into baseball bats for people to hit each other with I will quote you a lot from this time on. It is such a true and widely applicable judgement.
- maltalex 9y ago
  > Statements like that, while powerful are dangerous as they turn into baseball bats for people to hit each other with. 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.

Dylan16807 9y ago

I reject that comparison. This is not rewriting a core product with tens of millions of lines of code. This is a small utility program. It's very often no problem to just make a new utility program. Especially one that's in the single digits on how many coder-months it costs.

eradicatethots 9y ago
There are no rules in soft dev
Osmium 9y ago
Yeah, I can see how a rewrite makes sense. It's not rewriting diskutil itself, it's adding a new UI, that presumably uses newer APIs that will be easier to maintain in the future. 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.
DonHopkins 9y ago
Yeah, I think the problem is that they rewrote everything but the disk utility.
j45 9y ago
I don't know if a rewrite is about whether it's large or small, it's about the years of hardening many scenarios.
- Dylan16807 9y ago
  A simple utility doesn't need that much hardening against corner cases, and in this instance the bug is a main use case.

borplk 9y ago

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

diegoperini 9y ago
>...as they turn into baseball bats for people to hit each other with I will quote you a lot from this time on. It is such a true and widely applicable judgement.
maltalex 9y ago
> Statements like that, while powerful are dangerous as they turn into baseball bats for people to hit each other with. 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.