Simultaneous Development

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