Ted Johnson on Programming & Architecture

Over at Stack Overflow a question was posted " Is UML practical? ". The question itself is fine, but several of the answers were so narrowly focused. I believe that the everyday developer only sees UML as only a common set of shapes drawing a picture. Granted it has a common set of shapes for notation, but UML is first and foremost about modeling. (Big surprise coming from a Modeling Website). Where did this dis-information come from? In my experience the UML for diagrams message comes from schools/universities and popular UML books. Schools will often only teach UML as a way to diagram the solution you and your team of group participants are going to code up. Well of course it seems a little redundant in that contrived learning environment. UML's concepts are to large to teach in the same class as project management 101 or multi-developer projects 101. Most people just don't go any further with it and thus the collective knowledge is that UML is for making d

The "Done, and gets things smart" phrase coined by Steve Yagge and the "Smart and gets things done" phrase and book by Joel Spolsky are great mantras of modes of operation for technology geeks. Modelers should make special note however as the job of modeling is viewed as overhead or just smart people's diagrams. The "Done" part for modelers is critical in several ways. One, Modeling never seems to be done, it can always be improved and two, it always need to be done yesterday because the developers, business, PMs, and Stakeholders don't see direct value in modeling. Ok, modelers done means actually putting a line in the sand of when the model is good enough, and no this should not be based on your comfort level of showing everything or the number of elements and number of diagrams it should be based on the business needs and drivers, the amount of time the developers need to code up your crazy over engineered design, the market demands, whatev