4 ms·

No you dont get it. It's not about maintaining or not, its about what a developer spends their time on. Do you want the developer to spend months moving the cod

No you dont get it. It's not about maintaining or not, its about what a developer spends their time on. Do you want the developer to spend months moving the code from one legacy API to a new one, that will give the user no tangible benefit, or do you want the develop new features requested by the users?

deleted 7y ago
[deleted]
yardie 7y ago
> Do you want the developer to spend months moving the code from one legacy API to a new one If the situation demands it I would say yes. I treat it as one big refactoring job. There are lots of shims in old software libraries that may not need to be there anymore. There are also lots of vulnerabilities that a fresh set of eyes and a different perspective can illuminate. A product that began its life being developed by a lone developer may have an entire team now. The rewrite is a good opportunity to explore how it works and why certain decisions were made.
- pvorb 7y ago
  > The rewrite is a good opportunity to explore how it works and why certain decisions were made. ... and a good opportunity to break existing and working features along the way. If something works, why should you fix it?
jiofih 7y ago
“No tangible benefit” is a very weak assumption. Upgrading to new APIs means familiar UI controls, possibility of integration with system features - off the top of my head, iCloud copy & paste, versioning, handoff, low power/data mode, form inputs behave the same as everywhere else, font rendering, window controls - all very tangible for users.
- trimbo 7y ago
  Except there's no reason those things couldn't be supported in an existing API with less friction to adopt. It's software. I think the reason software abruptly changes (API switches, rewrites, UX redesigns, etc) is because doing that employs more software people than incremental improvements to old stuff. I don't think this is necessarily a choice, it's just the way it works out. It's kind of a perfect business in that way. The downside is that occasionally an important customer says "enough!" They're totally justified in doing that, but it doesn't align with growth, so it's the cost of business.
  - jiofih 7y ago
    > there's no reason those things couldn't be supported in an existing API That’s how you get Windows 10, where you’ll encounter three eras of UI, going all the way back to 1995, just to change your power settings. No thanks.

deleted 7y ago

[deleted]

yardie 7y ago

> Do you want the developer to spend months moving the code from one legacy API to a new one If the situation demands it I would say yes. I treat it as one big refactoring job. There are lots of shims in old software libraries that may not need to be there anymore. There are also lots of vulnerabilities that a fresh set of eyes and a different perspective can illuminate. A product that began its life being developed by a lone developer may have an entire team now. The rewrite is a good opportunity to explore how it works and why certain decisions were made.

pvorb 7y ago
> The rewrite is a good opportunity to explore how it works and why certain decisions were made. ... and a good opportunity to break existing and working features along the way. If something works, why should you fix it?

jiofih 7y ago

“No tangible benefit” is a very weak assumption. Upgrading to new APIs means familiar UI controls, possibility of integration with system features - off the top of my head, iCloud copy & paste, versioning, handoff, low power/data mode, form inputs behave the same as everywhere else, font rendering, window controls - all very tangible for users.

trimbo 7y ago
Except there's no reason those things couldn't be supported in an existing API with less friction to adopt. It's software. I think the reason software abruptly changes (API switches, rewrites, UX redesigns, etc) is because doing that employs more software people than incremental improvements to old stuff. I don't think this is necessarily a choice, it's just the way it works out. It's kind of a perfect business in that way. The downside is that occasionally an important customer says "enough!" They're totally justified in doing that, but it doesn't align with growth, so it's the cost of business.
- jiofih 7y ago
  > there's no reason those things couldn't be supported in an existing API That’s how you get Windows 10, where you’ll encounter three eras of UI, going all the way back to 1995, just to change your power settings. No thanks.