So it turns out I am a release manager on a product. A product I can't talk about right now, but a product nonetheless. I've been extremely fascinated with the entire process so far and I highly recommend it to anyone who is a fan of software development. But the process has also been a bit bittersweet as well. I have been such a long time fan of elegant user interfaces that when I moved over to my own product, I envisioned creating a product that not only felt exactly what good user interfaces should feel like, but really strived to think about what the user would do NEXT and work to deliver that as well.
However, now that I'm mired in the process of shipping a product, I find it amazing that the challenge in doing this seemingly straightforward task is enormous. I'm not sure if this is a software only thing, but the permutations of what can actually be done in any given situation is absurd! Let's use an example not from my product. Let's say you were responsible for handling the security features of writing to a folder. This seems to be straight forward, you allow people to set the security of the folder and you're done. You could even envision a very elegant way of showing people what the security was and allowing people with the correct permission to change it. Perhaps you would change the context sensitive menu such that you would only display the functionality that people actually COULD do would be displayed on the menu. That'd be pretty nice.
Unfortunately, then it comes to the implementation. What happens when someone is writing the file and you right click on it? What happens if another application changes the permissions once you've already right clicked? What happens when the file disappears by another process? What happens if the user is an administrator, but only running as a standard user just for security reasons? Suffice it to say it becomes an endless morass of complexity. And even the majority of this complexity can be addressable, but once you're done coding it, you have to test it. Imagine trying to test every possible scenario of these things occuring... it boggles the mind. So suffice it to say you can do this, but almost never within the time frame of shipping.
We've all heard of that old axiom pick two: fast, cheap or good. The additional component to throw in there when you're shipping software is flexible. Because every ounce of flexibility added ends up costing so much on the back end. This is one of the reasons the Mac was so successful for so long. By limiting the flexibility, they were able to maximize the user experience. That's not to say my product won't deliver a great user interface or be flexible... just that it certainly won't be as "good" as it could be because we want to ship "fast" and we want it to be "cheap". However, there should come a time when flexibility really does sacrifice at the altar of respecting the user. In a lot of ways, I'd love to see a real revival of this kind of thinking.