If it is indeed a boneheaded mistake, then it’s probably because of over reliance on RPC-type calls from the front-end that displays the data, to the back-end that actually handles the data. User deletes photo, and the front-end, instead of actually deleting it, tells the backend to do it… and then hides the photo from view, maybe updates its index of photos marking them as “deleted” regardless of whether the backend actually deleted the photo.
Then an OS update comes along, and rescans the filesystem, and report a bunch of new photos to the front-end, that then happily add them to the GUI to the user’s surprise.
Modern APIs and software architectures are a bloated, unnecessarily complex mess, and this is the result.
It’s quite possible, although I’m inclined to blame it on turnover and pressures for deadlines
I’ve come to see software kinda like a plant. If you neglect it, it rots, because all software is contextual and the world moves on. If you keep growing it, it starts to rot from the inside. If you carve out down to something smooth and streamlined, it can last a long time and just need TLC to bounce back
Ultimately, if you want something to be big and to last, you have to prune it, transplant it, and continuously work on it. There’s no direct money to be made there though
And it helps a shit ton to have people around long-term. It can take years to learn a big stack, but having someone go “wait, if we do this we need to rexamine how we delete photos” is how you avoid fuck ups like this
Wow, beautiful analogy! I’m going to use that in my professional career if you don’t mind. Also with your permission I’d like to give you credit with a link to this comment, if that’s OK with you, of course.
Some unit tests might have been lacking. But yea. I personally like to keep things simple, but a lot of tech companies seem to prefer quite the opposite sometimes
If it is indeed a boneheaded mistake, then it’s probably because of over reliance on RPC-type calls from the front-end that displays the data, to the back-end that actually handles the data. User deletes photo, and the front-end, instead of actually deleting it, tells the backend to do it… and then hides the photo from view, maybe updates its index of photos marking them as “deleted” regardless of whether the backend actually deleted the photo.
Then an OS update comes along, and rescans the filesystem, and report a bunch of new photos to the front-end, that then happily add them to the GUI to the user’s surprise.
Modern APIs and software architectures are a bloated, unnecessarily complex mess, and this is the result.
It’s quite possible, although I’m inclined to blame it on turnover and pressures for deadlines
I’ve come to see software kinda like a plant. If you neglect it, it rots, because all software is contextual and the world moves on. If you keep growing it, it starts to rot from the inside. If you carve out down to something smooth and streamlined, it can last a long time and just need TLC to bounce back
Ultimately, if you want something to be big and to last, you have to prune it, transplant it, and continuously work on it. There’s no direct money to be made there though
And it helps a shit ton to have people around long-term. It can take years to learn a big stack, but having someone go “wait, if we do this we need to rexamine how we delete photos” is how you avoid fuck ups like this
Wow, beautiful analogy! I’m going to use that in my professional career if you don’t mind. Also with your permission I’d like to give you credit with a link to this comment, if that’s OK with you, of course.
Some unit tests might have been lacking. But yea. I personally like to keep things simple, but a lot of tech companies seem to prefer quite the opposite sometimes