As a systems architect you sometimes have to make a guess how things will be used into the future, mostly you get it right, sometimes you don't.
A month or so ago we implemented a "computed page" functionality which allows pages to included in other pages at runtime. It wasn't until last week that we discovered a major bug in the new functionality.
Tornado server has html fields as controls and a corresponding document item holding the data. At runtime the document item data is merged with the control and output to the browser into text boxes, lists, radios etc. Up until the new computedpage functionality went it, everything was working perfectly.
The problem was that the choices for lists etc were stored internally on the control, not on the document item. Since the computed subpage was rendered at the very end of processing, any choices added programmatically were ignored as at that time no control existed to add the choices to (because the server hadn't yet chosen which computed page to insert). Major problem.
Now the challenge was to internally rearchitect the page rendering mechanism to allow choices to be stored on the document item instead of the control. This had to be transparent to the programmer because existing applications would break in spectacular fashion and would no doubt end in me receiving a few cranky-grams in the mail.
The good news is internally we had a major cleanout and reshuffle and everything is working as it should. Some applications had to have a few tweaks, but that was because they actually never should have behaved like they did.
It made me appreciate other products that are in version 5 or more and the legacy luggage they HAVE to carry forward in order not to break older code. It's very easy for us to look back and say "That should have been done differently", but very difficult at the time to look into the future and make a judgement call on how to implement a certain feature.