As I was developing FlowTracker, a lot of the work was driven by making tracking of specific example programs work.
I knew what result I was aiming for, but it was hard to predict what lower level mechanisms needed to be supported to make a specific example work. That often depended on internal implementation details of the JDK or libraries being used where the data was passing through.
But the HTML element linking back to the SQL script that added that data into the database wasn't like that.
I didn't expect or work towards it, that just happened, so it blew me away a little too and got me excited about what else this approach could accomplish.
A great example of how design of good products should be guided by the end goal instead of by the technical mechanism, when possible. You went out of your way to make sure the functionality was not limited by a certain single mechanism.
I didn't make it to that element of the demo because I don't need a tool to help me find which file HTML text strings are from or that HTTP headers come from my web server. So I would recommend putting that "wow" element earlier in the demo.
When you think about it, so many problems could have been prevented and so many business rules could have been easier to express if there was some standard way to track the origins and veracity of data.
Maybe also some way to track if the data is meant to be transient or meant to be written back.
The more such constraints which could be described up front, the better.
I can totally see a future where tools like this are the first line of defense when troubleshooting bugs.