Beck's law
“For each desired change, make the change easy (warning: this may be hard), then make the easy change.”
- Kent Beck 2012 (https://twitter.com/kentbeck/status/250733358307500032)
This is an amazing quote that offers clarity och guidance in a simple principle that is so frequently forgotten or ignored.
The basic beauty of refactoring massively and not aiming for the wanted change in the same operation has an element that is counter intuitive in that it might feel like a shortcut to do all (refactor and change) in one go. Reflection on the topic is well encapsulated in this quote, with an existing system you have a lot of information on how the thing operates and should function. If the initial refactoring that aims to enable the wanted change (which can be a very technically complicated change) without altering the system behaviour you will have so many options and easier way to ensure that nothing was broken. As a second step you can then put the effort on ensuring the wished behaviour is achieved with a technically less complicated change later, a territory where much less information is available and testing is going to be more difficult.
The key gain from this is that two complexities are at least partially isolated which is a lot easier to handle than both at the same time.
- Kent Beck 2012 (https://twitter.com/kentbeck/status/250733358307500032)
This is an amazing quote that offers clarity och guidance in a simple principle that is so frequently forgotten or ignored.
The basic beauty of refactoring massively and not aiming for the wanted change in the same operation has an element that is counter intuitive in that it might feel like a shortcut to do all (refactor and change) in one go. Reflection on the topic is well encapsulated in this quote, with an existing system you have a lot of information on how the thing operates and should function. If the initial refactoring that aims to enable the wanted change (which can be a very technically complicated change) without altering the system behaviour you will have so many options and easier way to ensure that nothing was broken. As a second step you can then put the effort on ensuring the wished behaviour is achieved with a technically less complicated change later, a territory where much less information is available and testing is going to be more difficult.
The key gain from this is that two complexities are at least partially isolated which is a lot easier to handle than both at the same time.
Kent Beck
Comments
Post a Comment