This is a real-life example of Golden Hammer Anti-Pattern [1]. The characteristic of this anti-pattern is the tell-tale signs of the blind applications of a technique without question of their validity and suitability. The story below will illustrate this concept and the harmful effect that not only has on the product but also the company culture.
This is a story of a product and suffice to say that it is a serious business application. The product has set out with a form of architecture and has for a while religious following it. However, this reliance on executable, most like came from Unix background, soon become an obsession developed into a Golden Hammer Anit-Pattern. Everything has to be an executable. COM is then used to support automation allowing one executable to incorporate functionality that is packaged in another executable.
To be fair, the product does have DLL's but they are not inproc server. Normally using COM local server is not a bad thing but when the organization is trying to put dialog boxes in a COM local server and trying to maintain the modality across the process boundary, the fool-hardiness of such obsession becomes obvious.
This obsession breeds bad programming practice. Since these local server are registered to be single-use, the developers blatantly abuse the use of global variables. Since there is no code review or mentorship, this abuse becomes cancerous making correction relatively expensive and limiting their options.
The obsession is repeated over a number of years and successfully infecting several generations of management and technical leads. No one has raised a question.
The authors [1] are spot on in explaining why this lemming-like behavior is developed:
In many cases, the Golden Hammer is a mismatch for the problem, but minimal effort is devoted to exploring alternative solutions.Further more, the authors suggest the causes of this are:
This AntiPattern results in the misapplication of a favored tool or concept. Developers and managers are comfortable with an existing approach unwilling to learn and apply one that is better suited.
- Ignorance, Pride, Narrow-mindedness
- Reliance on proprietary product features that aren't readily available in other industry products.
Here are some of the harms in this obsession representing in real term missed opportunities to provide innovative product and to exploit new products/platform:
1) Because everything is packages as COM local server, the product is unable to provide correct user-experience reliably. Often forms packaged in another COM local server fails to sit on top of the 'owner' form (the launcher). Extraordinary amount of effects over the years are expanded on trying to fix this problem ignoring that a simpler solution using in-proc server would immediately fix this courtesy of Microsoft. Pride and Ignorance have a lot to do with the blindness in recognizing this simple solution.
2) Because the process isolation shields the developers of the harmful effect of blatant reliance on global variables, they even use global variable to do the job of the this pointer, an obvious sign of lack of training in OOP.
3) The obsession has produced a culture so blind that when they considered moving to .Net technology, as everyone did, they refused to concede the inappropriateness of the executable model in the .Net architecture. As most .Net developer would tell you that you cannot develop COM local server using .Net languages but you can for in-proc server. "Igorance" as the authors suggest the cause of this disease, blinding them so badly they ignorantly believing .Net Remoting is a replacement of COM local server that needs no registration.
Instead of taking time out "to exploring alternative solutions", they develop a technique to bend the .Net framework to maintain their obsessive behavior using .Net Remoting. This is chalk-and-cheese difference but to them this is brilliant.
The end results are excessive consumption of memory, slow start up etc. producing a laughable implementation that is neither .Net architecture nor Unmanaged COM local server one. Management did not even thought of the inappropriateness of their flawed architecture. Poor customers.
Had they been less blatant in using global variables, they could have easily transformed their code from an executable model to one using assemblies thus giving them registration-free deployment without being obese.
The authors [1] are perfectly in their observation and suggested refactor technique:
Philosophically, an organization needs to develop a commitment to an exploration of new technologies. Without such commitment, the lurking danger of over reliance on a specific technology or vendor tool set exists. This solution requires a two-pronged approach: A greater commitment by management in the professional development of their developers, along with a development strategy that requires explicit software boundaries to enable technology migration.So true.
[snip]
In addition, software developers need to be up to date on technology trends, both within the organization's domain and in the software industry at large.... They can also form book study clubs to track and discuss new publications that describe innovative approaches to software development. In practice, we have found the book club paradigm to be a very effective way to exchange ideas and new approaches....
[snip]
... is to encourage the hiring of people from different areas and from different backgrounds...
Finally, management must actively invest in the professional development of the software developers, as well as reward developers who take initiative in improving their own work.
[1] "Anti-Patterns - Refactoring software, Architectures, and Projects in Crisis" by William J. Brown, Raphael C. Malveau, Hays W McCormick III, Thomas J Mowbray
No comments:
Post a Comment