Feel free to attend Jim Coplien’s research seminar on Friday at the Computer Science Department (IDA).
Date: Friday, Oct 3, 2008 Place: Alan Turing(House E, 1 floor). Time: 10:15
Jim Coplien, Gertrud&Cope, Denmark
Abstract:
To its end user, software is not a product, but a service. Procedural programming made it possible to reason about these services and their logic in which most problems could be found in low-cost but dutiful desk checks. The main correlation-like entity was the procedure, which could be assembled to collect large numbers of activation record instances into a few archetypical structures. In 1967, the ability to do this was taken away by object-oriented programming, which encouraged a style of programming where this user-focused structure was subordinated to the user's cognitive model of the static world: of its objects. The algorithmic view was further muddled by inclusion polymorphism. The Smalltalk anthropomorphic view and ever small method sizes made it necessary to understand dozens of atomic algorithms to understand even the simplest functionality. Progress in methodologies reduced this static view to an even more over-simplified and more static view in classes, the almost final step in removing our ability to reason about the end user system model. The final step was Agile methods, which focus on the customer -- the middleman -- instead of the end user, enabling a product focus instead of a service focus. This is even celebrated as a good thing.
Piecemeal, technology has slowly staggered roughly in the direction of the more primordial object view, and AOP has struggled to restore some of the algorithmic view. Roles and role-based modeling have brought back a bit more dynamic view of the system; we find their incarnation in Java and C# interfaces. There is renewed interest in dynamic programming languages and in the kind of flexibility one finds in traits. Trygve Reenskaug has combined these techniques and brought us full circle in the DCI paradigm. The "D" is for data modeling: what we know as traditional objects, though bereft of knowledge about scenarios. It captures the static structure of objects and their references on the heap. The "C" is for context: the mapping of roles onto objects on a per-use-case basis, implemented as a dictionary. The "I" is for interaction: an algorithm of a stateless role, written in terms only of other roles, that defines in readable terms what the system does. Object dynamics can be captured in interaction roles and melded with classes who use the roles as traits; interaction dynamics appear in a context object generated anew for every use case; and structural dynamics appear as references between elements of object data.
This design approach expresses several important correlations that long have been missing in object orientation. Rather than unifying all algorithmic cross-cutting into Aspects, it teases out important facets into the context and interaction, with the object model a third correlation that is usually presumed to be the base partitioning. These correlations conceivably compose in uniform and predictable ways because of their grounding in simple object concepts such as interfaces and classes, rather than cutpoints or wrappers and whoppers. It is an extended subset of multi-paradigm design, incorporating important elements of the procedural and object paradigms.
Speaker's Profile:
Jim ("Cope") Coplien is a Software Architecture and Agile Consultant at Gertrud&Cope in Denmark. He has a 25-year history as an "early adopter" and innovator behind several strategic innovations in software: his C++ Idioms book was one of the major sources for Design Patterns; his work on Organizational Patterns was one of the foundations of the structural components of XP and was the inspiration for Scrums. His books cover areas as diverse as C++ programming, software design, and organizational design. He has started writing a book on Agile software development. His current professional focus areas include Lean software architecture, highlighting the challenges of test-driven development, and Scrum process improvement using Organizational Patterns. His current day-to-day work includes architecture reviews, coding, and helping organizations work more effectively in lean economic conditions through process improvement and reduction of waste. His current hobby is creating advanced (housing) architecture CAD tools based on pattern languages. He lives with his wife and son in Mørdrup, Denmark. When he grows up, he wants to be an anthropologist.
Monday, September 29, 2008
Monday, September 22, 2008
Adapters in Python
Those of you who are interested in Python might find this presentation useful about adapter in Python.
You can also download the presentation slides from here
http://rhodesmill.org/brandon/adapters/
You can also download the presentation slides from here
http://rhodesmill.org/brandon/adapters/
The Observer Design Pattern - The You Tube variant
I found this while browsing on You Tube. There are several movies about design patterns from the same user. It is interesting, isn’t it? :-)
Monday, September 01, 2008
Six Impossible Things Before Breakfast
As a reaction to the first lecture and to the previous two blog entries I have received several emails. In those emails I'm sensing that some of you find it very hard to escape from the formal world of programming and exercise creativity. Imagination and creativity are important ingredients in any design process and contrary to what some of you believe, it can be exercised and trained. It not something that you are born with and it is not necessarily something that you learn in an art and design school. You can start practicing creativity by believing in impossible things. If you have doubts that you cannot be a good designer then take the advice of the Queen from Alice in Wonderland.
"Alice laughed: 'There's no use trying,' she said; 'one can't believe impossible things.'".
'I daresay you haven't had much practice,' said the Queen. 'When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast."
If you are still not convinced and you still do not know how to exercise creativity and visual thinking watch the following presentation:
"Alice laughed: 'There's no use trying,' she said; 'one can't believe impossible things.'".
'I daresay you haven't had much practice,' said the Queen. 'When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast."
If you are still not convinced and you still do not know how to exercise creativity and visual thinking watch the following presentation:
Design Thinking
During the fist lecture, I have mentioned that I will not let out the “design” concept from the design patterns course and we will discuss what makes design excellence in other science like architecture, cognitive science and, not in the last place, art. We have seen that design patterns in software engineering represent reusable solutions to commonly occurring problems in software design. Those solutions turned out to work well in a given situation therefore they have been captured in a pattern of catalog to facilitate reuse. Once you have identified the problem you can apply a pattern to solve it.
But how about the when you a have problem that has not been solved before and there is no satisfactory recipe to solve it? How one can solve such problems? What is the process for finding a solution?
Design Thinking is a new way of thinking about solving problems in which problem solving and innovation activities are closely linked with human-centered activities in which designer can take the role of the user. The product and the product development strategy are created by experiencing rather than simply carefully planning. For those of you that had contact with any of the agile development process this may sound familiar. Prototyping often in small development cycles and putting the customer in focus are the main driving ideas in any agile process. Among the multiple definition of the design term I like the one that states that “design is creativity in reaction to everyday problems”. That’s why I told you that I’m looking for creativity in this course. Thinking like a designer and using creativity is an important asset for every software engineer.
The June issue of the Harvard Business Review has just published an interesting article by TIM Brown CEO of IDEO on Design Thinking. If you are interested in some case-studies to see how design thinking takes place this article is a good start. Tim Brown gives also some guidelines on how to make design-thinking part of the innovation drill. Below I have selected some of the guidelines that I consider relevant for the software development process.
Begin with the beginning. Design thinkers should be involved from the very beginning of any innovation process. In this way more ideas would be explored that otherwise would have disappeared.
Take a human centered approach. I could not agree more. Technology is only one part of the story. One should never forget that technology is to make users life easier. In the design thinking process, the customer is on focus (like in any agile development method).
Try early and often. This sounds actually very familiar from the Agile Manifesto: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. Prototyping is one of the main ingredients in Design Thinking.
Seek outside help. Consumers should be involved the design process. Tim Brown’s advice is to exploit Web 2.0 networks to enlarge the scale of innovation. My favorite example is the My Starbucks Idea web site in which Starbucks is encouraging customers to share, discuss and vote on ideas that could improve their business. Take a look and let me know what you think. It seems that finally a big company got the idea how to exploit an emerging technology and listen to the customers.
Find talent anyway you can. Tim Brown advocates for interdisciplinary teams that can have a new perspective over the problem and a new way to find solutions. Sometimes I have the impression that some web sites are made only by software engineers. They could use some help from a multidisciplinary team including designers and usability engineers.
For Design Thinking in action you can watch the following movie made by a group of students from Stanford
Still not convinced? Maybe the following links would help:
But how about the when you a have problem that has not been solved before and there is no satisfactory recipe to solve it? How one can solve such problems? What is the process for finding a solution?
Design Thinking is a new way of thinking about solving problems in which problem solving and innovation activities are closely linked with human-centered activities in which designer can take the role of the user. The product and the product development strategy are created by experiencing rather than simply carefully planning. For those of you that had contact with any of the agile development process this may sound familiar. Prototyping often in small development cycles and putting the customer in focus are the main driving ideas in any agile process. Among the multiple definition of the design term I like the one that states that “design is creativity in reaction to everyday problems”. That’s why I told you that I’m looking for creativity in this course. Thinking like a designer and using creativity is an important asset for every software engineer.
The June issue of the Harvard Business Review has just published an interesting article by TIM Brown CEO of IDEO on Design Thinking. If you are interested in some case-studies to see how design thinking takes place this article is a good start. Tim Brown gives also some guidelines on how to make design-thinking part of the innovation drill. Below I have selected some of the guidelines that I consider relevant for the software development process.
Begin with the beginning. Design thinkers should be involved from the very beginning of any innovation process. In this way more ideas would be explored that otherwise would have disappeared.
Take a human centered approach. I could not agree more. Technology is only one part of the story. One should never forget that technology is to make users life easier. In the design thinking process, the customer is on focus (like in any agile development method).
Try early and often. This sounds actually very familiar from the Agile Manifesto: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. Prototyping is one of the main ingredients in Design Thinking.
Seek outside help. Consumers should be involved the design process. Tim Brown’s advice is to exploit Web 2.0 networks to enlarge the scale of innovation. My favorite example is the My Starbucks Idea web site in which Starbucks is encouraging customers to share, discuss and vote on ideas that could improve their business. Take a look and let me know what you think. It seems that finally a big company got the idea how to exploit an emerging technology and listen to the customers.
Find talent anyway you can. Tim Brown advocates for interdisciplinary teams that can have a new perspective over the problem and a new way to find solutions. Sometimes I have the impression that some web sites are made only by software engineers. They could use some help from a multidisciplinary team including designers and usability engineers.
For Design Thinking in action you can watch the following movie made by a group of students from Stanford
Still not convinced? Maybe the following links would help:
- Video of a presentation given by Tim Brown at the MIT Sloan School of Management
- Better Linux release notes through design thinking by Karsten Wade, article published in the Red Hat Magazine
- Intro to design thinking. An interview with David Burney conducted by Tim Hyer published in the Red Hat Magazine
- Hasso Plattner Institute of Design at Stanford University
Subscribe to:
Posts (Atom)
