Hammer
From APIDesign
(→Substitution) |
(→A NetBeans Hammer Experience) |
||
| (9 intermediate revisions not shown.) | |||
| Line 3: | Line 3: | ||
== Doing the Same Thing. Expecting Different Results == | == Doing the Same Thing. Expecting Different Results == | ||
| - | It is tempting to stick to tools, policies and solutions that have proven to work in the past. They have a history, they are familiar to us. We can project what they can do. It is comfortable to ''not change the winning team''. Still it may not be the | + | It is tempting to stick to tools, policies and solutions that have proven to work in the past. They have a history, they are familiar to us. We can project what they can do. It is comfortable to ''not change the winning team''. Still it may not be the best choice. |
| - | At the end we want to achieve something new. By repeating what we have done in the past, we can hardly get something | + | At the end we want to achieve something new. By repeating what we have done in the past, we can hardly get something different. We can apply similar practice, we can just follow the [[APIDesignPatterns|pattern]], but in order to do so, we should recognize the basic pre-requisites (that may be hidden from [[horizon]] of our shallow understanding) that are critical to applying the ''[[hammer]]'' properly. |
== Substitution == | == Substitution == | ||
| Line 13: | Line 13: | ||
As someone watching from a distance, I can't help seeing the [[wikipedia:Greenpeace|Greenpeace]] having a [[hammer]] (a successful fund raising when fighting against nuclear weapon testing) and using it on a completely different nail. Which is probably natural given the fact that all the nuclear weapons holders from the [[wikipedia:Greenpeace|Greenpeace]] beginnings ceased on any testing and the organization needed to re-focus to be relevant. | As someone watching from a distance, I can't help seeing the [[wikipedia:Greenpeace|Greenpeace]] having a [[hammer]] (a successful fund raising when fighting against nuclear weapon testing) and using it on a completely different nail. Which is probably natural given the fact that all the nuclear weapons holders from the [[wikipedia:Greenpeace|Greenpeace]] beginnings ceased on any testing and the organization needed to re-focus to be relevant. | ||
| - | Still the ''[[hammer]] law'' seems to be present. It is causing more harm than [[good]] as the [[wikipedia:Greenpeace|Greenpeace]] credit (earned in the nuclear weapon testing fight) is now used to promote idea which has little to do with the original one. Some people find this kind of [[doublethink]] twist uncomfortable and humiliating for an [[wikipedia:Greenpeace|organization]] that otherwise | + | Still the ''[[hammer]] law'' seems to be present. It is causing more harm than [[good]] as the [[wikipedia:Greenpeace|Greenpeace]] credit (earned in the nuclear weapon testing fight) is now used to promote idea which has little to do with the original one. Some people find this kind of [[doublethink]] twist uncomfortable and humiliating for an [[wikipedia:Greenpeace|organization]] that otherwise has a bunch of useful activities. |
== A [[NetBeans]] [[Hammer]] Experience == | == A [[NetBeans]] [[Hammer]] Experience == | ||
| Line 23: | Line 23: | ||
The [[performance]] of the new system is certainly better in the old scenarios (as it eliminates needless checks at the moment when user wants to do something with the IDE and gives it focus). On the other hand the external tools did progress as well and there are new use-cases we have not dreamed of back then: [[Git]] users are shamelessly switching branches from command line, merging between them and meanwhile the [[NetBeans]] IDE gets confused (and burns the CPU like crazy). This is indeed a flaw. | The [[performance]] of the new system is certainly better in the old scenarios (as it eliminates needless checks at the moment when user wants to do something with the IDE and gives it focus). On the other hand the external tools did progress as well and there are new use-cases we have not dreamed of back then: [[Git]] users are shamelessly switching branches from command line, merging between them and meanwhile the [[NetBeans]] IDE gets confused (and burns the CPU like crazy). This is indeed a flaw. | ||
| - | + | Here we are getting to the ''[[hammer]] experience'' - some members of [[NetBeans]] community ([[ThanksFriends#Tim_Boudreau|Tim]] and his fellows) reminded themselves about the old, [[good]] ''on focus synchronization'' and started to push really hard for it as being solution to the problem. I can't help myself, but from my perspective it is like the [[wikipedia:Greenpeace|Greenpeace]] replacement of ''nuclear weapon testing'' by fight against ''nuclear energy'' - it misses the root cause why the ''refresh on focus gained'' worked in the past. | |
| - | The original use-case was to synchronize when there was a chance that an external tool was executed. To execute an external process one had to switch to terminal window or window of some other application. Obviously gaining focus back was relatively [[good]] moment to refresh (at least for short running external commands). There was some sense in doing this. | + | The original use-case was to synchronize when there was a chance that an external tool was executed. To execute an external process one had to switch to terminal window or window of some other application. Obviously gaining focus back was relatively [[good]] moment to refresh (at least for short running external commands). The more often the IDE got focused, the more up-to-date its view of sources was. There was some sense in doing this. |
| - | However using a focus gained to prevent the IDE from doing refresh is | + | However using a ''focus not gained'' to prevent the IDE from doing a refresh is a fragile black magic and not a user interface. First of all it is not easy to find intuitive UI, second it will lead to situations when people will be afraid to use '''Alt-Tab''' as they might accidentally switch to the IDE at inappropriate moment. |
This is the kind of solution one gets when attracted by the [[hammer]] effect and seeing the nails all over. | This is the kind of solution one gets when attracted by the [[hammer]] effect and seeing the nails all over. | ||
[[Category:APIDesignPatterns:Anti]] | [[Category:APIDesignPatterns:Anti]] | ||
Current revision
There is an old observation: when you have a hammer all problems look like a nail. Wikipedia calls it law of the instrument.
Doing the Same Thing. Expecting Different Results
It is tempting to stick to tools, policies and solutions that have proven to work in the past. They have a history, they are familiar to us. We can project what they can do. It is comfortable to not change the winning team. Still it may not be the best choice.
At the end we want to achieve something new. By repeating what we have done in the past, we can hardly get something different. We can apply similar practice, we can just follow the pattern, but in order to do so, we should recognize the basic pre-requisites (that may be hidden from horizon of our shallow understanding) that are critical to applying the hammer properly.
Substitution
Once I heard a quote from a member of Die Grünen and Greenpeace about the latter organization: We started as fighters against nuclear weapon testing (a very laudable goal, I'd say), but since then we turned to be against anything nuclear. Something must went wrong.
As someone watching from a distance, I can't help seeing the Greenpeace having a hammer (a successful fund raising when fighting against nuclear weapon testing) and using it on a completely different nail. Which is probably natural given the fact that all the nuclear weapons holders from the Greenpeace beginnings ceased on any testing and the organization needed to re-focus to be relevant.
Still the hammer law seems to be present. It is causing more harm than good as the Greenpeace credit (earned in the nuclear weapon testing fight) is now used to promote idea which has little to do with the original one. Some people find this kind of doublethink twist uncomfortable and humiliating for an organization that otherwise has a bunch of useful activities.
A NetBeans Hammer Experience
An IDE like NetBeans does not live in a vacuum and needs to play well with command line tools. However when two systems (the IDE and for example Hg or Git) are accessing the same files on a disk, we have a conflict. They may not properly understand each's other intentions. The IDE may then see sources which are not up-to-date or which are inconsistent.
Various IDEs solve this problem differently. Some ignore external changes all together and require an explicit refresh. Others try to detect the changes and refresh automatically at the right moment. Old NetBeans used to do a pull like check on gaining focus. New NetBeans comes with a native file system listener support and detect the changes as soon as possible (on a push basis).
The performance of the new system is certainly better in the old scenarios (as it eliminates needless checks at the moment when user wants to do something with the IDE and gives it focus). On the other hand the external tools did progress as well and there are new use-cases we have not dreamed of back then: Git users are shamelessly switching branches from command line, merging between them and meanwhile the NetBeans IDE gets confused (and burns the CPU like crazy). This is indeed a flaw.
Here we are getting to the hammer experience - some members of NetBeans community (Tim and his fellows) reminded themselves about the old, good on focus synchronization and started to push really hard for it as being solution to the problem. I can't help myself, but from my perspective it is like the Greenpeace replacement of nuclear weapon testing by fight against nuclear energy - it misses the root cause why the refresh on focus gained worked in the past.
The original use-case was to synchronize when there was a chance that an external tool was executed. To execute an external process one had to switch to terminal window or window of some other application. Obviously gaining focus back was relatively good moment to refresh (at least for short running external commands). The more often the IDE got focused, the more up-to-date its view of sources was. There was some sense in doing this.
However using a focus not gained to prevent the IDE from doing a refresh is a fragile black magic and not a user interface. First of all it is not easy to find intuitive UI, second it will lead to situations when people will be afraid to use Alt-Tab as they might accidentally switch to the IDE at inappropriate moment.
This is the kind of solution one gets when attracted by the hammer effect and seeing the nails all over.
Follow
