--- Marcus Denker <denker at iam.unibe.ch> wrote:

>[...]
> The interesting thing is that this question is a pretty
> fundamental one: When designing
> Systems, there are two philosopies of how to deal with
> errors or 
> failures: 1) Make sure
> no Error happens 2) Errors will happen, deal with them.
> 
> The interesting thing is now that 2) allows to make the
> whole System 
> much much simpler
> and powerful, as you can ommit all the savegards that
> ensured  "correctness" before.

In the first year of my professional IT job, I think to
protect the code from destructive changes.
Then I start to apply a "light" XP process on my work and
schedule.
I embrace the change, at least in my mind, because the
project I worked was not XP-oriented.

Now my project are planned for change: the code I wrote
*should be reviewed* in the next future!
This vision improved my code: errors are less then
expected, even if now I take less care when writing the
"single" code line, and plan often releases.
The only think to do is to stake outs, for example via
class comment, where the code can be broken and when should
not  :)




=====
// Giovanni Giorgi    http://www.siforge.org