Object oriented frameworks impose additional burdens on programmers that libraries did not, such as requiring the programmer to understand the method callback sequence, respecting behavior constraints within these methods, and devising solutions within a constrained solution space. To overcome these burdens, we express the repeated patterns of engagement with the framework as a design fragment. We analyzed the 20 demo applets provided by Sun and created a representative catalog of design fragments of conventional best practice. By evaluating 36 applets pulled from the internet we show that these design fragments are common, many applets copied the structure of the Sun demos, and that creation of a catalog of design fragments is practical. Design fragments give programmers immediate benefit through tool-based conformance assurance and long-term benefit through expression of design intent.

A large financial company, struggling with legacy systems that did not interoperate, performed a pilot project to teach software architecture to an enthusiastic application development team. Experienced mentors, including the author, worked with the application team for seven months to complete their engineering goal successfully. However, the mentors were unsuccessful in their attempt to train any of the six members of the application team to create architecture models on their own, though they were able to create them collaboratively with the mentors. This surprising result is due to the application team's strong preference for concrete artifacts over abstract ones. Even more surprising, an application developer from a different project, "Developer X", read the architecture modeling documentation on an internal website and, without mentoring, created architecture models within a few days. In light of this failure to teach software architecture, two short-term strategies are suggested for the use of software architecture in companies.