Noel Rappin Writes Here

Jessica Kerr wrote a very interesting post on bell curves and engineering teams. Jessica’s point is that bell curves are for random distributions, and that when teams share information and learn from each other, they no longer can be modeled by a random distribution. I think this as true, and a valuable insight. It reminded me of a different, related observation about teams and bell curves. Back in the 1980s, when he was applying analytics to baseball teams, Bill James argued that a common feature of the decisions made by poorly performing organizations was the assumption that baseball talent was normally distributed and could be modeled with a bell curve.

I’ve now tried to write this post like three times, and one thing that’s clear to me again is why you don’t see more write-ups of even moderately complicated real-ish problems. It’s hard to get enough of the context across to make the code sensible without being overwhelming. But there’s a Rails and ActiveRecord structure that this example gets to that I think is useful, so I’m going to try again.

Hey, if you like this post, you might like my recent books: “Modern Front-End Development for Rails” (Ebook) (Amazon) and “Modern CSS With Tailwind” (Ebook) (Amazon). If you’ve read and enjoyed either book, I would greatly appreciate your help by giving a rating on Amazon. Thanks! When last I talked about the Elmer project tracker, I was talking about Ruby magic and singing the praises of StringInquirer. I was expecting some pushback on the Ruby Magic™, but didn’t get any, so I threatened to do something really weird, like implementing an API for getting project history with something metaprogrammy and dynamic, like project.

Or: Rails and JavaScript, Part 5 A quick program note: If you like this newsletter, you might like my recent books: “Modern Front-End Development for Rails” (Ebook) (Amazon) and “Modern CSS With Tailwind” (Ebook) (Amazon). If you’ve already read and enjoyed either book, I would greatly appreciate your help by giving a rating on Amazon. Thanks! If you are really interested in how we got here, I wrote about the history of Rails and JavaScript, read Part 1, Part 2, Part 3, and Part 4.

A quick program note: If you like this newsletter, you might like my recent books: “Modern Front-End Development for Rails” (Ebook) (Amazon) and “Modern CSS With Tailwind” (Ebook) (Amazon). If you’ve already read and enjoyed either book, I would greatly appreciate your help by giving a rating on Amazon. Thanks! In my last post, I refactored the status field for cards in my project tracker to a more object-oriented representation that used value objects and classes to replace conditionals throughout the code.

If you’ve been reading this newsletter for a while, you’ve may have noticed there are two patterns I talk about all the time: We’re doing something because everybody does it but we don’t know why. We’re doing something, but we don’t really believe in it so we’re doing it halfway and not getting any benefit. Object-Oriented Design often hits both those patterns – teams use OO languages for various reasons without thinking about what OO can do for them, and then teams don’t use OO design or programming tools in a way that can help them achieve their goals.

A long time ago, I studied research on what makes successful engineering teams. (Not programmers, other engineering fields). I don’t remember a lot of it, but one phrase stands out: “preserving ambiguity”. Successful teams don’t make decisions that aren’t needed, and they don’t get themselves locked in too early. One fact about the beginning of a project is that you know less about the project than you ever will. And yet teams are often asked to provide estimates, do architecture, and make long-ranging plans at the beginning of the project when it is guaranteed that some of the assumptions will be wrong.

Previously on Locally Sourced: I wrote about building a small feature in Hotwire. Also, I have two, count ‘em, two, books for sale. Modern Front End Development For Rails (ebook) (amazon) and Modern CSS with Tailwind (ebook) (amazon). I have this idea that teams get in trouble when they do something that they are “supposed to do” without understanding what problem they are trying to solve and what tradeoffs they are willing to make to solve it.

Previously on Locally Sourced: The Tailwind book is out. Buy it in ebook or at Amazon. Modern Front-End Development For Rails is in final layout and headed to the printer. This post will make a lot more sense if you’re familiar with Hotwire If, for example, you bought a book about it… Simplicity is Not Simple To the extent that I have a guiding principle of software development it’s this Alan Kay quote:

Previously on Locally Sourced: About a year ago, I started this newsletter with a bunch of posts that I originally called XP 2020 and later called Entropy Essays – you can find all the posts here. I got bogged down and never got to the punchline… There’s a common thread in the story of how testing, object design, and pair programming have been adapted since XP and Agile became buzzwords. I think estimating fits here as well.