I'm not convinced that code (as we know it) requires the same sort of literacy as the written word. For instance, it might be something for which fluency or participation takes other forms than "you must be able to create to be considered _able_". I think I agree that reflection is a good tool for handling unanticipated scenarios, and that local reflection allows us to incrementally adapt. But I don't think this is a complete vision. In fact, I see it as a remedy for an incomplete vision — reactionary rather than visionary. And as for self-organization, well... as we all know and all agree, (central) planning is the most efficient way to allocate resources, and self-organization at scale is anarchic and wasteful. (Come at me!)

(Disclaimer — I didn't watch the talk, because I live in a part of the world that doesn't have broadband, so if my hemming and hawing is cleanly parried preemptively by the speaker, kudos to them, apologies to you for the conjecture.)

... But anyway, that's not why I shared this; the main reason is how he focuses on humanity and the original human-centric vision of OO, and how he talks about using the human model to shape our code design. I subscribe to what DCI is trying to do, but not DCI itself. I try to capture system behaviors (i.e. pieces of the human model / use cases) as single coherent whole pieces rather than chopping then up along classes; but I don't see a need to try to do that in an OO way, e.g. still associating each piece with an individual role. I just let the "context" (which might be an object, or just a function) own the whole behavior itself

But anyway, I think Ivan & Jim Coplien are asking the same question: does anyone actually subscribe to these ideas? Where does it hold up, and where is it a dead end? Something in my gut tells me there's something seriously wrong / missing here (paraphrasing Jim, although I feel the same way).

...and to answer them myself: * All users write their own code: Maybe any user should be allowed to do so if so inclined; but I think that's the wrong question or thought, in the first place. All so should be able to own & shape their own tools & environment in whatever way (and to whatever extent) makes sense. That can (and should) mean LOTS of things other than dealing with raw code. * We can use reflection to code unanticipated scenarios The intent is that code already written (and compiled) can be supplied with a new "instance" that was not defined previously, and still work. So there's code saying "give me some X that has behavior Y, and I'll tell it when to do Y". You can then give it some new definition of X that it never heard of, even long after it was built & compiled, and it works. Traditional class-based-OO does this with interfaces & abstract base classes / virtual methods; but there are other ways, such as dynamic types, ST-style message passing -- heck, even HTTP REST qualifies as that style of message passing. For me, that's more about how do you properly design a system in terms of composable units, rather than using some clever polymorphic mechanism. I think that a lot of times the latter is an over-used / abused substitute for the first. E.g. using inheritance and interfaces to glue parts of code together that should have been coherent whole units to begin with. Or having poor software design such that one thinks that inheritance and overrides are necessary to be able to change the code in the future, versus having coherent code that is easy to understand and make direct modifications to to begin with. * Local reflection ... similar to the above. * Self organization is the order of the day I agree with Jim that this is a dead-end substitute for actual concrete system design. But I highly believe in creating an environment that the user can own psychologically and do as they please with

... I don't do it on purpose, but I think the appearance of my reply might start triggering an automatic need to find a comfortable place to sit down for a while :)

For any kind of tool, it’s maybe 1-2% of users that actively shape the tools themselves. Those 1-2% should be distributed across communities of practice, not sequestered in rich, urban, western bubbles.

For me, design requirements for software flow directly or indirectly from there.

So this is a core decision for me in the “maze”. I want to start by designing for the things only “non-IT” people can do—solve real world problems—and then steadily push to see how much of what’s currently relegated to professionals can be accomplished by users.

Rather than change programming as it’s currently practiced so it’s more accessible, lighter, etc. I expect many of the core ideas to be the same, but not all, or in the same order, or realized in equivalent ways.