Seit ein paar Monaten ist die neue Ausgabe des Entwurfsmusterbuchs verfügbar. Dies ist meine Übersetzung des Klassikers “Design Patterns” von Erich Gamma et al. aus dem Amerikanischen. Mit der neuen Ausgabe kommen einige Neuerungen und Änderungen. An erster Stelle zu nennen wäre der neue Umschlag:
Erster Vorschlag für den Umschlag der neuen Ausgabe
Der tatsächliche Inhalt der Sprechblase in der endgültigen veröffentlichten Fassung ist ein anderer und lautet: “We present you the book that changed software design.” Da die Viererbande (Gang-of-four) noch auf ein Nachfolgebuch mit weiteren Mustern hofft, habe ich Addison-Wesley’s ursprünglichen Vorschlag entsprechend geändert.
Abstract: Design patterns help in the creative act of designing, implementing, and documenting software systems. They have become an important part of the vocabulary of experienced software developers. This article reports about the author’s experiences and lessons learned with using and applying design patterns in industry projects. The article not only discusses how using patterns benefits the design of software systems, but also how firms can benefit further from developing a firm-specific design language and how firms can motivate and educate developers to learn and develop this shared language.
Here the slides for my OOPSLA Onward! 2009 talk on “Design Pattern Density Defined.” First the abstract:
Design pattern density is a metric that measures how much of an object-oriented design can be understood and represented as instances of design patterns. Expert developers have long believed that a high design pattern density implies a high maturity of the design under inspection. This paper presents a quantifiable and observable definition of this metric. The metric is illustrated and qualitatively validated using four real-world case studies. We present several hypotheses of the metric’s meaning and their implications, including the one about design maturity. We propose that the design pattern density of a maturing framework has a fixed point and we show that if software design patterns make learning frameworks easier, a framework’s design pattern density is a measure of how much easier it will become.
Abstract: Design pattern density is a metric that measures how much of an object-oriented design can be understood and represented as instances of design patterns. Expert developers have long believed that a high design pattern density implies a high maturity of the design under inspection. This paper presents a quantifiable and observable definition of this metric. The metric is illustrated and qualitatively validated using four real-world case studies. We present several hypotheses of the metric’s meaning and their implications, including the one about design maturity. We propose that the design pattern density of a maturing framework has a fixed point and we show that if software design patterns make learning frameworks easier, a framework’s design pattern density is a measure of how much easier it will become.
Reference: Dirk Riehle. “Design Pattern Density Defined.” In Proceedings of the 2009 Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA Onward! ’09). ACM Press, 2009. Page 469-480.
In software engineering, it is an old question whether you are “using” a component or whether you are “reusing” it. People tend to use these two terms interchangeably, annoying those among us who are trying to put precise meaning to terms. Alas, I don’t know of a good commonly accepted definition. I only know that “reuse” is an over-used term, mostly because “reusing” has more cache than “using”.
After reading some legal material, I’m wondering whether the copyright lawyers already solved this problem.
Abstract: A software forge is a tools platform for collaborative software development, similar to integrated CASE environments. Unlike CASE tools software forges have been designed for the software development practices of the open source community. Open source software projects succeed where waterfall and agile methods fail: They can cope with changing requirements and they can scale to large project sizes. Thus, corporate software development can learn from open source best practices. In this presentation, I discuss our experiences with using a software forge to bring open source best practices into SAP. We present the design principles and benefits of a firm-internal software forge, and we present a case study of how one project inside SAP benefited significantly from being on the forge.
Reference: Dirk Riehle. “Bringing Open Source Best Practices into Corporations Using a Software Forge.” Talk at SEACON 2009. Hamburg, Germany: 2009.
Abstract: Over the past 10 years, open source software has become an important cornerstone of the software industry. Commercial users have adopted it in standalone applications, and software vendors are embedding it in products. Surprisingly then, from a commercial perspective, open source software is developed differently from how corporations typically develop software. Research into how open source works has been growing steadily. One driver of such research is the desire to understand how commercial software development could benefit from open source best practices. Do some of these practices also work within corporations? If so, what are they, and how can we transfer them?
Keywords: Inner source, firm-internal open source, corporate source, software forge, open collaboration, open source.
Reference: Dirk Riehle, John Ellenberger, Tamir Menahem, Boris Mikhailovski, Yuri Natchetoi, Barak Naveh, Thomas Odenwald. “Open Collaboration within Corporations Using Software Forges.” IEEE Software, vol. 26, no. 2 (March/April 2009). Page 52-58.
The title of this blog post is my paraphrasing of a “law” from the tongue-in-cheek but nevertheless somewhat serious book “Systemantics” by John Gall. I tracked it down through Grady Booch’s original OOAD book and it had been pointed out to me by Ralph Johnson.
What’s so special about this quote? Well, it frames an inconvenient truth rather nicely: That you can’t create a complex system from scratch. Rather you have to evolve it step-by-step from a simpler system. This clearly runs counter to the intuition of many top-level IT or R&D managers. Thus, the unabated stream of expensive software project failures.
Open source and wikis are great examples of this proverb because of their (typically initially at least) volunteer nature. If they don’t work, they’ll get deserted quickly. If they get deserted, they are dead, and you don’t want that, if you are working on the project. Hence, this mechanism keeps you focused on the value the project or wiki provides to its users.
Reference: Steven Fraser (editor). “Escaped from the Lab: Innovation Practices in Large Organizations.” In Companion of the 2008 Conference on Object Oriented Programming, Systems, Languages, and Applications (OOPSLA ’08). ACM Press, 2008: Pages 787-790.
Available as a PDF file; my part follows as HTML below.
Position statement for the OOPSLA 2008 Panel on Innovation Practices in Large Corporations
In most companies, the innovation process is organized as follows: A research unit suggests to build a prototype of some innovative product or feature, a line-of-business sponsor signs off on the project, the research unit develops the prototype, a product unit receives it and turns it into a real product.
The critical point is the transfer from research to product unit. Here, many things can go wrong, for example:
Title: End-User Programming with Application Wikis: A Panel with Ludovic Dubost, Stewart Nickolas, and Peter Thoeny
Author: Dirk Riehle
Abstract: Wikis empower users to collaborate with each other using prose. Users imprint data structures and processes onto wiki pages using social and technical conventions. Application wikis enhance wiki engines with lightweight programming features that aid in making data structures and processes explicit. Using these features, end-users can program a wiki to better support them in their collaborative processes and integrate their work into the overall IT infrastructure. Application wikis make database access and business process integration easy from within the wiki while maintaining the wiki-style of collaborative work. The panelists of this panel, together with the audience and the moderator, will review existing work and explore future research directions in application wikis.
Reference: In Proceedings of the 2008 International Symposium on Wikis (WikiSym ’08). ACM Press, 2008: Article No. 4.