Entwicklertag 2016: How Agile and OO have lost their way together - James Coplien 

I am at minute 22 and have no clue what he is talking about.

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.

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.

Yeah, I think I need to watch this two or three times more to grasp a little bit more of what Jim is saying.

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.

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.

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.

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.

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).

Tardis in the basement.

And it seems misunderstanding some things; unit testing is not about class testing (although many do it that way).

I once lived near Chicago, which is not really Illinois, but I'm not from there. "Other than that..." ? lol!

Kind of ironic we've had 20+ years to get said data.

Hee hee.

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).

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.