Agile Otter Blog

  I have this very simple/simplistic view on leadership. People will become a follower if: a) They believe the person is competent b) They will personally benefit from that person's competence Whether it's a minister, a businessperson, a writer, a local organizer, or a criminal doesn't matter all that much. We like to impart character and integrity to our leaders, and we like to pretend that we chose them because of their superior traits, but it doesn't matter as much as we would like to pretend. If those were really the criteria, we would never fall for con men and tricksters. Remember. that people followed some pretty unsavory characters in the past and many do now. I had to chew on this for years, because people can be radical followers of some pretty awful characters. Why would they be so blind to the character of their heroes? It seems consistent now if one focuses on two factors. The perceptions don't even have to be correct. Sometimes confidence masquerades ...

 So, I have a command line utility that collects and presents some time-series data. What it is isn't important, but dates are involved. You can specify start dates and/or end dates with options --after and --until .  If you specify neither, you get everything. This programming idea is not so interesting on its own, and I have multiple expressions that all work just fine. It's not a programming puzzle I am here to present. Instead, I'm curious about which version speaks to you, which teaches you, which repulses you.  More than that, I'm interested in WHY.  Here is an if-the-else version: Here is a similar version using a dictionary: And one that uses structural matching: Some people will naturally prefer if/else for the simple reason of familiarity. They see a lot of if/then/else logic, and so there isn't much to learn or think about. They may call it "simpler' but it is not.  The dictionary version has more parts, but they're very simple parts, and al...

 CSS really is fun.  No, seriously. I'm not being sarcastic here.  Even though I've been in software a long, long, long time, I hadn't really studied CSS before last year (shocking, I know) and so I've been behind in my training.  I had an opportunity to dive in more, and all was going well until I started playing with media queries and ran into a specificity problem that wasn't so obvious (to me, though it may have been to you). So, to help people who are treading the same path, here are some aids on specificity: * W3 Schools has a fun "try it and learn" approach to general CSS Specificity * Saucelabs specifically breaks down specificity and media queries * Halodoc provides some best practices  to avoid troubles. * Specificity with Darth Vader and Stormtroopers and stuff at smashing magazine. These should get you past the worst of your troubles nicely. If you do get stuck, then it's always nice to experiment with a local HTML/CSS document or maybe fi...

 After many times looking up various resources on code smells and code smell taxonomies, I finally decided to make a listicle (list article) of these.  Enjoy: Industrial Logic's Code Smells album is carefully curated and deftly explained. A winner. Industrial Logic also has a cheat sheet for code smells (recommended) The OG Wikipedia's extensive listing A nice taxonomy at Coding Horror A nice writeup at Refactoring Guru The Samman Coaching List has nice descriptions. There is a longish list without explanations at DevIQ, as a jumping off point for many interesting web searches. Arjan Codes (a nice channel, recommended) has a video introduction to Python Code Smells. On the "positive" side of the ledger, we also have virtues: The original Code Virtues article from Pragmatic Programmers, republished at Medium. The explainer article (feel free to start here) at Industrial Logic.

 A big thread erupted, all full of misunderstandings and miscommunications, about the idea of "private" methods.  It all started quite innocently (I maintain) when someone asked how we felt about testing private methods. Some people jumped in with "Absolutely Not! Never! That's wrong! Test via public interfaces." I thought a little longer, and said "I'm not sure" and then later "I'm not sure that 'private' is even needed." This is where the problems started, and maybe here I can clarify what I meant by it all.  People assume (and insist) that I could only possibly mean that they should substitute 'public' for all protected and private members, polluting the interface, and inviting the violation of a class' internal state.  That was never my intention and still isn't. Still, this is what people insist that I must have meant from the start. I suppose this is because that's what they imagined me to mean and it...

 I've noticed that for several years now, one of the most frequently asked questions in agile forums deals with the splitting of stories.  We simply can't create a feature, epic, or improvement in a single gesture. If we are going to make progress, we have to start somewhere and build in small pieces. One way or another, whether we release after each piece or not, we have to make progress in bits and pieces.  In the bad old waterfall days, the analysts and designers would come up with a system with functional decomposition. It would essentially describe a tree with upper-level modules calling lower-level modules all the way down to individual functions. After the designers have done a top-down design, the developers would start building the system starting from the bottom-up. They would build the pieces and the higher-level pieces that use those pieces until they had components, sub-assemblies, subsystems, and eventually the entire product.  This "top-down design, bo...

I was chatting with a manager who was once a PO on a team I coached many years ago. This is only my best memory of the conversation (I didn't record it at the time). I may have slightly embellished it with snippets from conversations that followed over the course of days or weeks, but I try to be faithful. One day she took me aside and asked what she should be doing to accelerate the team and get more work pushed through. “Nothing,” I said. “Nothing? But I thought that I’m supposed to be getting maximum work and speeding up the team…?” “Nope. Your job as PO is to maximize the value of the work, not the quantity of the work. Given that they’re doing roughly the same amount of work each week (barring emergencies and vacations), your job is to make sure that what they are working on is the most valuable work that they could do that week - that it is impactful and useful.” The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Te...