I just listened to Eberhard Wolff’s BED-Con talk on microservice-based system architectures, which he prefers to call Independent Systems Architectures (ISA). One purpose of calling it ISA is to emphasize that there should be no common data model and no shared reusable libraries between microservices. Obviously, by discounting reuse, ISA may increase development speed short-term while increasing cost and quality problems long-term. Eventually, in his talk, Wolff came around and argued that microservce implementation independence and reuse are a trade-off rather than an either-or decision.
When teaching about modeling the world, I often talk about how concepts should be MECE, that is, mutually exclusive and completely exhaustive. I didn’t invent this acronym, I took it from Barbara Minto’s writings about structured reasoning.
I finally figured out the appropriate German translation, and, oh wonder, it is shorter than the English version. It is:
Überlappungsfrei und erschöpfend.
While preparing a session on (object-oriented) object creation for my Advanced Design and Programming course, I noticed that there are at least two major ways of looking at how to decide on how to create an object. The traditional way is a (still unwritten) pattern language that utilizes the classic Gang-of-Four object creational patterns (and then some) to guide the developer in designing the object creation process.
Fortunately, object creation has a neatly defined design space with clearly independent dimensions and hence lends itself well to a structured discussion. Without further ado, here are the dimensions of this design space as I see them:
Stack Overflow of the “full stackoverflow programmer” fame just published a developer survey. Among the items was a question asking developers, what they prefer for indenting their code: Tabs or spaces?
The majority of developers prefers tabs over spaces by a reasonable margin. What worries me, though, is the conclusion or the “trend” that the summary writer sees in the data: That more experienced developers prefer spaces over tabs.
According to this article, Google’s 20% time never really existed. I’ve always guessed as much, joking with Google friends that their 20% time really could only be taken on Saturday and Sunday. Which is all the same: Engaged employees do what they feel needs to be done no matter what and when.
Hackathons, however, exist. Facebook, SAP, and Suse are example companies that organize them with the purpose of prototyping potential new products. For all that I can say, the dirty little secret is that there are no successful hackathons without 20% time (make it +/- 15%). I’m betting that rarely was there a successful hackathon without a run-up to the hackathon that involved significant preparation, that is, “20% time”.
As a consequence, for hackathons to succeed, employees must not be disenfranchised or overworked. Otherwise they won’t spend their personal time talking about and preparing for a hackathon. Also, they should have a purpose, that is, be tuned in to the company’s mission. I guess this means that the better the company is doing, the more likely it is to get something out of their hackathons.
Addison-Wesley asked the patterns community (or at least those who were there at the beginning) about their opinion on various issues. This is the second post of what should have been three (though I probably will only get to the first two).
For this very specific question, I expect everyone to say: Retire Singleton!
I beg to differ; for its time, Singleton was right. “Its time” mostly means single-threaded C++ code, as written by 3 of the 4 authors of the Design Patterns book. Today, many will argue that multi-threaded Java programs have made Singleton obsolete and even harmful. In my take at design patterns that would be wrong. Singleton should not perish, it should simply be adapted to its time. What ever thread-local information you may have, some it will be global to that thread. How is that not a thread-specific singleton? Or, take a group of application servers acting as a group: How is the group communication protocol not to provide a global id that makes the group identifiable and provide some global state attached to it? This may not be your granddaddy’s good ol’ singleton, but a singleton it may be nevertheless.
This is also where pattern descriptions will pass (or fail) the test of time: Does the original description of Singleton allow for these variations or not? If not, it may have been too narrow a description. I’d assume then that specific usage examples, tied to the programming languages and systems and technologies of its time, dominated the description and the abstracion process “out of examples, timeless patterns” did not yet conclude.
Beyond Singleton, some may want to retire Visitor, mostly because we find functional programming concepts being added to programming languages more and more, and multiple dispatch (which Visitor is about) comes for free. I say: Simply be precise about the scope. Visitor is (kind of) fine for Java but in a different context may not be needed as a design pattern because it has been cast as a language feature.
Design pattern should evolve and there is nothing wrong with it. John would approve.
A summary of all posts can be found on the InformIT site.
PS: Turned out, not many on the InformIT site were pointing to this issue. Looks like I was beating a dead horse!
Addison Wesley is going to celebrate the 20 year anniversary of the Design Patterns a.k.a. Gang-of-Four book. For this, they reached out to the community and asked for contributions. Here are the questions they asked, suggesting we ask (and answer) our own ones as well:
- How has Design Patterns affected you and your career?
- How has it changed how you think about software development?
- Do you have specific recollections of the book’s release?
- How do you use design patterns today?
- Which Patterns should be retired?
- Which new Patterns should be added?
I’ll provide my answers to questions 1-4 here and I’ll answer questions 5-6 in separate follow-on posts later.
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.