Variability, Being Picky and Software Product Lines
When you're building a single app, things actually don't change all that much. Sure it is possible you'll completely change your back end scripting language, your Javascript library, your approach to implementing CSS forms and the framework you use to persist your data two or three times within a single project, but it isn't *that* likely. If you're developing a Software Product Line you're almost guaranteed to have that level of variability over a number of years and tens, hundreds or thousands of different projects, and you have to plan to abstract as much of that variability as possible so that you can automatically upgrade older projects to the latest version of your SPL. Because of this it is really important to be picky about encoding intent independently of implementation otherwise you'll end up with lots of markup in each project based on your current persistence framework, scripting language or Javascript library that are going to kill you when you try to automatically upgrade older projects to the latest version of your SPL.
Imagine if you have hundreds of apps explicitly calling Reactor that you need to port automatically to work with Transfer but you can't budget time on a per project basis to implement the port - only some time to write a simple script to transform your code . . .
Of course, these are hard problems to solve as you want to balance providing flexibility with avoiding unnecessary indirection, but perhaps it explains why I seem to picky about things that - if I were building just a single site - would seem pretty insignificant to me as well.





There are no comments for this entry.
[Add Comment]