Beautiful talk! And I loved James’ humorous illustration of the etymology of Scrum. It’s a shame that no one would be willing to make physical contact with one another anymore in this post-COVID world 😢
This was an amazing talk. Absolutely stunning and reinforced many of my personal intuitions of successful development. I tell my teams - the Domain Model must match reality as closely as possible and you will not need to fundamentally change it, everything falls into place when you do.
Great talk. Most developers probably won't get it, but great talk nevertheless. I especially liked the part about sprints failing 50% of the time. It's such an obvious thing, yet I haven't thought about it after many years of working in various Agile teams. For people who don't get it: 1. Watch some Alan Kay presentations. OOP was about self-managed objects and message passing. Java doesn't have any of that. 2. Unit tests are supposed to be _tools_ to achieve product quality. Instead, developers wave those things around as _proof_ that their products do not suck. If your product doesn't suck, you better have something to measure it by other than your process. At the end of the day no one cares about your process. 3. CD means things change all the time. Users don't like that. Users like stable software. 4. Refactoring is rework. Plain and simple. Good software is simply changed and extended, not refactored.
Amazing talk, and a much better presentation style than the one at GOTO Con 2017. I had some of my answers questions that were raised by the same presentation by the same person just one year later -- I think this one was better as such.
Personally, I am not sold on the idea that "class-based programming" is inherently bad, but I am definitely sold on the idea that mocking at method level with mocks is crazy. And a few other things.
31:40 - continous delivery. You said that CD is bad and users hate it without really saying why. What are the downsides from the users/customers point of view? 33:35 - Lufhtansa. What does it have to do with OO? Crappy UX == no OO? 35:59 - Separation. Splitting a system into cohesive, well defined parts doesn't mean that you don't think about how are they supposed to interact. How could it? 37:35 - how does planning remove the need for refactoring? I thought that we should decide on a goal and take a step to bring us closer to it. Then evaluate if the goal is still vslid and that the direction is ok and continue. But the goal might (and most likely will) change over time so even with planning rework is inevitable. 47:45 - tests. Sooooo... where do we get our automated regression tests from? Aren't they the documentation of things we learned during exploration testing? This in turn is just a way to figure out how exactly should something work. The purpose is not JUST to make the green bar come up but to make the green bar come up as a result of verification of our requirements!
Well, I would like to get a list of flights on some route on a specific day (and a few days before/after to compare prices), select the class, see how much it costs and pay for it. Last time I checked (a few months ago) it was more less how the process looked like on Lufthansa's website. Maybe I have my thinking already fixed on the provided model but it looks reasonable to me. How would you improve it? And how is it connected with OO? And I am not old enough ;)
Why CD can be bad... Believe he implied the side-effect of annoyances due to constant updates and user despair caused by continuous improvements which often spell total changes either to the User Interface or how the user will carry out their tasks, sometimes even breaking changes between versions (no backward compatibility). i.e. "Do you want to apply update XYZ?", iOS/Android app store constant updates to apply, Windows Update auto-restarting your system without permission, Adobe/Java plugins and their constant vulnerability patch dances, and any other drastically different front-end changes users have to deal with in their software/tools.
That's not what Continous Delivery is. What you are describing is Continous Deployment of software installed on clients (i.e PC's, smartphones) with each change containing changes to UX. Let's be precise in what we are talking about. If it's Continous Deployment with breaking changes without any notice to customer facing interfaces (be it REST or some GUI) then I agree - it's not good. What's wrong with it in 90% of other cases? And about those Java updates - it's not possible to create software without any bugs/vulnerabilities so there's no way around them.
From my perspective the only difference between CI and CD is that CI will build on set schedule (hourly, daily) or event (WebHook, Poll, etc) and queue the artifacts/distros up for manual deployment whenever the Build Master desires (again a set relese schedule), whereas CD will build on each commit no matter what, and immediately push that change to Production-like Test environment(s) and unless the change is flagged for problems via Manual or Automated Testing, then the change gets pushed up to Production automatically. Both have changes happening at an extremely rapid click, and introduce more opportunities for errors or user-frustrating changes, unless of course true DevOps CD is followed and the customer is part of feedback loop and personally requested the changes outright. Even then, the constant changes will inevitably delight some and distress others.
Bryan Copeland I think CI and CD are simply mindsets. At my company, CI is the mindset of developers working together to integrate their work and ensure that the newly integrated system (still) works. CD on the other hand is simply the mindset that the (properly) integrated system is then delivered - as early as possible - to end users who can derive the values that they (for not free systems) paid for.
I'd be very curious to see how Jim would handle industrial firmware programming, where by definition the only external interactions your software has is with other machines through industrial protocols. Would he say that OO programming just doesn't apply in such an instance? It would also be nice if he gave a few concrete examples to show what the functional difference would be between Object Oriented and Class Oriented design.
I’m gonna watch this again & absorb even the fine points that were being said here. Jim is going a lot of places that grasping where he’s at is a bit of an effort to hold what he’s really saying. But in general, I kind of grapple the trajectory of his thinking. It somewhat resonates with what I intuitively sense in the software dev industry about the idiocy of the many of it’s practitioners, the misunderstandings, the focusing on technology over people, the maintaining of the aura of sophistication over real value to human beings & a lot more aberrations that plague the industry. It’s a paradox that the very people who were supposedly to be above average in cleverness are the very ones to succumb to blindness of what they’re really doing & the ones to be easily sidetracked to the real purpose of their profession. In fairness however, this is also true in other fields of human enterprise like politics, science & even education. This happens when all they only have are highly intelligent peoples but lack wisdom.
No, they are not. Objects are. Regardless if you have classes in the language or not. To nitpick: classes are only text in a programming language. You can only "interact" with them by opening a text editor and changing that text.
It would have been nice if you would have given information to back up your propositions. Remembering that not everyone has your proported expertise. Java can not create objects? What?
Just came across this video and your comment. He says you cannot *write* objects in Java. You can of course create objects, but first you must *write* a class.
In Java you program with classes. Not with objects. read *program*. In true OO environments like Smalltak you are in an IDE and simply can say "w = new JWindow()" (I use Java speak). And inside the IDE a new empty JWindow pops up. Now you can add properties and methods to the variable a ... the object. And more important: when you quit the IDE an restart it, that variable a is back, the window is on the screen etc. When you are finished programming you have a soup of objects, partly visible partly not. Then you "strip" the IDE from that running environment and what is left is the running soup of objects (and classes). Other languages like SELF are more explicit as they simply only have objects, they don't have classes. Same for JavaScript, but javaScript is hiding that a bit.
@@Jiyukan Just watched the video and I am not past the first half yet. But I don't get the point of any of his arguments. He just says things like you can not implement objects. So what. Surely different tools offer different ways to solve things but in the end, the problems can be solved and just because the inventor of oop hat objects in mind and not classes does not mean that instantiating classes is bad. I mean so what if I can't add attributes to instantiations of classes. Where is the problem? Maybe we should not have classes or even objects in the first place. (Besides, you can add a map to the class and add as many things at runtime as you wish) Also when he says: "What part of the controller handles input events: It is not a controller it is a tool." What does that even mean? Is he mad about people implementing InputControllers and would he rather see InputTools? I read comments that this video helped some people but I am watching and don't know what I should change now. In fact, I see other videos which argue that we should not implement the domain model since that does not match with how computers work internally leading to slow software and hard to see through abstractions which become hard to maintain. Maybe I should have become a baker.
I agree with what he spoke about in that presentation. Software is a craftmanship and people, and managers are trying so hard to control and measure it. I think it's hard to control because it is mostly and art. The art of writting software that can always scale. However he rants a lot, and the video doesn't have a lot of views. So, maybe I am wrong by agreeing with him?
This is a bit late of a reply, and I imagine you have moved on since then, however I think that one of the underlying points of his talk which is very important to grasp is that he wants you to think for yourself. And no one else can do that except you. As you very well know, the catch that comes with thinking for yourself is that sometimes you will have to think differently from others, and to do that you need the courage to stand up against other's opinions, no matter how appealing it might be to follow the crowd (or mob). I think it is noteworthy as well to mention that very many of the highly esteemed minds of the past are people who were not very much recognized or appreciated in their own times (think of Socrates, Galileo, Nikolai Tesla and Van Gogh just to name a few).
@@jamescoplien5257 hi Jim. Great talk especially on the parts concerning the people. You did offer some suggestions but for the most part you were criticising the status quo. You managed to shake my faith, my belief quite a bit. You were right. I have no proof that any of it works. So what should I do now?
@@alimahdi6379 I don't tell people what to do because, in some sense, it doesn't work ;-) If I've shaken your faith, I've done my job. And I'm not sure how you would know you were done doing what you need to do next: i.e., what is your objective? If your objective is to do great things, seize every opportunity you can to explore ideas in depth. This usually means going back to the source. I think it started for me when I was learning C++ and supporting Stroustrup as he developed it, and must have exchanged Email with him almost every day for a year or two. When I wanted to learn MVC I went to Reenskaug; to learn Scrum, to Sutherland; and so forth. The original fonts are often inaccessible but most folks certainly can do better than ground their practice in trade rags, talking head talks (like this one :-( ) and Tweets. Come to understand the original underlying theory behind things, and too often you'll find that the spokespersons for this or that haven't themselves taken the time to do so. Some of it is easily verifiable stupid stuff, like Alan Holub today blaming Sutherland for starting the Scrum certification craze (it was Schwaber), and some of it is more subtle, like defining object oriented programming as working with encapsulations of state and data (no, that's ADTs). It will take time. I have been exploring the OO thing since 1982 or so, and it took me about 30 years to fully appreciate what Kay was trying to do. (Even most of the Smalltalk crowd, who tried to convince me all those years that I was wrong, themselves didn't really get it.) And I still leave the door open to being wrong in light of yet more authoritative evidence. To be like this might mean finding a senior mentor, or it may mean delving into the archival literature. There's no recipe. But first and foremost, be skeptical of surprising results, and of claims that are not backed up by proof or peer-reviewed publication in an esteemed journal (by which I might even exclude IEEE publications, though most ACM journals are still O.K.). Think and doubt, rather sign up and believe. Dubito ergo sum.
@@jamescoplien5257 Thank you Jim for taking the time to reply. Getting an A is great but I always wanted the 100. But it has not been that easy. I always felt there was something wrong but could not quite put my finger on it. I always blamed myself. But there ware so many things to do. So many distractions. Don't get me wrong. I think source control is awesome and necessary. But TDD, Agile, ... etc. Just did not help bring the focus to the main issues; satisfying the customer real requirements, delivering good quality on time, and be proud of we have built and were we are. I had just dusted off the Design Patters book by the Gang of Four. I thought I'd read it again, then I saw your lecture. I felt like a soldier who was tired and beaten but had some hope in the gun he had with him, only to find out that it is not as reliable as he thought. If I doubt you then what hope do I have.
@@alimahdi6379 The Design Patterns are interesting. The original C++ Idioms from my 1991 book were one of the four sources for the GoF book. Everyone thinks they are patterns; even from the first formative days of the software pattern discipline, we discounted them as something less. Everyone thinks they're the foundation of OO; no, they're what you do when your programming language doesn't properly express your abstract data types. They're hacks. Richard Gabriel once remarked that he doesn't understand them because he never needs them: CLOS gives him everything he needs out-of-the-box by way of expressiveness. In the final analysis, it is just a matter of maturity. We can use the excuse that we are an immature discipline, and to some degree that's true. But these clarifications are not unknown. They fall victim to educators and practitioners who seek fashion over principled design, and buzzwords over science. Personal computers and agile have laid a foundation for individualistic development apart from a team consensus or industry consensus view (after all, it's "individuals and interactions" - not teams). People forget and even argue against the most rudimentary basics, because their insecurity drives them into self-reinforcement if the energy level required to understand feels too high. I recently found myself arguing with someone in a prestigious forum that hash functions should be dumb and run fast. I mean, you don't even need algebra to figure that out. I sometimes worry that we are an industry of idiots, and I know that history will both laugh at us, and marvel that we could make software that works well enough to drive a car. (Even I have difficulty reconciling these two, and I think it somehow owes to the orders of magnitude of difference in talent between everyday programmers and the few who know what they are doing and who ultimately come into a position to steer the ship.) So it comes down to individuals taking the extra time, making the extra effort, and giving themselves the time (sometimes decades) and space (for error) to learn. When you read the GoF book, were you asking yourself: Why does this pattern work? What are its potential negative consequences? If I implement code that doesn't look like their diagram is it still that pattern? And: do I care? People get hung up on technique: things that can be trained, like we train dogs, and certified. It is the most nematode-style of thinking with which humans are endowed. Focus on the doubt. It sounds like you are already focused on the end-user; that's even more important (not the customer, by the way).
This talk could have been amazing but the speakers inability to resist ranting makes it almost unwatchable. There are some really good quotes that I wish he expanded on and explained but he is completely unfocused and leaps from one rant to another.
I found it pretty on point regarding agile needing to be people focused and I thought many if not all the examples looped back to this premise which BTW, is one of the four values in the manifesto.
36:35 before this, I was thinking, this guy is using a lot of charismatic and rhetorical tricks to make his point. I would call him a cult leader if I wasn't already sipping on his Kool-Aid...
!['A Glimpse of Trygve: From Class-oriented Programming to Real OO' - Jim Coplien [ ACCU 2016 ]](http://i.ytimg.com/vi/lQQ_CahFVzw/mqdefault.jpg)
Beautiful talk! And I loved James’ humorous illustration of the etymology of Scrum. It’s a shame that no one would be willing to make physical contact with one another anymore in this post-COVID world 😢
This was an amazing talk. Absolutely stunning and reinforced many of my personal intuitions of successful development. I tell my teams - the Domain Model must match reality as closely as possible and you will not need to fundamentally change it, everything falls into place when you do.
I am at minute 22 and have no clue what he is talking about.
Great talk. Most developers probably won't get it, but great talk nevertheless. I especially liked the part about sprints failing 50% of the time. It's such an obvious thing, yet I haven't thought about it after many years of working in various Agile teams.
For people who don't get it:
1. Watch some Alan Kay presentations. OOP was about self-managed objects and message passing. Java doesn't have any of that.
2. Unit tests are supposed to be _tools_ to achieve product quality. Instead, developers wave those things around as _proof_ that their products do not suck. If your product doesn't suck, you better have something to measure it by other than your process. At the end of the day no one cares about your process.
3. CD means things change all the time. Users don't like that. Users like stable software.
4. Refactoring is rework. Plain and simple. Good software is simply changed and extended, not refactored.
Amazing talk, and a much better presentation style than the one at GOTO Con 2017. I had some of my answers questions that were raised by the same presentation by the same person just one year later -- I think this one was better as such.
Personally, I am not sold on the idea that "class-based programming" is inherently bad, but I am definitely sold on the idea that mocking at method level with mocks is crazy. And a few other things.
Hmmm. Interesting. I wish I knew why.
31:40 - continous delivery. You said that CD is bad and users hate it without really saying why. What are the downsides from the users/customers point of view?
33:35 - Lufhtansa. What does it have to do with OO? Crappy UX == no OO?
35:59 - Separation. Splitting a system into cohesive, well defined parts doesn't mean that you don't think about how are they supposed to interact. How could it?
37:35 - how does planning remove the need for refactoring? I thought that we should decide on a goal and take a step to bring us closer to it. Then evaluate if the
goal is still vslid and that the direction is ok and continue. But the goal might (and most likely will) change over time so even with planning rework is inevitable.
47:45 - tests. Sooooo... where do we get our automated regression tests from? Aren't they the documentation of things we learned during exploration testing? This in turn is
just a way to figure out how exactly should something work. The purpose is not JUST to make the green bar come up but to make the green bar come up as a result of verification
of our requirements!
Well, I would like to get a list of flights on some route on a specific day (and a few days before/after to compare prices), select the class, see how much it costs and pay for it.
Last time I checked (a few months ago) it was more less how the process looked like on Lufthansa's website.
Maybe I have my thinking already fixed on the provided model but it looks reasonable to me. How would you improve it? And how is it connected with OO?
And I am not old enough ;)
Why CD can be bad...
Believe he implied the side-effect of annoyances due to constant updates and user despair caused by continuous improvements which often spell total changes either to the User Interface or how the user will carry out their tasks, sometimes even breaking changes between versions (no backward compatibility).
i.e. "Do you want to apply update XYZ?", iOS/Android app store constant updates to apply, Windows Update auto-restarting your system without permission, Adobe/Java plugins and their constant vulnerability patch dances, and any other drastically different front-end changes users have to deal with in their software/tools.
That's not what Continous Delivery is. What you are describing is Continous Deployment of software installed on clients (i.e PC's, smartphones) with each change containing changes to UX.
Let's be precise in what we are talking about. If it's Continous Deployment with breaking changes without any notice to customer facing interfaces (be it REST or some GUI) then I agree - it's not good. What's wrong with it in 90% of other cases?
And about those Java updates - it's not possible to create software without any bugs/vulnerabilities so there's no way around them.
From my perspective the only difference between CI and CD is that CI
will build on set schedule (hourly, daily) or event (WebHook, Poll, etc)
and queue the artifacts/distros up for manual deployment whenever the
Build Master desires (again a set relese schedule), whereas CD will
build on each commit no matter what, and immediately push that change to
Production-like Test environment(s) and unless the change is flagged
for problems via Manual or Automated Testing, then the change gets
pushed up to Production automatically.
Both have changes happening at an extremely rapid click, and introduce
more opportunities for errors or user-frustrating changes, unless of
course true DevOps CD is followed and the customer is part of feedback
loop and personally requested the changes outright. Even then, the
constant changes will inevitably delight some and distress others.
Bryan Copeland I think CI and CD are simply mindsets. At my company, CI is the mindset of developers working together to integrate their work and ensure that the newly integrated system (still) works. CD on the other hand is simply the mindset that the (properly) integrated system is then delivered - as early as possible - to end users who can derive the values that they (for not free systems) paid for.
Hi, thanks for sharing. Is the slide deck available on-line somewhere? Thanks
I'd be very curious to see how Jim would handle industrial firmware programming, where by definition the only external interactions your software has is with other machines through industrial protocols. Would he say that OO programming just doesn't apply in such an instance?
It would also be nice if he gave a few concrete examples to show what the functional difference would be between Object Oriented and Class Oriented design.
Been there, done that.
@@jamescoplien5257 Appreciate the reply, but that doesn't really help resolve any of the questions I had :)
@@gordonfreemanq You're welcome to Email your questions to me.
I’m gonna watch this again & absorb even the fine points that were being said here. Jim is going a lot of places that grasping where he’s at is a bit of an effort to hold what he’s really saying. But in general, I kind of grapple the trajectory of his thinking. It somewhat resonates with what I intuitively sense in the software dev industry about the idiocy of the many of it’s practitioners, the misunderstandings, the focusing on technology over people, the maintaining of the aura of sophistication over real value to human beings & a lot more aberrations that plague the industry. It’s a paradox that the very people who were supposedly to be above average in cleverness are the very ones to succumb to blindness of what they’re really doing & the ones to be easily sidetracked to the real purpose of their profession. In fairness however, this is also true in other fields of human enterprise like politics, science & even education. This happens when all they only have are highly intelligent peoples but lack wisdom.
Yeah, I think I need to watch this two or three times more to grasp a little bit more of what Jim is saying.
i think clacess are the interface that individuals uses to interact with their computers
No, they are not. Objects are. Regardless if you have classes in the language or not. To nitpick: classes are only text in a programming language. You can only "interact" with them by opening a text editor and changing that text.
It would have been nice if you would have given information to back up your propositions. Remembering that not everyone has your proported expertise.
Java can not create objects? What?
He said you cannot do OOP in Java. He didn't say you can't create objects :)
Just came across this video and your comment. He says you cannot *write* objects in Java. You can of course create objects, but first you must *write* a class.
In Java you program with classes. Not with objects. read *program*. In true OO environments like Smalltak you are in an IDE and simply can say "w = new JWindow()" (I use Java speak). And inside the IDE a new empty JWindow pops up. Now you can add properties and methods to the variable a ... the object. And more important: when you quit the IDE an restart it, that variable a is back, the window is on the screen etc. When you are finished programming you have a soup of objects, partly visible partly not. Then you "strip" the IDE from that running environment and what is left is the running soup of objects (and classes).
Other languages like SELF are more explicit as they simply only have objects, they don't have classes. Same for JavaScript, but javaScript is hiding that a bit.
@@Jiyukan Just watched the video and I am not past the first half yet. But I don't get the point of any of his arguments. He just says things like you can not implement objects. So what. Surely different tools offer different ways to solve things but in the end, the problems can be solved and just because the inventor of oop hat objects in mind and not classes does not mean that instantiating classes is bad. I mean so what if I can't add attributes to instantiations of classes. Where is the problem? Maybe we should not have classes or even objects in the first place. (Besides, you can add a map to the class and add as many things at runtime as you wish)
Also when he says: "What part of the controller handles input events: It is not a controller it is a tool." What does that even mean? Is he mad about people implementing InputControllers and would he rather see InputTools?
I read comments that this video helped some people but I am watching and don't know what I should change now. In fact, I see other videos which argue that we should not implement the domain model since that does not match with how computers work internally leading to slow software and hard to see through abstractions which become hard to maintain.
Maybe I should have become a baker.
I agree with what he spoke about in that presentation. Software is a craftmanship and people, and managers are trying so hard to control and measure it. I think it's hard to control because it is mostly and art. The art of writting software that can always scale. However he rants a lot, and the video doesn't have a lot of views. So, maybe I am wrong by agreeing with him?
This is a bit late of a reply, and I imagine you have moved on since then, however I think that one of the underlying points of his talk which is very important to grasp is that he wants you to think for yourself. And no one else can do that except you.
As you very well know, the catch that comes with thinking for yourself is that sometimes you will have to think differently from others, and to do that you need the courage to stand up against other's opinions, no matter how appealing it might be to follow the crowd (or mob). I think it is noteworthy as well to mention that very many of the highly esteemed minds of the past are people who were not very much recognized or appreciated in their own times (think of Socrates, Galileo, Nikolai Tesla and Van Gogh just to name a few).
Is Jim starting to slowly take on a Germanic / Danish accent?
Ok but everything is wrong, so, what is right?
I think I gave several examples of how to do things right. It's just that people don't.
Please watch it again.
@@jamescoplien5257 hi Jim. Great talk especially on the parts concerning the people. You did offer some suggestions but for the most part you were criticising the status quo. You managed to shake my faith, my belief quite a bit. You were right. I have no proof that any of it works. So what should I do now?
@@alimahdi6379 I don't tell people what to do because, in some sense, it doesn't work ;-) If I've shaken your faith, I've done my job. And I'm not sure how you would know you were done doing what you need to do next: i.e., what is your objective?
If your objective is to do great things, seize every opportunity you can to explore ideas in depth. This usually means going back to the source. I think it started for me when I was learning C++ and supporting Stroustrup as he developed it, and must have exchanged Email with him almost every day for a year or two. When I wanted to learn MVC I went to Reenskaug; to learn Scrum, to Sutherland; and so forth.
The original fonts are often inaccessible but most folks certainly can do better than ground their practice in trade rags, talking head talks (like this one :-( ) and Tweets. Come to understand the original underlying theory behind things, and too often you'll find that the spokespersons for this or that haven't themselves taken the time to do so. Some of it is easily verifiable stupid stuff, like Alan Holub today blaming Sutherland for starting the Scrum certification craze (it was Schwaber), and some of it is more subtle, like defining object oriented programming as working with encapsulations of state and data (no, that's ADTs).
It will take time. I have been exploring the OO thing since 1982 or so, and it took me about 30 years to fully appreciate what Kay was trying to do. (Even most of the Smalltalk crowd, who tried to convince me all those years that I was wrong, themselves didn't really get it.) And I still leave the door open to being wrong in light of yet more authoritative evidence. To be like this might mean finding a senior mentor, or it may mean delving into the archival literature. There's no recipe. But first and foremost, be skeptical of surprising results, and of claims that are not backed up by proof or peer-reviewed publication in an esteemed journal (by which I might even exclude IEEE publications, though most ACM journals are still O.K.). Think and doubt, rather sign up and believe. Dubito ergo sum.
@@jamescoplien5257 Thank you Jim for taking the time to reply. Getting an A is great but I always wanted the 100. But it has not been that easy. I always felt there was something wrong but could not quite put my finger on it. I always blamed myself. But there ware so many things to do. So many distractions. Don't get me wrong. I think source control is awesome and necessary. But TDD, Agile, ... etc. Just did not help bring the focus to the main issues; satisfying the customer real requirements, delivering good quality on time, and be proud of we have built and were we are.
I had just dusted off the Design Patters book by the Gang of Four. I thought I'd read it again, then I saw your lecture. I felt like a soldier who was tired and beaten but had some hope in the gun he had with him, only to find out that it is not as reliable as he thought. If I doubt you then what hope do I have.
@@alimahdi6379 The Design Patterns are interesting. The original C++ Idioms from my 1991 book were one of the four sources for the GoF book. Everyone thinks they are patterns; even from the first formative days of the software pattern discipline, we discounted them as something less. Everyone thinks they're the foundation of OO; no, they're what you do when your programming language doesn't properly express your abstract data types. They're hacks. Richard Gabriel once remarked that he doesn't understand them because he never needs them: CLOS gives him everything he needs out-of-the-box by way of expressiveness.
In the final analysis, it is just a matter of maturity. We can use the excuse that we are an immature discipline, and to some degree that's true. But these clarifications are not unknown. They fall victim to educators and practitioners who seek fashion over principled design, and buzzwords over science. Personal computers and agile have laid a foundation for individualistic development apart from a team consensus or industry consensus view (after all, it's "individuals and interactions" - not teams). People forget and even argue against the most rudimentary basics, because their insecurity drives them into self-reinforcement if the energy level required to understand feels too high. I recently found myself arguing with someone in a prestigious forum that hash functions should be dumb and run fast. I mean, you don't even need algebra to figure that out. I sometimes worry that we are an industry of idiots, and I know that history will both laugh at us, and marvel that we could make software that works well enough to drive a car. (Even I have difficulty reconciling these two, and I think it somehow owes to the orders of magnitude of difference in talent between everyday programmers and the few who know what they are doing and who ultimately come into a position to steer the ship.)
So it comes down to individuals taking the extra time, making the extra effort, and giving themselves the time (sometimes decades) and space (for error) to learn. When you read the GoF book, were you asking yourself: Why does this pattern work? What are its potential negative consequences? If I implement code that doesn't look like their diagram is it still that pattern? And: do I care? People get hung up on technique: things that can be trained, like we train dogs, and certified. It is the most nematode-style of thinking with which humans are endowed.
Focus on the doubt. It sounds like you are already focused on the end-user; that's even more important (not the customer, by the way).
Well, you look the same as 12 (now 14) years ago. (Angelo here, the Aikidoka)
Tardis in the basement.
This talk could have been amazing but the speakers inability to resist ranting makes it almost unwatchable. There are some really good quotes that I wish he expanded on and explained but he is completely unfocused and leaps from one rant to another.
I found it pretty on point regarding agile needing to be people focused and I thought many if not all the examples looped back to this premise which BTW, is one of the four values in the manifesto.
What if your mob is only three people?
36:35 before this, I was thinking, this guy is using a lot of charismatic and rhetorical tricks to make his point.
I would call him a cult leader if I wasn't already sipping on his Kool-Aid...
Kind of ironic we've had 20+ years to get said data.
Hee hee.
Jim Coupling is against a lot of stuff
And it seems misunderstanding some things; unit testing is not about class testing (although many do it that way).
Cope --- you're from Illinois, aren't you? Other than that - another excellent dissertation. Reality is complicated!
I once lived near Chicago, which is not really Illinois, but I'm not from there.
"Other than that..." ? lol!
I feel really bad every time people say: 'everyone is wrong, we lost our true way'.
why?
Because it's becoming very religious at this point. We haven't lost the true way, we've just evolved.
I know what you mean... but this guy kind of knows what he's talking about. there's exceptions.
Exactly. And this constant suggestions about some hidden agenda (he stole that, they want to make money).
Piotr Kopalko yes, hidden agenda is: make people finally understand what OOP really is.
Cope you can't be serious about mob programming. You were doing so well there ..