Submitted by MichaelJames on March 31, 2008 - 4:01pm.
A friend of mine in Seattle also wrote to me about this. There's things we can do to mitigate this -- it's not an unsolvable problem or even a particularly hard one. But no matter what, it's going to have a greater cost than a simple code refactoring that doesn't touch the persistence layer, and there may be times we wish we'd chosen "correctly" in the first place.
With databases, the cost of change is a little higher still if we've deployed or released a previous version with active data we've promised to preserve. We probably need to write some kind of migration (either explicit in one step, or implicit) which may itself have bugs or be misused by customers (ahem...).
Probably any promise we've made in the past increases the cost of change. In the case of user interface, people may get attached to our old UI. One way or another this will increase the cost of switching to a better UI. With an API, we may be obliged to support the deprecated one years after we come up with a better one; this constrains our options.
Database persistence can be seen as a special case of API that involves our past selves talking to our future selves.
Thanks for the kind words, Niels. Amsterdam was a great course with a positive group of participants.
A friend of mine in Seattle also wrote to me about this. There's things we can do to mitigate this -- it's not an unsolvable problem or even a particularly hard one. But no matter what, it's going to have a greater cost than a simple code refactoring that doesn't touch the persistence layer, and there may be times we wish we'd chosen "correctly" in the first place.
With databases, the cost of change is a little higher still if we've deployed or released a previous version with active data we've promised to preserve. We probably need to write some kind of migration (either explicit in one step, or implicit) which may itself have bugs or be misused by customers (ahem...).
Probably any promise we've made in the past increases the cost of change. In the case of user interface, people may get attached to our old UI. One way or another this will increase the cost of switching to a better UI. With an API, we may be obliged to support the deprecated one years after we come up with a better one; this constrains our options.
Database persistence can be seen as a special case of API that involves our past selves talking to our future selves.
Thanks for the kind words, Niels. Amsterdam was a great course with a positive group of participants.
--mj