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