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