The Dehumanisation of Agile and Objects • James Coplien • GOTO 2017
ฝัง
- เผยแพร่เมื่อ 17 พ.ค. 2024
- This presentation was recorded at GOTO Berlin 2017. #GOTOcon #GOTOber
gotober.com
James Coplien - Lean/Agile Process & Architecture Coach; Founder of the Pasteur Organizational Patterns Project
ABSTRACT
It can easily be argued that agile grew out of the spirit of object orientation: its focus on change, on anthropomorphism, and on people. Alan Kay saw objects as a way for people to connect with their environments through their machines. As late as the 1980s people were still talking about anthropomorphic [...]
TIMECODES
00:00 Intro
02:10 A Family Tree
06:09 The Agile Manifesto
16:29 Genetic Epistemology
19:18 Where have objects gone wrong?
30:14 Where has Agile gone wrong?
32:48 Agile has lost its roots
34:50 and the good parts are little understood
38:47 The Common Enemies
40:22 Restoring Focus
46:23 Elusive lands over the horizon
46:52 Organizational Learning Models
47:30 Failure to Dream
Download slides and read the full abstract here:
gotober.com/2017/sessions/297
RECOMMENDED BOOKS
Subramaniam & Hunt • Practices of an Agile Developer • amzn.to/2XjbWor
Uncle Bob • Clean Agile • amzn.to/3tpAqb5
Derby, Larsen & Schwaber • Agile Retrospectives • amzn.to/3hB4eNk
Kent Beck & Cynthia Andres • Extreme Programming Explained • amzn.to/3muIlCm
Jeff Sutherland • Scrum: The Art of Doing Twice the Work in Half the Time • amzn.to/2X4GQAD
/ gotober
/ gotoconference
gotocon.com
#Agile #AgileManifesto #XP #AgileDevelopment
Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket at gotopia.tech
Sign up for updates and specials at gotopia.tech/newsletter
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.
th-cam.com/users/GotoConf... - วิทยาศาสตร์และเทคโนโลยี
![[TH] 2024 PMSL SEA W2D2 | Summer | โหดจัด ซัดไม่เลี้ยง](http://i.ytimg.com/vi/TJa9d7tpSP4/mqdefault.jpg)
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.
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.
No way to describe it with better words, man.
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
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.
"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.
"That wasn't REAL communism"
It wasn't REAL communism... I mean....
_It WaSsn't ReAL aGiLe!_
Had to be said. Thank you!
The longer I work in a Java-centric, Spring Based, software shop, the more I agree with Coplien
What about your experience brought you to this conclusion?
I mean oop isn't bad it's just the way Java does it makes me want to throw up .
@@abeplus7352 Java is an old idea that needs to be forgotten.
@@abeplus7352 Java is not OOP at all, Most programmers understand OOP totally wrong, JS and C++ are OOP
@@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.
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]
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?
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...
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!
43:28 - *The Interface IS the Product*
TPS reports are real?
Hairy shouty person warning... but you know you need it!
I loved this guy in Happy Gilmore
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.
So I watched this talk, and watched this exact same talk again presented 1 year before at Entwicklertag 2016 (th-cam.com/video/DOyNfmqwR98/w-d-xo.html), 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.
Why does TDD necessarily force you to adopt a bottom-up design?
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.
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
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.
They are honestly not hard. The hard part is adopting the habit of writing them.
@@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.
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.
You are my new hero 😊
lex Tr3 have a bag on your side 🙂
"You're not doing agile right!" - lol, maybe it just doesn't work!
_It'S YoU, AgiLe wOrKs!_
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.
22:36 And then I look at most websites and applications (someone said "git"?) ...
important information but hard to listen to... sorry, but he is not a good communicator
Don't hate me...but I don't want to have him as a scrum master in my workspace.
I guess he wouldn't be a Scrum master.
there's no need to have masters and slaves in the current society.
Just saying.
@@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.
@@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.
I don't ever again want to work in a place that has "scrum masters".
So you are a Slave!?😢
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.
TDD is about designing how your code behaves. A refactoring safety net is a nice side effect though.
@@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.
TDD is advertised as a design method and its an antiquated anti pattern meant for a different era
I heard Dijkstra is writing a new paper: GOTO Conference considered Harmful.
😁😁😁😁😁😁
Coplien on cohesion :V
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.
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.
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?
Like many "strongly opinioniated developers", he's terribly good at convincing us of what's wrong and awful at explaining what's right.
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.
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?
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
I agree
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
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.
@@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
You are part of the problem John.
I am more convinced than ever that Agile is KM on wheels....You can't have Agile without KM Knowledge Management 8:19
Hmm, 20:07 interests me
th-cam.com/video/ZrBQmIDdls4/w-d-xo.html yay for regression tests
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.
Loved the content but the presentation was a bit too strong.
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).
This talk sounds like 2007...not 2017....
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.
People over processes is wrong approach because people will leave and structure/processes will remain.
got nothing from this
ROBOTS ... DON'T ... LEARN !!
yes baby 🤗🤗🤗
At 47:52 we should kick in Boku no hero's academia You Say Run.
you can't explain away inherent failure.
Much goodness here. However, "The UI is the product"
Hahaha this guy is pretty radical.
As brilliant as he is, he probably forgot there are other models of thinking than just algorithms.
Does anyone else notice how major people in the industry have their minds slip, over time?
Advising against testing and automation!?
Pure heresy!
th-cam.com/video/ZrBQmIDdls4/w-d-xo.html
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
Too bad 99% of the industry has incentives to not understand
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.
Why do geeks do that laugh where they don’t laugh out of their mouths but breath in and out of their nose quickly?
Who hurt you?
@@errrzarrr Grow some hair
I am a republican and I approve this
Nothing that Alan Kay said in that quote about children’s psychology was sexist.
13:36 sexist language? oh god....
Pass. This guy is a whining baby, yelling at the crowd. Watch something else.
"sexist language" ... ugh.
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.
what a bunch of nonsense