We have ThinClient. We see all the problems with ThinClient that would be solved if we had ThickClient. We all migrate to ThickClient. We start to see all the problems with ThickClient that would be solved if we had ThinClient, and we've forgotten all the problems we had with ThinClient. So, we all migrate back to ThinClient. Repeat.

We notice lots of code that is repeated among lots of applications on our systems. Wouldn't it be nice if we eliminated that duplication? Wouldn't it be great if all programs would be automatically improved by improving some shared code? So we invent dynamic/shared libraries. Then we discover DllHell. We find that upgrading the shared code automatically breaks as many applications as it improves. So, we invent ways for each application to get its own isolated copies of the shared code. Repeat.  

(To be fair, much of the motivation for DLL sharing appears to be to reduce the file foot-print of suites. However, as disks grew cheaper and CD's replaced floppies, that became less of an issue. Thus, the decision was understandable. History of microcomputer software is full of trying to squeeze as much as possible into small packages because they had to out of necessity.)

----
There is a very good reason for what might seem to be an arbitrary flip-flop: in between swings of the "pendulum", the underlying forces change.

ThinClient originated because CPU resources were relatively dear, and "network" resources (serial lines, actually) were relatively cheap.  When CPU resources became relatively inexpensive faster than network resources, ThickClient evolved.  When network resources started becoming cheaper, ThinClient again became feasible.

Similarly, shared libraries were a big win when memory and storage were costly and version conflicts were few.  Now that memory and storage are cheap and version conflicts are relatively expensive, the costs are beginning to outweigh the benefits.
----
Too often, though, the choice is made to go with the generalizations of the CurrentConventionalWisdom rather than what makes the most sense for the specific service being (re)implemented.
----
Now we have a thick client (windows PC) running a thin client (browser) which uses thick client controls (activeX) that use thin client messaging (xml web services). And after all this, there is horrid performance, usability and deployability.
----
(Another thing that I was thinking of when I started this page, but forgot to include:)

Sometimes the pendulum isn't technological. It could be business process. e.g. A software company that keeps switching between ReleaseEarly & ReleaseLate.

Typically this is because of myopic executives who can only see the current problems, not the past or future problems. Although this may be a side-effect of too rapid change of the faces in the executive suite.
----
SeptemberZeroSix

CategoryAntiPattern