Reflections on Reflection

Recorded at:

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

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

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.

What I have come to realize is that all data (or state) is is created and managed in the context of some conversational boundary that can span many interactions and have a time window of relevance that goes from nanoseconds up to years. These conversations can represent a contract or a transient association but it is the conversations and the signals that are enclosed within them that can drive runtime adaptation (behavior) - it is this that turns a class into an object.

Signals approach to what DCI is tackling is based on self organization, self regulation and self adaptation.
www.jinspired.com/site/introducing-signals-the-...

When I first came across this talks title I was hoping to see that reflection would be revisited in terms of behavior and not state or structure (as exposed by classes). There were hints of this possible direction but sadly nothing of significance. What is lacking today is self awareness and the ability to reflect on past, present and predicted behavior.

Going Beyond State/Structure Reflection in Java with Behavioral Tracking
www.jinspired.com/site/going-beyond-state-struc...

From Anomaly Detection to Root Cause Analysis via Self Observation
www.jinspired.com/site/from-anomaly-detection-t...