I’m looking for simple examples of product management failures and challenges that I can use in teaching our product management course. Photos or short stories would be great. To give you an idea of what I’m after, here are three examples.
This unmaintainable cup with saucer is probably a best seller, but I’d only give this as a gift to a person I don’t like. It will probably be destroyed during the first dishwasher run or will cause cleaning grief to the owner for many years to come.
The interest remains; I’ve given my new talk on Inner Source at a couple of companies now (ask me!) and next time will be at CMU (in Silicon Valley, broadcast to Pittsburgh) next Tuesday, November 5, 2013. The talk was originally going to be hosted by Tony Wasserman, now by Hakan Erdogamus, and is open to the public. Looking forward to it!
This coming Wednesday, September 18th, 2013, starting at 6:30pm, I’ll be giving a talk on inner source (“open source best practices inside companies”) applied to product line engineering at Hewlett Packard in Palo Alto, CA (3000 Hanover Street Building 20, Palo Alto, CA 94304). The San Francisco Bay Area ACM chapter is the host, see the original announcement (including directions).
This talk is free and open to the public. It is one of my current talks, probably the most popular one. For your convenience, here is the full information:
A screenshot from Fitbit’s German website this morning. The issue is circled in red, a scale with a “feel-good” weight of 122.5. Amusingly enough, this only feels good if you live in the colonies. Germany is not part of it. Here, the metric system rules, not the imperial one. 122.5 on a scale will be interpreted as 122,5 kg, which amounts to a whooping 270 pounds. So much for getting fit with Fitbit!
The lesson for software design, of course, is that if you go international, you have to be culturally knowledgable and sensitve. And you have to pay attention to detail. That’s what we are trying to teach our students who are working hard to become product managers. Maybe we should add this example to our PM by Case collection?
During a trip to New Zealand I found this wool store near Taihape, on the road between Taupo and Wellington. I bought a couple of pieces and was so happy that I went to their website to buy some more, which also turned out to be a pleasant experience. However, when I returned yet again, a few days ago, they had changed the website: I was now being quoted in Euros, my native currency, and not in New Zealand dollars any longer.
Abstract: Wiederverwendung von Softwarekomponenten verspricht, Softwareentwicklung schneller und günstiger zu machen und die Ergebnisqualität zu steigern. Trotz diverser methodischer Ansätze ist es für viele Softwareentwicklungsorganisationen schwierig geblieben, diese Ziele auch nur ansatzweise zu erreichen. Vor diesem Hintergrund bietet „Inner Source“, die Verwendung von Open-Source-Praktiken in der firmeninternen Softwareentwicklung, neue Chancen. Inner-Source-Software ist Software, die innerhalb eines Unternehmens über Profit-Center-Grenzen hinweg in Gemeinschaftsarbeit entwickelt wird und von allen Abteilungen genutzt werden kann. In diesem Artikel stellen wir die bisher gewonnenen Erfahrungen mit Inner-Source-Entwicklung dar, definieren organisatorische Gestaltungsmöglichkeiten und prognostizieren die Entstehung von Inner-Source-Organisationen, einer neuen Form der Organisation für die Wiederverwendung.
Keywords: Open source; inner source; software code reuse; knowledge sharing; firm-internal open source; open collaboration
Reference: Dirk Riehle, Detlef Kips. Geplanter Inner Source: Ein Weg zur Profit-Center-übergreifenden Wiederverwendung. Friedrich-Alexander University Erlangen-Nürnberg Technical Report CS-2012-05. Erlangen, Germany: 2012.
At FAU, we are now holding our so-named “software architecture” seminar for the second time. It is important to realize (for students as well as the general public) that “software architecture” is a metaphor (or, maybe more precisely, an analogy). Architecture is a discipline several thousand years old, while software architecture is only as old as software engineering, probably younger, if you make Shaw and Garlan’s book the official birth date of software architecture, at least in academia.
Abstract: The design of software development tools follows from what the developers of such tools believe is true about software development. A key aspect of such beliefs is the size of code contributions (commits) to a software project. In this paper, we show that what tool developers think is true about the size of code contributions is different by more than an order of magnitude from reality. We present this reality, called the commit size distribution, for a large sample of open source and selected closed source projects. We suggest that these new empirical insights will help improve software development tools by aligning underlying design assumptions closer with reality.
Reference: Dirk Riehle, Carsten Kolassa, Michel A. Salim. “Developer Belief vs. Reality: The Case of the Commit Size Distribution.” In Proceedings of Software Engineering 2012 (SE ’12). Springer Verlag, 2012. Page 59-70.
The paper is available as a PDF file. The survey used in the paper is also available as a PDF file.
Titel: Geschäftsrisiken und Governance von Open-Source in Softwareprodukten
Zusammenfassung: In fast jedem Softwareprodukt, auch in großer Standardsoftware, sind heute Open-Source-Komponenten enthalten. Die Hersteller dieser Software müssen die Geschäftsrisiken, die mit der Integration von Open-Source-Software in kommerzielle Produkte verbunden sind, verstehen und vernünftig managen. Dieser Artikel zeigt ein Modell verschiedener rechtlicher, technischer und sozialer Risiken auf, die durch unkontrollierten Einsatz von Open-Source-Software entstehen und erläutert ausgewählte Erfolgsmethoden der Open-Source-Governance, die von führenden Firmen angewandt werden. Das Modell ist das Analyseergebnis von fünf mit großen deutschen Softwareherstellern geführten Interviews sowie weiterer Literaturrecherche.
Trying to wrap my head around the Open Cloud Principles put out by the revamp of the Open Cloud Initiative, I’m happy to note that software engineering research has something to say to the challenges these principles will face.
Every real-world specification is an underspecification.
So, well, I say that, but I doubt that I’m the first one to have learned this from 30+ years of software engineering research. This principle leads us directly to the challenges anyone is facing who is trying to be truthful to the intentions behind the Open Cloud Principles.