(via diveintomark): Compare two very different software development strategies: NASA (expensive, precise, almost "perfect", with functional specifications weighing in at around 50% the size of the code) and Linux (ad-hoc, evolution over design). I've always been on the side of evolution, for the simple reason that it's easy to spend enormous amount of time building exactly the wrong functionality. With incremental development - starting with the sketchiest ideas of the required functions, building something to play with, asking the customer where they'd like to take it next - the formal specification phase doesn't turn a committee's guesswork into tablets of stone. Lots of Notes/Domino systems are built incrementally because it's possible to build them this way: evolvable data structures, very quick deployment, and little separation between the user environment and the development environment.
My experience with the UML seems to show its value in communicating the design, as much as in specifying and modeling the system; at Agora we learnt the value of use-case driven designs and specifications by teaching the client our language (to some extent). It worked because we found or created a common language for our private conceptual models of the system. This is something of what Schrage means by "shared space", and something of why Groove is a good model-sharing platform.