On Monday 25 July 2011 11:03:57 Igor Stasenko wrote: > But i think this is a general problem of software evolution. No matter > how hard you try, you cannot foresee all kinds of interactions, > features and use cases for your system, when you designing it from the > beginning. > Because 20 years ago, systems has completely different requirements, > comparing to today's ones. So, what was good enough 20 years ago, > today is not very good. > And here the problem: is hard to radically change the software, > especially core concepts, because everyone using it, get used to it , > because it made standard. > So you have to maintain compatibility and invent workarounds , patches > and fixes on top of existing things, rather than radically change the > landscape.
Now, why is it hard to radically change the software? Is it the failure to foresee all kinds of interactions that creates the problems? Maybe is not what we are leaving behind in the design of the solution, but what the design assumes (whether we are aware or not): the hundreds and hundreds of little assumptions that have no relation with the actual solution description... Take imperative instructions: when writing a solution in an imperative language, we are imposing chronological order to the instructions even when that particular ordering is not a requirement of the solution. So, we are not called up to change the software when the solution changes. We are called up when something, anything changes and breaks any of the assumptions carried by the software. We seem to be writing software that doesn't appear to be so soft... Cheers, Thiago _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
