To recap, adopting modeling techniques as part of the development process gives very distinct advantages to the project:
These are all valid reasons for employing modeling techniques on the project. However, not all software development organizations use modeling for the betterment of the software but for other, less laudable reasons:
Using only these reasons for adopting modeling on a project is a sure sign of the development team going through the motions of software modeling. Here, the application of modeling is construed as just another task on the project plan instead of as being central to the development process.
If development teams are not confident of the real reasons for using modeling methods, they risk engaging in cargo cult software development. In this situation, modeling becomes a time-waster rather than a time saver.
Cargo Cult Software
Stephen McConnell coined this novel phrase in an editorial for IEEE Software magazine [McConnell, 2000]. The term cargo cult comes from a description by theoretical physicist Richard Feynman [Hutchings, 1997] of a South Seas people who, during World War II, enjoyed the benefits of regular visits from Allied planes bringing supplies for the soldiers stationed there. The island nation prospered on the inflow of goods and materials delivered by the planes. When the war was over, the planes stopped coming and the good times ended.
Determined to have the planes return, the island people mimicked the actions of the Allied servicemen. They built runways and used fires for runway lighting; they constructed a hut to use as a control tower and staffed it with a controller who wore pieces of wood on his head as imitation headphones. Despite this careful attention to detail, the planes did not return.
The islanders' mistake was in associating the actions of the servicemen with the reasons for the arrival of the planes. Thus, they'd missed a fundamental piece of the puzzle.
In his article, Steve McConnell drew the same comparisons between software development companies who mimic the actions of their more successful competitors and expect the same results. They too are missing something fundamental, a basic understanding of the reasons for employing the process.
Although McConnell's article was on software processes, the same criticisms can be made of many software development teams who adopt model-centric development practices. All too often, UML diagrams are generated without fully appreciating their true value.