Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Presentations Reflections on Reflection

Reflections on Reflection



Jim Coplien believes that we have done OOP the wrong way for 40 years, and suggests an approach to reflection based on the DCI paradigm and influenced by the human society.


Jim ("Cope") Coplien is the father of Organizational Patterns and one of the founders of the Software Pattern discipline, a pioneer in practical OO design in the early 1990s and is a widely consulted authority, author, and trainer in the areas of software design and organizational improvements. With Trygve Reenskaug he is a co-originator of the Data, Context and Interaction (DCI) paradigm.

About the conference

SPLASH is the ACM conference on Systems, Programming, Languages and Applications: Software for Humanity. SPLASH is an annual conference that embraces all aspects of software construction and delivery. This is the premier conference at the intersection of programming languages, programming, and software engineering.

Recorded at:

Mar 01, 2013

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Reflections on Reflection slides

    by Carlos Silva,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great talk!
    Some slides have superimposed texts. Can fix?
    Thank you. I will read your book again e try hard, now...

  • How about using AOP to implement this

    by Wouter Hermeling,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    To implement the behavior of the use cases into the objects, can AOP be used for this. Any thoughts/comments on this?

  • Fail to see how DCI affects User Experience

    by Adam Nemeth,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I normally agree with Coplien, but I still fail to see how DCI helps us build a world keen to Alexander's vision of his IEEE talk.

    I think, or rather, I believe, that the way to catch end user's mental models is to sit down with them and speak to them a lot and design in front of their eyes.

    What does it mean? Watching them use the previous systems. Making them talk about their realities. Show them drawings. Ask them to play make-believe with those.

    For the user, the user interface is the software. His/her daily life is the system. Anything behind the user interface? Doesn't matter to them.

    We should design for the real problems. We shouldn't use abstract words. We abstract them out later. Of course we abstract them out! But we should be able to show the code afterwards to a user, to any user basically, and they should be able to reason about it, and understand how it's connected to their daily life! I call it the "janitor test", and I regularly do it (hint: first remove type declarations: users don't need that).

    Classes were never about object orientation: they are a way to structure code. It's a way to put things into a logical structure! Forget Alan Kay, the way we use classes is how it's written by Dahl in Structured Programming from 1972! Is it wrong? It's fine! It's about put the code where you expect to find it! Put things together which change together.

    Just like we expect users to be able to find the thing they need right now in a menu structure of a large webpage (think of a government site or such) we build code hierarchies primarily to let programmers find it quickly!

    Of course, we should still build code where we can reason about behaviour. You press a button - you should be able to look up what that button does in the sourcecode just by looking up the file structure.

    But that's through process and not through structure! Remember what Alexander said in Nature of Order: forget the structure, a structure is only good as the process it was born through! Concentrate on your design process instead, make sure that every single part of that design is about the central topics of the problem you design against!

    I fail to see how could we make user-reconfigurable systems if we build context into the whole model. If you build your system around context, how do you expect users to use its elements out of their designed context?

    I don't believe everyone should be an architect, but I believe we should design architecture - and let me use a strange definition: architecture is whatever a user can't change for themselves as it'd cost a lot of effort, knowledge, or tools - in a way that users don't even think about it.

    I usually say I like to design tapwater applications: when you open the tap, you don't even think about wether the water would flow. It's not natural, especially for high-rise buildings. But it's so well-designed, that for 364 years a day, you don't even have to think about it, and you can reconfigure it to whatever purpose you see it fit, cooking bathing or anything else.

    Sometimes I feel that as the developer community as a whole neglected users, the design of our actual buildings - the software - is into the hands of UX designers, and developers are merely the construction workers making dreams a rigid reality.

    But I hope this won't be about putting the bolts together for that long. Would DCI be the way out? I'm sorry but I can't see that still.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p