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.

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 then 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.

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]]

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.

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 new. 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.

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 ==

== 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 wise choice.

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 new. 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.

At the end we want to achieve something new. By repeating what we have done in the past, we can hardly get something new. 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.

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.

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 then a user interface. First of all it is not 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.

However using a ''focus not gained'' to prevent the IDE from doing a refresh is a fragile black magic then 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]]

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.

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 refresh is more a black magic then a user interface. First of all it is not 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.

However using a ''focus not gained'' to prevent the IDE from doing a refresh is a fragile black magic then a user interface. First of all it is not 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]]

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.

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 more a black magic then a user interface. First of all it is not 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.

However using a focus (not) gained to prevent the IDE from doing refresh is more a black magic then a user interface. First of all it is not 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]]

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.

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 more a black magic then a user interface. First of all it is not 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.

However using a focus gained to prevent the IDE from doing refresh is more a black magic then a user interface. First of all it is not 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.

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]] of ''nuclear weapon testing'' by fight against ''nuclear energy'' - it misses the root causes why the ''refresh on focus gained'' worked in the past.

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). There was some sense in doing this.

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.

And here we get 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]] of ''nuclear weapon testing'' by fight against ''nuclear energy'' - it misses the root causes why the ''refresh on focus gained'' worked in the past.

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]] of ''nuclear weapon testing'' by fight against ''nuclear energy'' - it misses the root causes 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). There was some sense in doing this.

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 does bunch of [[good]].

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 ==