We Tried Baseball and It Didn't Work (2006)
ronjeffries.com
ronjeffries.com
- 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.
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.
Maybe he had also tried TDD "wrong"? Or maybe he's just another snake oil salesman, like "uncle" Bob?
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".
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.
> 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.
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.
Why does Uncle Bob get a larger amount of ire?
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.
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.
The implication of your question though, is that you do not think Uncle Bob is an authority in this sense, merely an influencer?
(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.
... 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 ;-)
Surely people actually read the article?..
Take another look. They're just bikeshedding.
Everyone knows that if the US would just change the name, they'd win the World Cup. That's clearly the most important thing.
But baseball was a poor choice because original baseball is bad.
(It isn’t a methodology, either. It’s a philosophy of development or, if you prefer, a family of methodologies, such as Scrum, XP, and Kanban.)
VIOLET SCRUM
PURPLE KANBAN
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.
[1] http://mlb.mlb.com/mlb/downloads/y2010/official_rules/2010_O...
> 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.
https://todayinhistory.blog/2019/02/10/february-10-1920-the-...
Examples? I'm thinking there must be some.
The Buster Posey rule about sliding into home? (I don't think they call it that.)
The George Brett rule about corked bats? (Ditto)
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.
at least with how "agile" is set up at work (with SCRUM and SAFE (scale agile framework)), yes
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.
For the historical cruft we’re getting there, I’m sure there’s teams mandating to stand during stand-up even during remote sessions.
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.
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 ?
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.
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.
(Yes, yes, I get the allegory.)
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.
'Merica.
- https://www.businessinsider.com/football-vs-soccer-map-2013-...
- https://www.businessinsider.com/why-americans-call-it-soccer...
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 someone who always called it football, the word "soccer" feels like a needless neologism.
I guess your culture says nothing strangely eh?
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.
HTH!
"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...
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.
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.