You've got 6 developers and 8 months to ship an MIS
application. This worries the person who is in charge
of the project (it's a tight deadline and he's
never seen a project comfortably make its deadline).
The project manager recognizes that he needs to do the
following before "real coding" : (1) get a complete list
of requirements and do domain analysis (2) create
prototypes and get user feedback on the GUI design and
(3) design the application.
Reasoning that "Hey. They've built similar things before,"
the assumption is made that all three can proceed
simultaneously.
After two months, the project has a prototype GUI (with
lots of inbuilt assumptions about how the rest of the
application is built), a generic "architecture" for a
"back-end" (because it was designed ignoring the GUI and
without a complete list of requirements) and a list
of requirements.
But, reasons the project manager, this is okay. Because
it looks vaguely client-serverish (and will look even
more so when the developers insert a "translation"
layer between the GUI and what the developers are
beginning to think of as "the real application"). Hell,
it's on one machine, but it's a genuine "3 tier"
architecture and isn't that a good thing ?
And so, development commences. And design continues,
because now there's this complete list of requirements.
And because the back-end actually has some coherent
logic to it, changes forced by the requirements
document are often foisted into the GUI or the
middle-layer ("since they were pretty much
designed-by-kludge it doesn't matter").
The result is a half-baked application that barely
does what it is supposed to, has lots of logic in the
widgets, and barely ships on time (if it even makes
schedule). The project manager realizes all of these
flaws and they reinforce his decisions (outlined in
paragraph 1). After all, even with maximizing his
use of developer time, he barely got the dang thing out
the door.
That's part of what I mean by
TooMuchGuiCode