On the other side of the analogy, Mr. Jeffries & co seem to think that:
- Everybody should "play baseball"; playing baseball is the perfect way to "have fun" because "the proponents of baseball" said so.
- If you aren't having fun, then you're not playing baseball correctly; Playing baseball correctly necessarily leads to having fun.
- Softball is just plain wrong; lots of people play softball and seem to have a lot of fun doing it, but they are clearly wrong and not having fun because they don't follow the rules that the "proponents of baseball" dictated 20+ years ago.
- Oh, yes, I sell baseball courses; but this doesn't make me biased at all when criticizing other baseball coaches or even other ways of having fun. It's just that all the other ways are wrong, always.
I don’t know specifically of Mr. Jeffries ideology but his parable hit home for me. My work often runs projects or chooses software in a similar manner to how Baseball was modified. It ends up poorly because there’s a common thread of ignoring the warnings and best practices of the authors of the products or software.
As an example, we moved our apps to the 12 Factor Manifesto style but not really. It was decided that some requirements were silly and new incompatible requirements were added. Now our apps won’t run in a 12 Factor environment and 12 Factor apps won’t run in our own environment. I just spent about a week getting an open source 12 Factor app running in our environment because of those changes.
I don’t believe our changes added any material benefits to the business or how we work, let alone offer an improvement over 12 Factors.
The way we got there wasn’t far off from the story. Lots of criticism about how things were inefficient or won’t scale despite plenty of evidence to the contrary.
I think Uncle Bob also promoted AGILE very hard. But if we mention Uncle Bob, we also should mention GoF (If you have problems with OOP architecture, you aren't doing it right, you aren't abstracting enough, you should abstract the existing abstractions, too).
Which of the four GoF does this apply to. I've never seen any of them make the arguments you are claiming they're making. I certainly don't recall it being made in "The Book".
Honestly no shade on the actual book or authors, but my heart sinks every time I see a dev reading that book, because I _know_ some truly bad ideas are coming down the pipe really soon.
Ironically, none of those ideas the dev then starts pushing are ever "Prefer composition over inheritance" which is literally a section in chapter one.
I reread your breakdown of the FitNesse code example a few times and I felt less and less generous about the analysis each time. Here's two and half questions:
1) If private fields are NOT to be considered implicit arguments to every private method, what exactly are they for? (And if they should not be modified, why would they be anything other than 'final'?)
2) Why do you consider Martin's definition of side-effect, which speaks of 'global state' and 'unexpected changes' to include changes to private members of the class in functions that document those changes via their signature?
You could answer those uncharitably and make Uncle Bob look bad, or you could answer them charitably and then his code makes sense.
I also have to say I don't understand how 'illegible trash' is remotely an appropriate description. This is as good as just about anything I've seen in actual production work in 10 years. It's extremely readable and quite testable. There are nits to pick (and you've done an excellent job of that), but for some part of those at least I feel like they're to be picked with 2008 Java API and coding standards rather than the author.
I can't see that reading this book would be a net negative for 95% of people writing OO code. If you also don't know of a better book either, I'm stumped as to why you'd stop recommending it.
Finally, it looks to me like there's people out to get Uncle Bob cancelled for not being on-board with a certain political invasion of software that's going around at the moment (you can already see a comment calling him 'a terrible human'), so I'm somewhat suspicious of ulterior motives here. If that's not your intent, my apologies.
I did like this article in general and found it to be plenty insightful, so I'd love to read more from you.
Funnily enough, I don't think the quoted comment makes a charitable interpretation of the article.
> Why do you consider Martin's definition of side-effect, which speaks of 'global state' and 'unexpected changes' to include changes to private members of the class in functions that document those changes via their signature?
In Martin's definition, the first example of a side effect is "unexpected changes to the variables of its own class". Perhaps the argument being made here is that the changes aren't unexpected, but in that case, the article is very clear in that it considers them unexpected.
I have also been writing software for a while, and I agree with most of Martin's claims that qntm sites in that article. But I also agree that the example code is utter crap. It violates most of the rules that Martin just gave in the chapter.
Now, having written technical documentation myself, and even "Welcome interns" docs, I understand that writing good examples of good code is quite hard. But on the other hand, if one is writing a book about good programming then take the time to write examples that actually demonstrate what was claimed in the preceding pages! Like, it would be better to have a comment saying "Imports elided for brevity and printing costs" rather than writing wildcard imports.
"Pontificating from a position of authority with nothing to back it up" is what every thought leader does though; it's practically a requirement for amassing "influence" as everyone calls it.
In the Karate Kid, the Karate Expert Mr Miyagi teaches youngster Daniel the martial art of Karate. My Miyagi begins by having Daniel paint his fence and wax his car. Daniel doesn't understand how this helps, and has a tantrum, at which point Mr Miyagi demonstrates that Daniel has, in fact, been building the muscles and reflexes necessary for Karate.
They situation here is simply one where Daniel is not qualified to evaluate Mr Miyagi's methods. Conversely, had Daniel the necessary experience to evaluate the method, he would not have needed instruction.
The internet is full of Daniels, and gives them the ability for their tantrum to reach a large audience. The internet is far more full of Daniels than Miyagis. Further, to tell the difference between a Daniel and a Miyagi, one has to be a Miyagi (see Dunning, Kruger).
Finally, there are legitimate differences in approach between different masters. Sensei John Kreese has very different methods compared to Miyagi, that are, nevertheless, clearly effective. Kreese also has turned his experience into a business and this influences his decisions, such as breaking agreed rules.
Bob might be Miyagi, and he might be Kreese. Most of what he says is good advice, in my opinion. Some of it isn't. Which parts are which depends on who you ask. But most of the complaints come from Daniel.
Agree. I always suspected that Daniels are everywhere with the fact that few people wish to talk seriously about software, instead preferring to talk about fashionable software.
Bob also speaks highly of teaching developers to design software well. This is unpopular right now, we prefer to believe that tools alone are all we need.
Authority and influence are conflated here, especially where you understand authority as expertise (i.e. an authority on a topic). Such an authority should be able to produce credible evidence in support of their claims, else they are possibly not an authority in this sense.
The implication of your question though, is that you do not think Uncle Bob is an authority in this sense, merely an influencer?
We did do all of the things that "real" baseball requires, and guess what – it's just mind-numbingly tedious and boring to play. You tend to spend a lot more time obsessing over what exact equipment and dimensions to use, when your competitors are having fun and getting exercise by just running around the park.
(Since all of the other comments seem to be about sports or writing [1], I should point out that this seems to be an analogy about not doing "real" Agile by one of the authors of the Agile Manifesto.)
----------------------------------------
[1] I hope this was not an intentional pattern that I have broken by being That Bozo Who Said The Forbidden Word.
Cricket has also had these tweaks for a while, and One Day International and Twenty20 are basically new formats of the game, invented because no one wanted to watch two teams play out a match over five days.
There is mindlessly doing "Agile" "by the book" in a time and place where it doesn't fit (ignoring the whole idea about people over process)
... and there is doing something completely different in a time and place where agile would be perfect - and claim that it is "agile".
(And there's thankfully places like the team I work on now where other teamleads come to see how our team lead does it. I suspect part of it might be all the stuff she doesn't do ;-)
I feel like a lot of people are commenting about sport, when the point of the article was an allegory about lazy or badly applied adoption of a practice...
The problem is the analogy doesn't map. You (supposedly) do agile to produce software faster/cheaper/better, but what is baseball making better? Playing baseball is the sole goal. So in that respect it's actually accurate...doing "agile" is the only goal.
Yeah the problem is that they're trying to say "Agile is like baseball - it doesn't work if you make all sorts of misguided improvements to it. You need to stick to the original, then it will be great."
But baseball was a poor choice because original baseball is bad.
I'm bookmarking this conversation as a remarkable example of how certain styles of communication are missed by a lot of people...probably the same phenomenon that obliges you to include "/sarc" lest you be obliged to entertain a long follow-up discussion.
Personally I think capitalizing AGILE buzzwords as if they were cold-war era acronyms or code words is hilarious and I’m going to start doing it myself. SCRUM, KANBAN…
I was gonna say the same thing except for reviews of recipes in comment sections. I made this chili recipe but didn't have tomatoes so I used ketchup and I didn't have beef so I used lobster tail, it was disgusting. 1 star.
Anyhow: "agile" has turned into just the latest way for people who can't code to make a living selling their supposed "expertise."
"If it doesn't work, you aren't doing right"?? No, if it doesn't work, you have a bad project, bad managers, or bad programmers, or all of those. No packaged methodology can fix that.
Baseball has a 136 page rulebook [1] only because (almost) every conceivable situation over its 150 year history has arisen. I don't think that would be an inch thick unless you used very heavy paper.
Nice comparison! There is an impressive amount of considerations in the rule book. Glove dimensions on PDF-page 16 are visually pleasing somehow. And then this rule which I had to look up some more info about:
> 3.02 No player shall intentionally discolor or damage the ball by rubbing it with soil, rosin, paraffin, licorice, sand-paper, emery-paper or other foreign substance.
Huh, licorice? Apparently it was simply used to dirty up the ball so it was nearly impossible to see.
Using baseball as a metaphor for agile just feels wrong and if I were uncharitable I would even call it a self-own. Baseball is a slow-paced, ceremonious game with an inch-thick rule book and a deep layer of historical cruft, does that sound like agile to you?
"Baseball is a slow-paced, ceremonious game with an inch-thick rule book and a deep layer of historical cruft, does that sound like agile to you?"
Sounds like agile methodologies; doesn't sound like agile manifesto. Which is kinda the point. The manifesto is a few salient points and heuristics that devs at the time found effective for delivering working software (and which, I would contend, still hold). The methodologies that have arisen are overly prescriptive, adopted without any eye to the culture, and frequently lead to outcomes no better than what they're intended to replace.
I started programming professionally in 1989, and I delivered a LOT of software for a few different companies before the Agile obsession hit. I had a quite a lot of freedom to modify the process depending on what the project called for. There were fewer corporate overlords worrying about whether I stuck to this or that process. There were certainly no Agile Coaches making sure I followed all the ceremonies of the "Agile Process" (that's a quote) or making sure I used story points instead of calendar time in my estimates.
Making software is a lot less fun these days than in the "bad old days" of the alleged waterfall process.
Yes! I never encountered any of the problems that the so-called "Agile" manifesto and the absurd processes that accreted around it. The current trend just seems amateurish to me, compared to what it strives to replace.
Idk, that. At work, half of time we do real work, half of time we do stupid AGILE ceremonies and POKR because our CEO is accustomed with all the trendy managing methodologies. He likes to change them when he learns about new stuff.
Even if we loose time with lots of stupid things we are required to do the same work as if we had the whole period free. So, the code quality has to suffer and tech debt is accumulating.
I found it rather funny. I see some very uncharitable interpretations here. To me it sounded quite a bit like how people tend to implement microservices. It is a problem our field that people use words so very loosely that it is kind of impossible to know what they are talking about.
It is in this forum commonly made fun of that people who tried something and then get told that they didn't do it right. However, this can be a reasonable objection, depending on the circumstances. There are lots of people all over the world doing things in not-so-very-handy ways and thereby causing problems. If A does not work it might be that A should not be applied in your circumstances, it might be that A was applied wrong or it might be that people are falsely assuming that they have a right to a life without problems. Any of these three could be going on when A is not working. the article is making the point that the second case can go quite far.
Would you like to help me and my buddies learn to play cricket ?
Its quite the same sport, and don’t worry, no one has ever played baseball or cricket in the team, they won’t notice !
And please, go straight to the full group « at scale ». We have to be quick, it seems to be the only way to look like people who have success in this other country, India !
This analogy is wonderful, I may reuse it someday. Thanks for sharing.
However it makes me wonder about tailoring ideas. Of course it is necessary to adjust ideas to context, but how do you know when it is too much ?
I think this is the key part about adopting anything: Make sure you understand the goals behind it, and how those led to the choices it made. Not understanding those is when you start cargo culting.
Of course, it's impossible to know every thought process that went through the original developer's head, but with an understanding of the core goals, you can at least make educated guesses as to what's "load bearing", so to speak.
- People try agile but they don't do it right. Then they fail.
- There are A LOT of consultants and managers pushing Agile (Mostly some Scrum practices) but they have absolutely no idea how software engineering works.
But look at the Agile principles. They are pretty good common sense ideas.
Agile was supposed to take the control of the development process and give it back to the practitioners who understand deeply how to write and deliver software.
My favorite Agile principle: "Continuous attention to technical excellence and good design enhances agility." But that is pretty hard (See https://norvig.com/21-days.html) so people focus on planning poker and having stand ups.
The Agile principles are completely opposite to getting a consultant (or in-house expert) to design you a process. You can do Agile or get a designed process, not both. Thus if a consultant works on designing Agile processes, he must not have any idea what he is doing, your second point is necessarily true, on every instance.
Also, "trying agile" has a strong connotation of trying a canned process, what is necessarily means you don't get to follow the Agile principles.
Why it is that all scrum peddlers always reason by shitty analogies?
Do they really think this a sensible way of reasoning or they are fully aware this is BS but they don’t care as long as they sell training and consultancy packages?
The park variant doesn't really care about team sizes and it scales nicely from 3 people per side up to ridiculous number of people per side.
Plus it's a sport that combines well with alcoholic lubricants and Summer days.
I know it's older (1500s!) so doesn't seem to be as modern as something like Baseball, but it's OSS (everyone in the park applies their own rules) and scales nicely.
That reminds me of the comments on my favourite cooking website: "We replaced ingredient X by Y and prepared Z differently. Bad recipe, cannot recommend."
My friends and I grew up playing stickball, making up the rules as we went along. We had a blast, learned how to have a good game anywhere we were with improvised equipment, and we made a lot of good memories.
Because the term "football" can have different meanings depending on where you are, but the term "soccer" is unambiguous and known to everybody*, it would make sense to exclusively use the term "soccer" when writing for an international audience, no?
It's ironic that in a dispute over correct writing, you've split your infinitive. "Properly to play" or "to play properly" are correct English grammar.
Just because a couple hundred years ago, the British had a Latin fetish and tried to shoehorn in new rules doesn't mean anyone should ever follow them.
Yeah, this is an odd quirk of some British grammars that wanted to imitate Latin. It's not an actual rule, and those grammars have been retired long ago.
Don't worry, some stuffed shirts made up the rule wholesale in the 1830s and a particular kind of pedant has been pushing it ever since. It's never been true.
Ask a football fan which countries they think of? Brazil, the Netherlands, Italy, Spain, etc... Not the U.S., Canada, and ... Southeast Asia? The same is inversely true for hockey.
Countries that are new to football calling it "soccer" are like countries new to hockey calling it "ice-golf": there are other ways to be unique and draw attention.
To be fair, outside of US almost everyone calls this sport American Football, whereas the local translation of football in most countries simply refers to "soccer" ;)
> Also why is it only ok to shit on the way Americans say things but not anyone else?
Because A), in 99% of cases it is only the US that does shit weirdly, and above all, B) because in 99% of those cases, Americans are so fucking ultra-annoying in assuming their parochial way is The Gold Standard.
This is tangential but I love baseball and it’s fun and hilarious to bring someone to a game that doesn’t know the rules (I mean not know the rules at all, from a country without baseball). Three strikes, 4 balls, three outs. Ok that’s simple, and a foul is also a strike. But that guy’s not out? No, it doesn’t count on the third strike. Catching the ball is an out. No that wasn’t an out because it was just a foul tip. Not catching the ball isn’t an out obviously. Well it was in this case because of the infield fly rule. Oh wait it wasn’t because you can’t call infield fly rule when there’s two outs. Ok the batter got hit by a pitch but he deserved it because two innings ago he hit a home run when his team was winning by 6 runs. It’s an unwritten rule you see… The big beards are for luck. No not on that team though, they’re not allowed to have facial hair…
Don't know if it's just me, but I find the analogy to agile methods to break immediately. I've always thought that the goal of agile is not to have more fun but to produce working software faster and better. Agile of course can also be fun for some people, but for others care-free coding of tickets in a waterfall plan is much more fun than constantly facing the uncertainty of customer expectations.
Looks like writing of someone who does not "get" the game. It is a bit like people who are asking why offside is needed in soccer. If you play with your friends on a beach, surely, does not make much sense, but in a real game on a large pitch it makes hell a lot of sense.
"Golf balls went too far and were hard to catch" - I hope nobody else will go that way unless one tries to win Darwin Award...
Great article. It nails the “We tried X without actually trying X and it didn’t work” problem that happens all the time in software development. I have so many times been told that “X doesn’t work” after which I demonstrate X working just fine. They always get very quiet when I do that.
Given the time period: 2006, this was about OOP development and/or XML. I'm talking about hardcore consultant stuff: UML diagrams and gantt charts.
Agile was in its infancy in 2006. No one would be making a joke like this about Agile at that time.
---------
Alternatively, maybe the author was familiar with OOP / UML / Agile and decided that making this blogpost applicable to all 3 with an allegory was good? But I'd expect that most readers were thinking UML diagrams instead of standup meetings.
I will be quite happy when this particular generation of old white boomer men that push Agile constantly finally fade into the sunset.
It's a religion with them, and despite almost universally never having written any software of any note that ever went into production, they pontificate and bleat about best practices, and become hostile and defensive if you register any objections to their doctrine.
I will be quite happy when unprovoked complaining about white men in contexts where race and gender have nothing to do with anything finally fades into the sunset.
- Everybody should "play baseball"; playing baseball is the perfect way to "have fun" because "the proponents of baseball" said so.
- If you aren't having fun, then you're not playing baseball correctly; Playing baseball correctly necessarily leads to having fun.
- Softball is just plain wrong; lots of people play softball and seem to have a lot of fun doing it, but they are clearly wrong and not having fun because they don't follow the rules that the "proponents of baseball" dictated 20+ years ago.
- Oh, yes, I sell baseball courses; but this doesn't make me biased at all when criticizing other baseball coaches or even other ways of having fun. It's just that all the other ways are wrong, always.