This is interesting. While this seems reasonable in the context of ModelFirst, how does it relate to continued evolution of a system. After a while I've got some UI. Does this just slow me down, live with it, or are there ways to deal with this while continuing to move quickly, refactor mercilessly, etc.
  -- AlanKnight
-----
UserInterfaceInertia comes from many sources.  If you release the user interface early, documents may be written describing it.  Users may be trained upon it.  And once you have a bunch of users that know the interface, it can be very difficult to make changes.

From the development point of view, creating the user interface may add constraints to the business rules and models.  One is then faced with either creating sub optimal structures for the business rules and models, or changing the UI.  If the UI is big, there will be pressure upon you to leave it alone and change the structure of the model.   And, of course, that's a move that someone will eventually regret.

--RobertCecilMartin -- 9/8/99

...and yet...  there ''are'' apps where the UI is 90% of the success of a shipping product.  Additionally, if you're working in the vicinity of shrinkwrapped Win32, your resulting code-base will be at least 50% UI code in any of VB, VC++, BCB, SDK C, or Delphi.  Generally, too, the overall metaphor for UI, either event-driven or program-driven, will have ''profound'' impact on the resulting problem domain code.

None of these is any excuse for a) not striving mightily to isolate model code from ui code, or b) not trying to tackle the model first as far as possible.  It's just that there are plenty of tricky corner cases, and hard and fast rules about ignore-ui-until-model-runs can be deadly mistakes.  That having been said, its obvious that in general, journeyfolk overemphasize UI development, and many more people make the mistake of coding UI before coding model than the other way around.