[HN Gopher] Book Review: "Tidy First?" By Kent Beck
___________________________________________________________________
Book Review: "Tidy First?" By Kent Beck
Author : todsacerdoti
Score : 43 points
Date : 2024-04-01 18:42 UTC (4 hours ago)
(HTM) web link (www.pathsensitive.com)
(TXT) w3m dump (www.pathsensitive.com)
| Jtsummers wrote:
| > If you'd like more detailed criticism of the book, you can buy
| my raw unfiltered chapter-by-chapter notes. This will only be
| available until April 8th, and then I'll take it down forever.
| Click here to purchase.
|
| (Link goes to: https://mirdin.com/downloads/notes-on-tidy-first/)
|
| Follow the link and you can buy the detailed criticism of the
| book for $25. Which is more than the cost of the book new on
| Amazon ($20, or $24.99 for the Kindle version). Seems somewhere
| between scummy and scammy.
| fnl wrote:
| Oh, wow, scummy to scammy, indeed! It's all in the fine
| print... I didn't bother reading this appendix on the first
| read of the blog post.
|
| Disclaimer: I do really enjoy this book, as it reminds my of
| uncle Bob's Clean Code, but a short version, and with the focus
| on what to do after writing code, when you need to change it or
| want to understand it better.
|
| Yes, it is structured very much like a collection of blog
| posts. Which is great for me, as I typically work on learning
| one "tidying" a day or less. So I am not yet done with the
| book, end-to-end.
| jjice wrote:
| Is it scummy and scammy? I don't see anything wrong with
| someone selling their notes on a subject, no matter the price.
| The purchaser can choose if it's worth it to them or if it's
| not.
|
| I don't see the scummy or the scammy part here. Am I missing
| something?
| mtlynch wrote:
| I admit that my gut reaction is that there's something fishy
| about selling notes about someone else's book, but thinking
| about it more, what's the harm?
|
| There's nothing deceptive or sneaky about it. There's value in
| distilling information from a bloated book down to its useful
| ideas.
|
| There are lots of books that are just existing ideas repackaged
| for a different audience. For example, _Atomic Habits_ is
| basically a repackaged version of BJ Fogg 's research papers.
| And people see value in that, so why isn't it okay to do that
| in a more 1:1 way?
| Jtsummers wrote:
| The short release period gives off "For a limited time only!"
| vibes, a scummy way to entice people to buy something now
| because they might not be able to later. It's also unclear
| that the notes even add value, they're described as "raw
| unfiltered chapter-by-chapter notes". Are they just random
| thoughts? Are they a better version of the chapters they line
| up with? Are they a companion to the book (the notes
| elaborating on the parts this author found to be too brief)?
| Are they responses to the contents? You don't know, until you
| spend more than the cost of the not-actually-bloated book
| that they cover.
|
| > There's value in distilling information from a bloated book
| down to its useful ideas.
|
| Yes, but it's not clear at all that this $25 limited-time-
| only set of notes actually does that, and they cost more than
| a book that is decidedly _not_ bloated (it 's 100 pages, 33
| chapters, and each chapter is quite short).
| mtlynch wrote:
| Yeah, I agree. The "limited time only" seems manipulative
| and totally unnecessary.
|
| I'm less convinced by the criticism about the notes
| potentially not being worth the money. That's true of
| basically all products.
|
| In this case, if the buyer chooses to buy these notes based
| on the minimal information the author has shared, then the
| buyer should be ready to accept the possibility that the
| notes won't be what they expected.
| jbenoit wrote:
| He said it was unfiltered. If I was giving out some of my
| unfiltered thoughts, I don't think I'd want them floating
| around the Internet for anyone to read at any moment.
| TylerE wrote:
| If you're not comfortable with something "floating around
| on the internet" show could you possibly be comfortable
| SELLING that thing to the same people?
| jbenoit wrote:
| Of course. It means people genuinely interested in your
| content will have it, but people looking to score cheap
| Internet points on you won't. ("Did you know he once
| called chapter 5 of Bob Smith's book 'under-researched,"
| and Bob Smith's grandfather is Puerto Rican, so he's
| literally saying that people of color are stupid")
|
| If you look at the link, that's what he actually says.
| Sometimes these notes are not things I want to share with
| the whole world, but might be helpful for a few people.
| So what do I do? I release them, but only for a limited
| time. I also put on a price tag -- not because I expect
| to make any money, but so that only those genuinely
| interested will read it.
| PaulHoule wrote:
| Isn't Beck the Dr. Oz of software management? He's built a career
| on cargo cult practices that destroy software developers. Pushing
| agile he's done more harm than Tony Hoare's billion dollar
| mistake.
| fnl wrote:
| That's an interesting viewpoint, even surprising to me. Can you
| be more concrete about what you think is wrong with the agile
| software development movement Kent Beck co-founded, and how it
| destroys developers?
| simonbarker87 wrote:
| It has turned into a system that keeps developers in a
| constant state of crunch time. It simultaneously pushes all
| responsibility for delivery on to devs under the guise of
| "the team self organises" whilst stripping them of any real
| autonomy to actually feel a sense of satisfaction in
| completing tasks and delivering projects.
|
| When something goes well the anonymity that "the team"
| creates to the wider business means that praise goes to the
| project managers and product owners who, realistically,
| probably did very little beyond the kick off to deliver.
|
| Agile is a system that creates misery for devs.
| bitwize wrote:
| Indeed. In agile, successes belong to the team; failures
| belong to the individual developer. The higher-ups will
| know that it was your commit that broke the build, and they
| know exactly how many story points you delivered -- or did
| not deliver -- per sprint by your JIRA metrics.
| VHRanger wrote:
| Did you read the original agile manifesto? It's very
| reasonable.
|
| In the 20 years since, agile morphed into the agile industrial
| complex, where practices at best cargo cult the original idea.
| PaulHoule wrote:
| It's semi-reasonable. The individual parts are reasonable but
| putting it together to create a branded methodology(tm) which
| is "my way or the highway" was the beginning of the agile-
| industrial complex as we know it.
|
| You might make the case that Kent Back has actually put
| together two lines of code and run a compiler (even started
| JUnit) and the thousands of imitators who _talk just like
| Kent Beck_ haven 't, but if you're going to be critical of
| the agile-industrial complex you have to be critical of the
| founder too, who created a toxic style of discourse and a
| piratical business model of agile consulting.
| ebiester wrote:
| I go through some of the alternatives to agile in project
| methodology here:
| https://www.ebiester.com/agile/2023/04/22/what-agile-alterna...
|
| Go back to 2001. Which non-agile methodology would you have
| liked instead? RUP? How about we all end up in the PMBOK circa
| 2001?
|
| We take releasing monthly, weekly, or faster for granted. We
| take continuous integration for granted. So many of these ideas
| came explicitly out of agile delivery or were popularized
| because of it.
| legulere wrote:
| No silver bullet was published 1986 advocating for
| incremental software development. Feedback cycles in
| development were always a target for optimization, but often
| had technological roadblocks.
| zwischenzug wrote:
| RAD?
| PaulHoule wrote:
| I've got no problem with continuous delivery. I do have a
| problem with sprints (instead of wrecking your project with a
| fake deadline every year, wreck your project with a fake
| deadline very month.)
|
| Granted to do sprints you have to have a better build process
| than a lot of shops had in the 1990s but taking a week or two
| to deliver just because the process says so... means a 1-day
| delay can snowball into a delay of weeks or months.
|
| Also there are all the meaningless meetings that people
| dread. The standup that inexplicably happens first thing in
| the morning when you struggle to remember what you did the
| day before. The retrospective that I only want to answer with
| "I am so tired at the end of this sprint that I just want to
| go ride my bike in the hills or drink some beer or smoke some
| pot or play a videogame, not sit around uncomfortably in a
| group of people that are either disengaged and hiding it or
| doing a good job of pretending to be engaged"
|
| ---
|
| To me it is fighting works to bring up the PMBOK because the
| PMBOK doesn't specify a particular process but it _does_
| enumerate the things that have to be managed to manage a
| project, in "agile the good parts" you are just addressing
| all of these on a weekly cycle instead of a yearly or longer
| cycle. I also see the rejection of PERT charts and other
| dependency managements as a fatal flaw for A.I. and data
| science projects where model training might take 1/2 of the
| sprint so if you don't start building your model in the first
| half you blow. your. sprint. every. time. I first saw people
| make this mistake 12 years ago and they are still making it.
| By making people pay attention to a bunch of fake management
| metrics (story points) you distract them from paying
| attention to the metrics that matter for a particular app.
| I've even seen a lack of attention to dependencies be quite
| harmful to teamwork in more normal software projects because
| if a team really understood that getting Task A done means
| you can be efficient at Task B and Task C they might get as
| much real work done in one sprint than they wind up getting
| done in three.
| bitwize wrote:
| Sprints are essential to software development because they
| make underperformers much easier to fire. With long
| deadlines, a straggler can take their time and evade
| detection by management for months if not years, but with
| sprint commitments to which devs are held accountable on a
| consistent, fast cadence, stragglers can be easily found
| and eliminated.
|
| Agile in the workplace is not for you, it's for management.
| layer8 wrote:
| Sprints are Scrum, they are neither Agile [0] nor Kent
| Beck's Extreme Programming [1].
|
| [0] https://agilemanifesto.org/
|
| [1] https://en.wikipedia.org/wiki/Extreme_programming
| maximinus_thrax wrote:
| > He's built a career on cargo cult practices that destroy
| software developers.
|
| That's a very strong statement for which I don't believe you
| have the data to back it up. He (or his practices) has not
| 'destroyed' software developers. Not sure if you were working
| in the pre-agile era, I do agree some shops take to the
| extreme, but what we had before was a complete mess.
| hn_user82179 wrote:
| Good review, I enjoyed it. It does what I think I look for in
| technical book reviews, specifically:
|
| - gave a detailed overview of the book
|
| - gave an actual opinion, instead of just the summary
|
| - included specific excerpts to support the opinion
|
| - [bonus] talked to the author about specific questions the
| reviewer had
|
| And I appreciated this last paragraph:
|
| > So, if you're considering buying this book, just purchase a
| subscription to his Substack instead. He'll earn more and you'll
| learn more. The only one who loses is the publisher.
| criddell wrote:
| I recognize most of the tidying patterns listed in the article
| and the associated Twitter feed. My problem is the unnecessary
| noise in version control. If I'm trying to see when some chunk of
| code was changed using _blame_ , having a bunch of small edits
| can make it a lot more difficult.
|
| Still, I tend to do this kind of work on days when I'm not
| feeling great. I work on a large, reasonably old codebase (28
| years old) so tidying busywork sometimes leads me to someplace
| interesting.
| thestoicattack wrote:
| git blame does include --ignore-rev and --ignore-revs-file, so
| maybe if people updated such a file when making small edits, it
| would make your life easier.
| criddell wrote:
| Thanks for the idea. I'll check it out.
|
| We're actually still using Subversion for our main codebase
| and mostly happy with it. Being able to use --ignore-revs-
| file is a reason we might want to switch some day.
| jolmg wrote:
| If the noise is behind merges, you can also use `git blame
| --first-parent` and it should show the big merge commit with
| the comprehensive explanatory message, rather than the small
| commit in the feature branch. You can use `git show -m` to show
| the diff of those merges.
| barfbagginus wrote:
| It can be hard to review or blame small disordered commits. But
| you can rebase the commits to group and squash them for review.
| Then you may choose to squash the entire PR when you rebase
| main onto it.
|
| This has pros and cons. Let's explore them after an example.
|
| Scenario: Big & Noisy PR
|
| We have a PR with 13 commits : 3 fix commits, 5 refactors, 2
| doc updates, a CI modification, 1 feature commit, 1 test update
|
| The commits are in random order, and some of the commits are
| revisions to earlier commits. It's hard to understand the
| narrative of the commits and review things accurately.
|
| Solution Part 1: Tidy the PR
|
| 1. Reorder the commits by type and relevance: 3 fix -> CI ->5
| refactor -> 2 doc -> test -> feature.
|
| 2. Squash logically similar commits: fix -> CI -> 2 refactor ->
| doc -> test -> feature.
|
| A squashed commit should have a bullet list detailing each
| changed module and scope of change:
|
| """
|
| Fix(package a): Fix a, b, c
|
| This patch fixes:
|
| * (module b): fix [...]
|
| * (module c): fix [...]
|
| * (module c): fix [...]
|
| """
|
| 3. Review and CI the PR
|
| 4. Add commits needed to complete the PR
|
| The tidied PR was easy to understand: We fixed some pre-
| existing issues, beefed up the ci, then set the stage for the
| feature. The feature itself was clear and simple.
|
| If you do just this, your history will be much cleaner.
|
| Now I'm going to recommend something controversial:
|
| Solution Part 2: Squash-rebase the PR onto main
|
| Yup. Take all that work and mash it together. The final commit
| message should look clean and detailed:
|
| """
|
| Big Shiny Feature
|
| This patch implements [...]
|
| Feat:
|
| * (module d): Implement big shiny feature
|
| Doc:
|
| * (readme): update feature list
|
| * (userguide): add tutorial for feature
|
| CI:
|
| * (workflow a): modify [...]
|
| Fixes:
|
| * (module b): fix [...]
|
| * (module c): fix [...]
|
| * (module c): fix [...]
|
| Refactor:
|
| * (module a): rename [...]
|
| * (module b): delete unused [...]
|
| [...]
|
| """
|
| Benefits: - We drop 7x fewer commits onto Main - Project
| history is more legible - Commit messages are detailed and
| useful - Bisecting takes log 7 = 2.8 fewer steps
|
| Risks: - File diffs can be illegible if feature work intersects
| with refactor or fix work - There are 7x more defects per
| commit - It is harder to uncover root cause if we bisect
|
| Conclussion
|
| Tidying PRs before review is a no brainer - it greatly improves
| our review and history.
|
| Squashing PRs onto main loses some information, but can make
| history easier to navigate. Since we're disciplined and
| detailed in our commit messages, this is often much less of a
| footgun than it might seem. Each commit is now a logical and
| self-contained unit.
| edvardas wrote:
| > He gives some examples of ways that programmers, even after
| being taught in intro classes not to use magic numbers, still
| litter their code with constants like 404. But I wish he'd tell
| Python programmers to stop designing APIs where you write string
| constants like "r--" and "bs" to denote that your scatterplot
| should use red dashes and blue squares.
|
| Intriguing. I assume the author would prefer a stronger-typed
| alternative like explicit parameters and enums. Yet I wonder if
| having a small DSL-like syntax is actually the better for a
| scripting language. Most of these plots will be hacked together
| in a local notebook anyway.
|
| What would be a better alternative to this terse DSL in such
| case?
| selimthegrim wrote:
| And here I was anticipating a pun on tidyverse and a journey into
| how agile techniques would apply to R
___________________________________________________________________
(page generated 2024-04-01 23:00 UTC)