The Dehumanisation of Agile and Objects • James Coplien • GOTO 2017

[@EricRohlfs]

This talk caught me off guard. Information dense, authoritative, unique point of view derived from experiences my generation missed. We were given tools and told to use them, very little on why.

[@mindmantra-digital]

Exactly the words (okay, not so polite like yours), that came to my mind. Took three turns and still left almost a quarter near the end.

[@joanvallve7647]

No way to describe it with better words, man.

[@ChrisAthanas]

This is the definition of cargo cult practices It’s important to truly understand WHY we do these things, not that it’s “best practice” This age is inundated with the logical fallacy of “Appeal to Authority” I hope we recover soon from this folly

[@ericpmoss]

Gawd I hate Agile and all the rest. We keep hearing that "oh, it is great if you practice the REAL agile", but that's indistinguishable from any other religion. It's all just a social construct that cannot replace deep knowledge of the problem space. Coplien pointed that out well in this same conference. In every place I have ever worked, the best people were driven away by the mentality of servicing the paradigm, and the cute games, and tools that enforced the rituals. Bleah.

[@swapode]

"Deep knowledge of the problem space" is exactly the problem. And particularly how the lack of understanding of the core problem relates to abstraction. The vast majority of programmers seem to start with a vague understanding of the problem and creating (or borrowing via frameworks and such) an abstract model of things they think might be required at some point and try to shoehorn the problem into that abstraction after the fact. That's an insane approach. Not only because you spend your time not actually solving the problem but because it leads to this cargo-cult idea where serving the "elegance" of the abstractions is more important than getting things done. I'd much rather refactor someone's one file spaghetti solution than trying to wrap my head around some mess of classes, interfaces, managers, factories, adapters and so on that objectively have nothing to do with solving the problem. At least the spaghetti code being written by someone with no clue about structure, algorithm and such also means it's been written by someone without assumptions about grand concepts. I don't think that's necessary at odds with agile, I wouldn't even surprised if the ur-agiles would agree with me, but agile doesn't really deliver tools to get the abstraction mindset out of people's heads - instead it manifests itself as another religion (complete with priests and kardinals who get their sermons paid in gold) that lets people repeat the same mistakes over and over again with even more tam-tam.

[@puk3rz]

"That wasn't REAL communism"

[@errrzarrr]

It wasn't REAL communism... I mean.... _It WaSsn't ReAL aGiLe!_

[@MarkT]

Hairy shouty person warning... but you know you need it!

[@dafl00]

The longer I work in a Java-centric, Spring Based, software shop, the more I agree with Coplien

[@nonya69]

What about your experience brought you to this conclusion?

[@abeplus7352]

I mean oop isn't bad it's just the way Java does it makes me want to throw up .

[@BryonLape]

@@abeplus7352 Java is an old idea that needs to be forgotten.

[@tomwilliam7299]

@@abeplus7352 Java is not OOP at all, Most programmers understand OOP totally wrong, JS and C++ are OOP

[@uselesssacrafice9211]

@@tomwilliam7299 So what the OOP is in your terms? Because I am struggling to understand this man: he dropped all the stuff into one pile and repeats saying everyone is wrong. Maybe I should look for his books, though.

[@panicraptor2837]

Scrum is from 1986. Hirotaka Takeuchi and Ikujiro Nonaka introduced the term scrum in the context of product development in their 1986 Harvard Business Review article, "New New Product Development Game".[5] Takeuchi and Nonaka later argued in The Knowledge Creating Company[10] that it is a form of "organizational knowledge creation, [...] especially good at bringing about innovation continuously, incrementally and spirally". The authors described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, photocopier and printer industries.[5]

[@BryonLape]

TPS reports are real?

[@JeremyAndersonBoise]

I actually like how upset he gets, even when I disagree with his use of absolutes. Not “all” talks are recipes. Admittedly, a lot of consumers of conference talks seem think they are, or should be. Coplien is a serious academic, y’all best take heed.

[@mortenbork6249]

The deferred word was added, because they realized that you don't want to pick a persistence layer, before you know what you need to persist. That you don't choose a framework, until you know that the framework integration will improve efficiency of the team, rather than slow it down. (or simply adds new syntax, that hides the fact the team, simply didn't know how to solve a task efficiently natively) I agree that agile doesn't mean fast, but deferring choice is a core concept. You do not want to pick something before you know you need it. If I pick a framework based on an assumption, I cannot undo that choice easily once the integration is made. And it may will turn out, once working code has been constructed, that I find, an assumption was invalid, and I didn't need to persist something, or could persist it differently a better way, or there was a smaller framework available, or a bigger one, where an early choice, made the whole thing a giant mess to untangle. That is what is meant, as far as I understood it, as "Defer" decisions until you KNOW you need them. And you don't know you need anything, until you have PoC anyway.... Or did I completely misunderstand something here?

[@bigstones84]

I have your same question. Maybe he's referring to things where "fail fast" is a better approach, eg the details of some feature. But I'm still wondering if that's just his interpretation...

[@ChrisAthanas]

It’s important to know the history of LEAN and the Japanese In one of his talks he says that the Japanese embedded some misinformation and in the process One being “last possible moment of choice” In reality, you want to bring those decisions forward and anticipate them as much as possible, but always with an eye to change if it’s a mistaken, and to build the system with this in mind (ie: decoupled) James knows Japanese and he read the original quote in Japanese in the creators autobiography He head faked the Americans!

[@jonchicoine]

important information but hard to listen to... sorry, but he is not a good communicator

[@ralfrolfen5504]

22:36 And then I look at most websites and applications (someone said "git"?) ...

[@snaecooceans8744]

43:28 - *The Interface IS the Product*

[@marna_li]

Programmers are tackling problems from the wrong perspective - the purely technical - without understanding the actual need and domain. Starting with classes and having to figure out how to translate details of a specification into code. For the most part, I try to figure out the objects, their behaviors, and how they intreact with each other, before I even start coding. It is high-level.

[@BryonLape]

I heard Dijkstra is writing a new paper: GOTO Conference considered Harmful.

[@tomwilliam7299]

😁😁😁😁😁😁

[@Zhuinden]

So I watched this talk, and watched this exact same talk again presented 1 year before at Entwicklertag 2016 (kzbin.info/www/bejne/eoDcf5mjptyFb5o), and I advise watching *that* instead, it is much cleaner and much more straight to the point - unfortunately some of the information really is lost across the "rantiness", potentially because there there had been a "great talk" shout-out, but in this one this talk intends to also have the mission of trying to invalidate all previous talks.

[@happyuk06]

Why does TDD necessarily force you to adopt a bottom-up design?

[@dubiouslycrisp]

If you apply TDD at the high level of the design before the lower level details, then the tests consist of checking whether the right stubs were called, and in the right order. That's not so satisfying. Thus, when people set out to make tests, they gravitate toward tests that run code that produces a result, like calculating whether a given year is a leap year. For known inputs, you can determine what the correct outputs should be. A person could do TDD in a top-down way, but in practice people don't go that route. That's my take on it.

[@ChrisAthanas]

It concentrates on the details (methods) which is not the most important unit and will often change. TDD ignores the large picture which is where a lot of software problems exist due to mismatch of mental model and machine model

[@tr233]

As c++ better then java, diamond inheritance problem, memory leakage. TDD is not a technique to know what your code doing, it is a technique to make sure that side effects wont appear if you write code on large projects and that at any point you can refactor it to the requirement of the client.

[@ottorask7676]

TDD is about designing how your code behaves. A refactoring safety net is a nice side effect though.

[@mortenbork6249]

@@ottorask7676 When you write unit tests, you also tell the next programmer, what you "meant" to do. by your tests. If you assert that boundaries between interfaces are tested in those specific ways, then you tell the next guy that reads your code, that you meant it to work like this. At least within those boundaries specified by the tests. You are in fact communicating about which constraints are indirectly applied to your implementations. This can be very important to the next guy, or yourself, when trying to remember WHY something was done a specific way.

[@ChrisAthanas]

TDD is advertised as a design method and its an antiquated anti pattern meant for a different era

[@JohnDarrington88]

Regardless of good points made - the way he makes them, and the disparaging remarks about others in the industry and other speakers makes me never want to interact with this person in real life

[@shadysource9783]

I think many figures in tech are overly coddled. I greatly appreciate someone with strong enough ideas to overcome the pervasive stagnant reverence towards ‘authorities.’ This is the only way the industry can improve.

[@ChrisAthanas]

@@shadysource9783 my very best teachers have always appeared abrasive This was often a front to make a point and if you were one of the few that truly listened, they would usually soften up and spit serious wisdom that is extremely useful and Can save years of effort and heartache Software problems are people problems

[@dijoxx]

You are part of the problem John.

[@sebastianogeyingbo7977]

A bit wrong about TDD here. TDD is useful for documenting how that module works and constrains the system against future incompatible changes/regressions, in addition to ensuring that the feature/model is working as intended.

[@kalekold]

"You're not doing agile right!" - lol, maybe it just doesn't work!

[@errrzarrr]

_It'S YoU, AgiLe wOrKs!_

[@c2ashman]

Don't hate me...but I don't want to have him as a scrum master in my workspace.

[@mvargasmoran]

I guess he wouldn't be a Scrum master. there's no need to have masters and slaves in the current society. Just saying.

[@Luiz__Silva]

@@mvargasmoran Why would you assume the term master refers to slavery, necessarily? I'm the past we called teachers or any wise person from which we can learn from "masters" as in a master-disciple relationship.

[@mvargasmoran]

@@Luiz__Silva I'm sorry man, I was tired about the libtard cringe, I just got told to move my git branch from master to main, because slavery... I really don't give a fuck, Just let me have master and slave, and master record and whatever primeval computer guys named. at this point, is not like I don't care, I'm against progressive types changing crap.

[@dijoxx]

I don't ever again want to work in a place that has "scrum masters".

[@errrzarrr]

So you are a Slave!?😢

[@happyuk06]

The real killer behind TDD is chasing excessively high unit test coverage coverage - more than 80% becomes a fool's errand quite quickly. When done appropriately and judiciously auto and unit tests definitely do the job in the nightly pipeline builds. I've seen this in practice with my own eyes, where tests flag up things that would otherwise go unnoticed. The real issue with unit tests is that many developers find them hard and time-consuming to write.

[@dijoxx]

They are honestly not hard. The hard part is adopting the habit of writing them.

[@happyuk06]

@@dijoxx Agreed. Also when they are "hard" and require a lot of mocking up it's often a sign the code is not SOLID-principled.

[@psyaviah]

His slide "Where Agile Has Gone Wrong" should be titled "How Agile Is Misunderstood/Misused"... Because I agree what he says over there. But, if all you remeber of testing software is testing your methods, then my god you are wrong as well... He doesn't seem to grasp how tests help developers and create time for "invidiuals and interactions" and where a person testing the software can focus on diving into the mental model of an end user; not just reporting the same errors over & over again. Hardcore TDD sure, if you take it like that. But let's be honest, he's shouting it's all bad and forgets that testing software as it should be done, in a UNIT (a set of objects working together) or as an INTEGRATION where multiple moving parts and external dependencies (such as filesystem or db) are integrated in the test aren't important. (Yes in the "questions" he refers to that, but not having it in his core talk is an oversight). To use his own words "a lot of it is ignorance", sure, as he's doing as well: wiping it all from the table, a bit simplistic and radical in my view.

[@NedHasovic]

Had to be said. Thank you!

[@torenoleary8489]

30:15 To counter, the agile manifesto #3 point: 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. "preference to the shorter timescale" is implying to delivery software faster. A bit of nuance, but I agree overall with his messaging.

[@pm71241]

Hmm... I felt like hearing my teachers in humanity classes from high school try making sense of something from natural sciences. To add to that ... if this was the pitch I had been given about software development before picking a college education, I'd become a baker or a chef instead. So... we all need a psychologist sitting on our lap - along with 2 project managers and a patent lawyer. If I understood the last few minutes right that it favors a "post modern" approach over a "modern" ... then it explains a lot about why I get an urge to run away screaming. I do agree, though, that the certification circus is a waste of time.

[@ChrisAthanas]

What do you suggest? Are you saying ignore psychology and people and just write code for the machine? What about the other developers? Do they matter?

[@SM-ok3sz]

I loved this guy in Happy Gilmore

[@twistedbydsign99]

got nothing from this

[@sambell624]

I am more convinced than ever that Agile is KM on wheels....You can't have Agile without KM Knowledge Management 8:19

[@anthonycyrille]

Like many "strongly opinioniated developers", he's terribly good at convincing us of what's wrong and awful at explaining what's right.

[@BuffNerdInCa]

Who gave the crazy dude amicrophone? What a nonsense disorganized rant. I think he knows his stuff, just fails miserably to present it in a coherent manner.

[@BB1CC666]

This talk sounds like 2007...not 2017....

[@thygrrr]

15:00, speaker goes off the rails and I would say he takes the entire talk off the deep end. What?! (yes, classes are not objects, but... what?!? none of this tangent makes any sense) Best takeaway was CRC Cards, that's an old tool that beats UML or more detailed modeling for me, because it's much higher level. I'll use it for my architectures in the future. It's worth the try :) Talk becomes pracrically unbearable after 35:30

[@FritzFeuerbacher]

Most people don't, and never will know how to model objects properly. That's why Java is the perfect middle ground between a true object oriented language, and a great general purpose object oriented language.

[@pohjoisenvanhus]

Loved the content but the presentation was a bit too strong.

[@mileskafka9450]

Curious if you were watching it at normal speed? I had it cranked up to 1.5x and that did make it feel like getting yelled at :) But taking it at regular speed seemed more earnest than angry (to me at least).

[@zofe]

1. What about Requirements-Management instead of Mob-programming? RM is the right estuary to all mob members (the sea being the products realizing these requirements). 2. What about acknowledging high-IQ is the queen of battle, e.g. of development?

[@ChrisAthanas]

The ai Revolution will cede ground from the autist priest class and hand it to the ones more aligned with customer needs and expectations and mental models

[@errrzarrr]

I agree

[@heyheyhophop]

Coplien on cohesion :V

[@Zhuinden]

Hmm, 20:07 interests me

[@Zhuinden]

kzbin.info/www/bejne/kKOlgqB_ecmfqZY yay for regression tests

[@damaddinm88]

You are my new hero 😊

[@damaddinm88]

lex Tr3 have a bag on your side 🙂

[@simont936]

As a software engineer and chartered engineer of many years standing, I cannot make out whether this is just a personal rant or a hatred of the previous speaker (since there are many bits of spite aimed at him personally). I am not sure if this is an attempt at rabble rousing, because certainly it adds nothing to the debate except noise. Testing is not about exploring designs, I hate agile "sprints" but a 50% success rate is not at all to do with mathematics: that would require a curve and some data. It is interesting - or rather not - that the speaker keeps saying "it's in the research" without ever quoting any qualitative or quantitative figures from the research.

[@sebastianogeyingbo7977]

People over processes is wrong approach because people will leave and structure/processes will remain.

[@VideoPir]

Pass. This guy is a whining baby, yelling at the crowd. Watch something else.

[@mvargasmoran]

At 47:52 we should kick in Boku no hero's academia You Say Run.

[@RonaldTetsuoMiura]

13:36 sexist language? oh god....

[@shipper66]

ROBOTS ... DON'T ... LEARN !!

[@tomwilliam7299]

yes baby 🤗🤗🤗

[@henrikvendelbo1117]

Too bad 99% of the industry has incentives to not understand

[@aivascu]

Does anyone else notice how major people in the industry have their minds slip, over time? Advising against testing and automation!? Pure heresy!

[@Zhuinden]

kzbin.info/www/bejne/kKOlgqB_ecmfqZY

[@mururoa7024]

Hahaha this guy is pretty radical. As brilliant as he is, he probably forgot there are other models of thinking than just algorithms.

[@alrightsquinky7798]

Nothing that Alan Kay said in that quote about children’s psychology was sexist.

[@bocckoka]

you can't explain away inherent failure.

[@billziss9824]

Much goodness here. However, "The UI is the product"

[@Fetrovsky]

"sexist language" ... ugh.

[@alrightsquinky7798]

My goodness. If the interface is the product, then how come the user complains if you remove the database from the system? The interface is absolutely NOT the product. It’s just that: an interface for the user to interact with the services provided by your system. In some minimalist cases I’ve worked on interfaces that were simply buttons for the user to press in order to generate reports, and these could just as well have been development scripts run from the command line, which would have no GUI whatsoever but produce the same result. This “The GUI is the product” nonsense is possibly the worst analysis of software development that I’ve ever heard.

[@SM-ok3sz]

Why do geeks do that laugh where they don’t laugh out of their mouths but breath in and out of their nose quickly?

[@errrzarrr]

Who hurt you?

[@SM-ok3sz]

@@errrzarrr Grow some hair

[@a5a5a9]

I am a republican and I approve this

[@hwstar9416]

what a bunch of nonsense