This is another piece of the amazing proliferating TooMuchGuiCode problem. It occurs after one or more projects embodying the first two aspects have already appeared. The project manager looks around and sees a whole bunch of GUI widgets. Scads of them just littering the ground. A slogan pops into her head: "Objects promote reuse." At the next design meeting, the suggestion is made that the current project could reuse parts of the last one. In particular, aren't those widgets *just like* the ones needed for the current project? Note, since we're early on in the SimultaneousDevelopment process, it's not clear just what the GUI ought to be. So, yes, those widgets are probably similar to what we need, but -no- please don't make us reuse them. Because it's rude to overtly say "that code was bad," reticence gets interpreted as a desire to express your individuality ("it's not my code, I don't want to use it") and the firm suggestion is made -- reuse those old components. So now, in your new application, you're going to wind up with bad gui objects that weren't thought out being placed willy-nilly in the GUI. And you can't go back and redesign them correctly because your project manager remembers (see SimultaneousDevelopment) that projects always run out of time and so you definitely don't have time to go do a correct redesign of already working code. E.g. you now need another layer of translation code. Congrats-- you've achieved object reuse ''and'' a 4 tier architecture. How ultimately buzzwordish. ---- See ModelFirst and SpartanUserInterface. Reused or not, GUIs will bury you and your team. Besides, it's easier to negotiate about them when the customer is hot to get things released. -- RonJeffries