Imagine you’re making a music player. It should do all the normal things. It should be able to, you know, play whatever music files you consider important (MP3s if you’re a normal type, FLACs if you’re a music nerd, everything ever if you’re VLC). You probably want it to have some kind of playlist feature, so you can make a list of songs and have them play one after the other. If you’re like me and don’t want to actually decide on a playlist, you might want to be able to take some subset of your music library and shuffle it so your songs play in a random order.
Now the software engineering starts. Shuffling an arbitrary list is easy. Your framework of choice probably provides an implementation of the Fisher-Yates shuffle. If it doesn’t, it’s easy enough to implement. This naïve implementation works in almost every case. You wouldn’t see anything wrong with it until you’ve been using the software for a while. (The task of statistically proving that your shuffle works falls on you, if you care.) My exact problem sounds like this. You see, on every Alan Parsons Project CD I’ve ever owned or listened to, as well as this particular YouTube video, the song most people think of as Eye in the Sky is actually two songs. Sirius, a different song, works as the intro to Eye in the Sky. It doesn’t make any sense to listen to Sirius by itself, and being dropped right into Eye in the Sky is jarring at best, yet it always happens when I leave my player on shuffle. (The “full” version can be found here, for comparison.)
This is the kind of problem that you wouldn’t notice right away in testing. (An equivalent problem is that some albums, like the venerable Mouth Sounds, are designed to be listened to as one continuous album and shuffling hurts the experience.) After all, the actual shuffling works. It’s just suboptimal in some situations. My idea is to be able to “link” files to be played one after the other. You could link Sirius and Eye in the Sky to say “Shuffle, treat these as one song and always start playing at Sirius.”
Of course, new features always add complexity. How do you tell users this is an option? Since linking isn’t commutative (you have to specify which one is “first” and maintain an order), maybe “link” isn’t even the right term. “Parent” and “child” might work? “Sirius is the parent of Eye in the Sky” is a little non-obvious to people who don’t work with data structures. It’s also unwieldy for sticking albums together (“Prime Time is the parent of Let Me Go Home is the parent of One Good Reason is the…”). Then you have to worry about storing this information efficiently (maybe as a collection of linked lists) and telling the shuffle about it (saying “if you land on one, go to the start of the linked list” doesn’t work because it means that you’re more likely to land on a linked song. The shuffle should treat each set of linked songs as one song, but the user should be able to seek back and forth in the list, as well as skip the whole thing.) And, like anything, there’s issues that probably won’t show up until testing and until it’s released to the wild.
So software engineering isn’t easy. If you get any of these wrong, your feature will end up unused or make the experience worse. Even a relatively simple feature can spiral out of control.