Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yes, that's a good example. A software that was messed up, had crazy security bug and is still lacking. Why was a rewrite necessary? How cynical would be to say "the engineer of the day fancied Swift more than going into old code"? Sadly these days, I'm not sure this is so far-fetched.


> Why was a rewrite necessary?

Most likely because original authors were laid off or moved on; it's cheaper to rewrite software than to fix existing one; both need very different skillset and there are more people that can write their own algo quickly than fix somebody else's.


cheaper to rewrite software than to fix existing one

That's a very shortsighted thought, because the rewrite has also introduced its own set of new bugs.


I get this point. But coupled with lack of expertise & experience, lack of QA and lack of dependency tree (what feature is used where), the result can be amateurish at best and catastrophic at worst. In the case of DU, it was more the latter.

Again, the cynic in me can't accept the "cheaper" argument. Apple has lack of funds to properly hire people who are not afraid to go into complex existing code? I get this argument in a start-up environment, but won't accept it in the case of the largest tech company in the world. This is just bad management.


Apple is a multi billion dollar company and you are saying they couldn’t find a C/Obj. C developer to take care of their own app?

Also, developers in their nature like to rewrite things. There should be a product owner overruling them. I’m saying this as a developer myself. Otherwise you end up in a situation where images are running the asylum.


Google is doing it all the time; it's not a question of money, it's that most developers don't want to work on old stuff they had minimal input on; it's easier to motivate with "hey, let's do new stuff" instead of "hey, fix these convoluted bugs original author wasn't able/willing to".


Yes, this is creating lot of churn in terms of apps and user interfaces. Developers as I said before are motivated to build new things causing adverse problems like this situation here were perfectly good apps are being rewritten to an inferior state.


Didn't the re-write happen around the time that Apple released and shifted to APFS? Not defending the new app, it is a huge misstep in my book, but it makes sense that there was a major overhaul to the Disk Utility app when they were introducing substantial new features for something as important as the file system.


I think both apps are a wrapper for diskutil or its underlying implementation. And UI-wise, APFS didn't warrant introduce any substantial UI changes, especially not ones that couldn't be added to the existing software.


They are but I was focusing on the impetus of the re-write, not defending the decision to hamstring the UI. I agree that it’s a regression but I think the patient was on the table when APFS came out and the new UI appears to have come at that point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: