Seeking the Inner Ring – Revisited

01 Wednesday Oct 2025

Posted by Danny R. Faught in archive, career, life

Tags

Revisited

In 2004 I published “Seeking the Inner Ring” in my newsletter, which I have included below with further comments. I still think about it from time to time.

Seeking the Inner Ring

Throughout our lives, we seek to improve ourselves, especially our social standing and our career prospects. But are there some things we shouldn’t seek out? I’d like to introduce you to a compelling speech on this subject, and then I’ll share a relevant experience from my youth that has weighed heavily upon me for years.

Rings

I’ve just read a through-provoking speech by C. S. Lewis, “The Inner Ring.” An inner ring is perhaps the same thing as an “inner circle.” Wikipedia says that an inner circle “describes the individuals who are given special status…” and goes on to discuss things like secret societies, esoteric teaching, and friendship networks. [The Wikipedia page has changed a lot in the last 20 years, and it’s now merely a disambiguation page.] Lewis warns us against seeking admittance to any of the many inner rings we encounter in life merely for the sake of being there. But this isn’t easy. Lewis said:

I believe that in all men’s lives at certain periods… one of the most dominant elements is the desire to be inside the local Ring and the terror of being left outside.

This reminds me of the many invitation-only workshops like LAWST (the Los Altos Workshop on Software Testing) that I wasn’t getting invited to a few years ago. When I finally did get invited to LAWST a few times, I either couldn’t attend on the chosen dates, or I didn’t have much to say about the chosen topic, so I declined the invitations. Reaching the milestone of getting invited accomplished nothing but to alleviate my anxiety that I wasn’t worthy of being invited. You could of course make the argument that if I were even further inside that inner ring, I could influence the choice of dates and topics so they suited me better. Maybe some day I could, but in the mean time, I’m no longer fretting so much about whether I’m getting invitations like this.

Lewis recommends that we simply strive to be “one of the sound craftsmen,” and in the long run we will find ourselves inside what appears from the outside to be an inner ring, but in fact is not, and is much more valuable. It is friendship. For Lewis, inner rings are apparently artificial creations, built upon active exclusion and forced secrecy. My interpretation is that a circle of friends is secretive merely because the friends aren’t going out of their way to announce their mutual bond. If someone were to make a genuine request to join in, they would likely be welcomed, if only they knew that this was something they could possibly ask about. If a newcomer approached one or more of these craftsmen not for the purpose of joining a clique but for mutually advancing some shared interest, it is likely that this association of friends would be introduced to the newcomer in the natural course of things.

So we can generously view the web of semi-secretive gatherings merely as groups of friends who want to learn from each other. Other friends can be brought into the gathering, just as some may go. Should we expect them to grow without bound, once more people become aware of them? That’s an interesting question, as the character of a large group is different from that of a small intimate group. Would they be wrong to limit how many people they’re willing to interact with? Perhaps the limits will come naturally, as our own circle of friends is limited by how much time we can feasibly dedicate to maintaining the friendships. To do this, we pay attention to some people and turn away others.

The Vigil

Some accomplishments in our lives must be sought, and others must not. I saw a clear example of this as a Boy Scout. There is an organization within the Boy Scouts of America called the Order of the Arrow (OA). The OA is a secret society, in that the members are asked not to discuss the details of the initiation and certain signs of their membership level to people who haven’t achieved that level.

The first step to join the OA is to satisfy a set of well-defined requirements, including merit badges, camping experience, etc. Once a year, a certain percentage of those who meet the requirements are nominated for OA membership via a vote of the troop members. So first the Scout must take the initiative to satisfy the requirements, and the next step depends on a much more subjective process, which the Scout can only influence by improving his social standing in the troop. Meeting the concrete requirements can follow a predictable time line, but there is no certainty regarding when and if the Scout will be nominated.

If a Scout is nominated, there are again a set of concrete requirements. This starts with a weekend-long induction quaintly named the “Ordeal.” Then, much like a fraternity pledge, the Scout is encouraged to learn more about the organization. A year later, he can demonstrate that he’s met the requirements and then be inducted as a “Brotherhood” member.

At this point, the path becomes subjective again, and this is where it got interesting for me. The highest membership level is the Vigil Honor, which is bestowed to a small percentage of Brotherhood members by other Vigil Honor members. The only prerequisite is being a Brotherhood member for two years.

I was a Brotherhood member. I was active in the lodge and eventually became Lodge Chief. I was planning the induction for the three levels of membership, traditionally conducted jointly over one weekend. I was eligible for the Vigil Honor for the first time, and as Lodge Chief, I was a highly visible candidate. When I asked the person who was planning the Vigil Honor induction about coordinating with the other events of the weekend, he became suspicious about my motives. He sent me a letter, urging me, “Do not seek the Vigil – the Vigil will seek you.” Like the other candidates, I was delighted by the chance of receiving the Vigil Honor, but I was not consciously trying to abuse my power to sway the decision or learn who had been chosen.

During the weekend of the induction, I was briefing the people who would be conducting the ceremonies that evening. I made a terrible slip of the tongue, saying “When we are called out for the Vigil Honor” when I should have said “When they are called out.” I immediately corrected the error. It was an embarrassing slip. All kinds of things were going through my head at the time – the above-average likelihood that I would be recognized for my service as Lodge Chief, balanced by the growing cloud of suspicion that hung over me.

Just in case, I had brought supplies that I knew would be needed if I would be experiencing the vigil induction that weekend. I didn’t need them. The moment came, and I was not selected. I was disappointed, but didn’t feel I has lost out on something I was entitled to.

Later that year, we held another induction for those who couldn’t attend the first. I was no longer dwelling on the Vigil Honor. I didn’t bother to bring the extra supplies with me. But this time, I did need them. I was selected to be inducted into the Vigil Honor, and I scrambled to borrow camping equipment to survive a real overnight vigil under the stars. It was a profoundly moving experience for me, though of course I’m not supposed to tell you why.

Much later I found out that I had been selected all along, but at the first induction my name was struck off the list at the last minute. Though I was not trying to seek the Vigil, my actions implied otherwise, and those actions were highly visible. Now years later I still hear the mantra “Do not seek the Vigil” repeating in my thoughts any time I feel like I’m seeking recognition.

When to seek?

Clearly, some recognitions and affiliations must be sought, and others must not. The hard part is knowing which is which, and how to deal with the gray area in between. I’m still trying to figure out all the things Lewis was trying to say about inner rings. But I can take his conclusion to heart, that we should simply strive to do good work and form genuine friendships. As humans, we’re going to make some mistakes along the way. And we still have to choose how we seek out the work and make friends in the first place. No one said life was going to be easy!

My thanks to Matthew Heusser for pointing me to Lewis’ speech and to Matthew Heusser and Dave Millman for giving me early feedback on this article.

Epilogue – 2025

Speaking of friendships, I’m happy to still be in touch with Matthew Heusser.

Twenty years ago, I didn’t yet know that I was on the autism spectrum. I now wonder if my response to the accusations of seeking the vigil honor was purely defensiveness, and not considering what other people’s perceptions were. I never bothered to ask what was the basis of their concern. Was it a harsh punishment to make me think for half a year that I wasn’t selected? I don’t have a strong opinion about that, but I do know that the learnings from that experience will stay with me all of my life.

When I think of how this shaped my more recent behavior, I’m reminded of how I tried to get a promotion in a recent job. While trying to put together the promotion packet, at some point along the way, it started to feel like I was grasping for something that was going to distract from my daily job function. So I stopped pursuing it. I felt that if my company wasn’t going to proactively recognize my abilities and ease the path to promotion, it probably wasn’t the right path. (This decision was later validated when I read Developer Hegemony.)

black ribbon with three pins, all earned from my chorus activities — *My recent merit badges*

On the other hand, my latest “merit badge” was a recognition I received from the chorus I sing in, where I passed a difficult qualification on each of ten songs. Earning this one was not a zero sum game. It was nice to have a straightforward but challenging goal to achieve.

Use Your Unit Tests, or Else

04 Thursday Sep 2025

Posted by Danny R. Faught in software-development, testing

≈ 2 Comments

Tags

programming, software-development, testing

I’ve been talking to a few people about Test-Driven Development, which has me thinking about what important factors for success might be overlooked. Here’s a big one: you have to use the unit tests. Otherwise, they’ll rot on the vine and the whole TDD effort will be in jeopardy.

Here’s what I look for – you want to have a CI pipeline that automatically runs all of the unit tests and fails the build if any test case fails. You shouldn’t be able to release the software (without an emergency override from senior management, perhaps) if the unit tests aren’t all passing. If you don’t have a CI pipeline yet, you can still put this safeguard into your build process, and ideally into your version control system so you can’t make a code change if the tests aren’t all passing.

If you have failing unit tests already, the first step is to get them to pass (you might say “the tests are red”). Maybe this means fixing bugs in your production code, or more likely, fixing broken tests. But in a lot of cases, the most practical thing to do is to disable or delete the troublesome tests. You can put tasks in your backlog to fix them if you want to, but if they’re failing now, they’re not helping you, and you should get your tests back to “green” quickly. Only then is it feasible to introduce a mandate that they have to stay green.

Do you see a failed unit test run and instinctively hit the button to re-run them because they’re likely to pass after a few tries? Does your CI already do this automatically? Flakes in unit tests are less likely than with higher order tests, but it can happen. It’s also fairly common that tests that are called unit tests are really higher order tests (a topic we can explore later). This is a tough problem to deal with. I recommend that you take measures to identify which tests are flaky, and also keep metrics on which builds encountered one or more flaky tests. Though you might choose to remove flaky tests, when you do, you’re also removing the possibility that they might start failing consistently and thus demand the investigation of a bug in production code. It might make sense to take a long-term look at improving the design of your troublesome test suites, because flaky tests have a cost that you have to bear over time.

Do you have no unit tests at all? It’s time to get started! You only need one in order to update your build process and get people used to having green tests. Really, just one.

Why is all of this important? As soon as failing tests become normalized, you lose track of how much bit rot has happened in the tests. The technical debt quickly builds to the point that the most dedicated TDD adherents end up spending a large fraction of their time fixing problems introduced by other developers so that they can get the tests back to green and get back to their work. The pressure to ship the next code change will soon overwhelm everyone, and then your developers aren’t doing TDD at all.

If you’re not going to use the tests, don’t add them to your code base.

Open-Minded Networking

16 Sunday Mar 2025

Posted by Danny R. Faught in career

≈ Leave a comment

Tags

career, job-search, networking, writing

It’s been a while since I wrote about professional networking, though it’s one of my favorite topics and something that I love to do. Here I’m going to talk about how keeping your options open will serve you well.

In many contexts, it’s important to have a plan. That applies to managing your professional networking as well. However, frequently we don’t end up following a plan exactly. That’s usually ok, and in fact, it might be important sometimes to veer from the plan. That’s where the open-mindedness comes in.

I have a solid reason for each networking opportunity I spend time on, because my time is precious. Even though I often venture outside the plan, sometimes I actually do make the kind of contacts that I planned for.

Networking principle: Make a plan, and then be strategic about changing it on the fly.

Here’s an example:

I attended the Agile Open Northwest conference recently. I went last year because I was worried about my job security. There was a lot of great technical content and I was able to meet several people who could help with a job search. This year, I’m actively searching for a job, and I was hoping to further strengthen my network and get some tips for job hunting. While I certainly did expand my network and strengthen several existing connections, I found many more people asking for job search advice than offering it. So I created opportunities to share my ideas, and ultimately decided that I should write this blog post as well.

Networking principle: You don’t know in advance whether you’ll be giving or receiving.

Don’t be afraid to ask for help, but expect to give more than you receive.

Expand your expectations even further – it’s hard to know what kind of benefit you might be able to receive or offer. At Agile Open Northwest, I was planning to attend a technical session, but then I saw an opportunity to make a new friend, someone I really could identify with. I ditched the session and took some time to start a real friendship. That was certainly not in the plan.

Networking principle: Be open to getting and giving something different than you expected.

On the way to the conference a few days earlier, I went to a writer’s meetup. As the evening wound down, I asked someone I had been chatting with to show me his LinkedIn profile. I could hardly believe it. Just the previous day, I had been looking at his profile because he was highly experienced in a role I was considering pivoting to. I had never talked to him before, but there he sat. He’s a great new addition to my network.

Please indulge me in one more story. Not long ago, I offered to proofread a book that was almost ready to publish. I love doing this when it’s a book I want to read anyway, and it often helps to build a professional relationship with someone (careful criticism tends to be more valuable than praise). I spent time sending feedback on each chapter, and the author told me that this triggered a good deal of editing. A short time later, I was talking to a mutual friend, and he suggested that I ask that author for help with my job search, so I did. They spent a good deal of time giving me personalized suggestions for improving my resume, which I really appreciate. In this case, my plan was only to build external motivation to read a useful book and add a smart and well-connected person to my network. I was happy to benefit more from it more quickly than I had hoped.

So with a nod to Postel’s law about computer networking (“be conservative in what you do, be liberal in what you accept from others”), when networking with humans, make a solid plan and then be open to what comes out of it.

Design Evolutions Doomed to Never Finish

28 Wednesday Aug 2024

Posted by Danny R. Faught in technology, testing

≈ Leave a comment

When I’m maintaining a code base, sometimes I’ll get a big idea about a redesign that will improve the code. And because I strongly prefer to make changes in small steps, this means that the new design may be done in only a small part of the code for some time, living alongside the old design it’s replacing. In fact, the old design may never be completely replaced. How do we feel about that?

I’ll point to a concrete example. I was working with the open source CloudFoundry app called UAA. There were a few tests for the web UI that were relevant to some changes I needed to make to the code, and I saw that the tests had some duplicated code that could be cleaned up. Rather than simply extract the duplicated code to some common methods, I decided to introduce the Page Object Pattern (I’ve had a lot of success with this pattern on other projects, but I won’t go into all the details of how it works here.) You can see the first two tests that I redesigned in this pull request: Rearchitect two integration tests to use page objects.

After that pull request was merged, we had two tests using page objects, but many more that did not. I had agreement from my team that this was a good change, but we then had a mix of different designs in the tests. Even after later converting several more tests in the same test class to use page objects (current version: SamlLoginIT.java), as of now, not all of the tests in the class are using this design, and there are several other unconverted test classes as well. It’s now almost a year later with little further progress, and I’m no longer working on the team. The redesign will probably not be complete across all of the relevant tests for the lifetime of the repository.

We had a great discussion about this at a Legacy Code Rocks meetup (thanks Scott, Chris, Sarosh, Steve, Jacob, and Jeremy). The incomplete evolution seems to be a very common experience for developers (I’ve encountered it myself several times). The general feeling was that doing them is the right decision, even knowing that the rest of the code may never catch up. It was suggested that we should document these design choices so that in the future, maintainers will know which of the existing design approaches should be used for new code and further refactoring. Finding the best place to put this kind of documentation and keep it up to date can be a challenge, however.

So my advice is to make the code you’re working on better than you left it, even if you don’t clean up all the other code.

Thanks to Bruce Ricard for making some great contributions to the UAA redesign mentioned above and for inspiring this post.

featured photo credit: spaceamoeba, CC BY-NC-ND 2.0

Adventures in Personal Library Management

12 Monday Aug 2024

Posted by Danny R. Faught in career, technology

≈ Leave a comment

I have been rapidly adding books to my office library recently, and I realized that it’s getting hard to remember which books I already have. Scanning the shelves and other stacks where I may have books isn’t enough, because I also have ebooks from several different sources. Surely there is software that can catalog all of my books? Here I’ll document my experience with a library management app to try to wrangle all of my work-related books.

I did a quick search and decided to try Libib. A free Libib account gives me plenty of features for managing a small book collection. I can use the web interface or a mobile app. Once I set up my account, I grabbed my phone and grabbed a book off my shelf to scan the barcode using the mobile app. The book didn’t have a barcode, but it did have the ISBN printed on the back cover. I set it aside and grabbed another book. Success! The moment the barcode was near my camera, the book was added to my Libib collection.

I was able to add maybe as many as two-thirds of my books by barcode. In a few cases, there were multiple barcodes on the back of the book, so I learned to to slide the camera over from the side that had the ISBN barcode. I had to check the information about each book, though, because there were some misspellings in the title and some missing co-authors. A few titles included the subtitles, but most did not. I added the subtitles in most cases. I found it a little odd that for titles starting with “The,” this word was removed (not just moved to the end for collation purposes), but I left them that way. Several entries did not include cover art, or the cover didn’t match my edition, so I either took a rough picture or found a picture online.

For many of the books I couldn’t add by scanning, I was able to enter the ISBN printed somewhere in the book and that worked. For ISBNs that weren’t in the Libib database, I had add the books manually (the pro version of Libib allows for lookups by Library of Congress number, which the older books did tend to have).

There were a few interesting things about entering books manually. For example, a minor mystery was how to translate this word art into a title:

Part of the cover of a book. The text "PL/I" is on the first line, with the word "Programming" superimposed within the slash character. The second line says "A Manual of Style Weinberg."

I settled on “PL/I Programming: A Manual of Style” with an “I” instead of a “1.”

There is a field for the number of pages in the book. I had to do a bit of study to conclude that I was supposed to count everything except the covers, including blank pages and probably the end papers. So I took the last page number and manually counted the pages after that and before page 1. One fun case was the Programming Perl Quick Reference Guide, which had a page number on the inside of the back cover and both inside covers had printing. Then there’s Computer Lib/Dream Machines, revised and updated, which is two books printed back to back and upside down from each other, with two separate sets of page numbers that are added together in the page count (it only has one ISBN and one entry in the database). But I also have a scan of the first edition, which includes Dream Machines in reverse and upside down compared to the physical book so you can read it easily on the screen. There is a separate set of page numbers for Dream Machines, and also a continuing page count for the book as a whole upside down in the opposite corner, counting backwards from the highest page number in the book because of the way the pages were reversed.

There’s an interesting anomaly for the book I am a Bug – the text on the spine is printed from bottom to top. Every other book I have has the text reading down the spine instead of up. I can choose to either keep the rest of the book right side up, or align the spine text the way all the other books on the shelf read (I chose to keep the cover and contents right side up instead of the spine). In any case, it was an easy decision to make the cover picture in my book database right side up.

Several of my ebooks books have ISBNs but none have a barcode to scan. The Kindle ebook Dominating ChatGPT in 30 Days, though, has an ISBN for the print version but not the Kindle version. Books I bought on Leanpub often don’t have an ISBN, though they do have a publication date, which can change often as the book is updated. Examples include Developer Hegemony, and everything by Jerry Weinberg from Leanpub, like What Did You Say?, second revised edition. However, What Did You Say? is also available from Smashwords where it oddly does give an ISBN. The Smashwords version has a publication date of 2013, but Leanpub has an update from 2015. All of the books I’ve bought on Smashwords, however, do not include an ISBN. Here again, I was able to find an ISBN for one of them (Aremac Power: Inventions at Risk), for the Nook version from Barnes & Noble, which might or might not be considered the same publication.

A new category of publication I’ve fairly recently become aware of is the “zine.” I have a handful of these visually-oriented ebook zines that relate to my work, and none of them have an ISBN or any date printed inside. Examples include the “Pocket Guide to Debugging: Stellar strategies for sticky situations” and “How to Quit Vim.”

Most of my ebooks that are faithful reproductions of printed books seem to have proper ISBNs, including those from Pragmatic Bookshelf, Barnes & Noble, Manning, and InformIT. But some from more unusual sources, such as a scan of a 1949 book from Project Gutenburg (Giant Brains; or, Machines that Think) and a PDF sourced from GitHub (Uncurled: everything I know and learned about running and maintaining Open Source projects for three decades) have no ISBN and the publication date was not easy to track down.

By the way, I had to get creative with ebooks in Libib so I would know not to look for them on my bookshelf. I added an “ebook” label to all of my ebooks, and I added a note indicating where I got it from. For books with digital rights management, that tells me what app I have to use to read the book.

I really enjoyed having an excuse to thumb through my books, because I found some interesting things inside. I buy a lot of used books, some of which have a previous owner’s name written inside. I’d really like to talk to them to ask where they were in their career when they used the book. Alas, the person I’m pretty sure I tracked down successfully died in 2008.

I found library stamp cards in several former library books, like The Medusa Conspiracy (bonus points if you know why that one would be in my office library). In Computers in Business, I found an unpunched punchcard, perhaps used as a bookmark. And in The Aramac Project there was a letter I forgot I’d gotten from Dorset House thanking me for proofreading the book. In fact, it strokes my ego to find my name printed somewhere in the front of a book, and in some cases I didn’t even know I had influenced the content of a book. There’s one more going to print soon – stay tuned.

Surely there are established library science practices that have worked out how to solve some of the questions about cataloguing books that I’ve run into. I’d love to hear from people who are familiar with this.

Four Years after the 343

05 Friday Jul 2024

Posted by Danny R. Faught in career, testing

≈ 1 Comment

Almost four years ago, in 2020, I joined Alan Page for a podcast episode, ABT 343 – Danny Faught, which was part of a series where he would interview some of the listeners of the AB Testing podcast. I was recently asked whether I still stand behind what I said. I had to go back and listen to the episode to answer that question. My answer is, pretty much, “yes”, except I might end up not taking my own advice. Here’s my followup on the interview.

First of all, I was talking about how I was happy about working as a software developer and I did not recommend being a testing specialist. I find myself between jobs right now, and I’m considering various jobs openings where I could help developers get more directly involved in building test automation for the code they’re developing. Perhaps that would get me back into the business of being a testing specialist? I’m not going to overthink it. Strike that, yes, I am going to overthink it.

Another thing we talked about was being a software generalist. I’ve been asking around trying to learn how to market myself as a generalist. After not getting any help with that, I found this help: “A Career Guide for the Recovering Software Generalist” (along with several other great posts on that site, and a book). I’ve taken “generalist” out of my LinkedIn headline and decided to take more of a stand on what types of things I like to do.

We talked about my attempts to write a biography of Jerry Weinberg. I’ve only posted two more installments since then, but I was recently at a writer’s meetup working on the next one, so I’m still plugging along on it very slowly.

I mentioned having discussions on Twitter. I haven’t tweeted for about a year and a half. I miss it, but I just can’t support it any more. Instead, I’ve been getting to know Mastodon (I’m @swalchemist@fosstodon.org). I’ve found that I’m getting better engagement on LinkedIn, actually, so I’ve been more active there too.

Listening to that episode again, I like to hear how much we also learn about Alan. I hope you’ve tried DuoLingo again, Alan, or if you’ve used another language learning app, I’m curious which one. My DuoLingo streak is 1,704 days now. (Join me! I’m @swalchemist.)

Beyond Scrum

28 Friday Jun 2024

Posted by Danny R. Faught in technology

≈ 5 Comments

Tags

Kanban, scrum, TDD, XP

At the last few companies I worked for, my organizations happened to follow a similar agile methodology. It worked really well for us, but I don’t have a name for it. Maybe you can help name it. For now, I call it “Beyond Scrum.”

I’ve followed the Scrum methodology on a handful of teams in the past, including all of the ceremonies (colloquially – daily standup, sprints, sprint planning, demo, retro). I was even a certified scrum master.

But over time, some of the ceremonies seemed more useful than others. For one, sprints (a.k.a. iterations) especially created friction without providing any benefit. At the end of a sprint, there would almost always be stories that either had to be split, taking partial “credit” in the current sprint and the rest in later sprints, or pushed wholesale into the next sprint without getting any recognition for any of the work in the current sprint. We could get better at fitting stories into one iteration, but you know what makes more sense? Don’t arbitrarily chop our work up into sprints and then fret about whether the last few stories fit into the time at the end of the sprint.

My recent teams evolved into more of a Kanban sort of flow, where we would finish a story then pull the next story off of the backlog. There was no sprint backlog, just the overall project backlog. I don’t really know how much of Kanban we followed, because I don’t know much about Kanban. But I do like the continuous flow of starting a new story as soon as people were available to take on something new. Caveat: one team used a project management tool to groom at least a week’s worth of work at a time, which looked on the surface like a 1-week sprint, but the reality was that they always wanted at least a little more than a week of stories so they wouldn’t run out and have to groom more stories mid-week. Any stories that weren’t finished at the end of the week would flow smoothly into the next week with no anxiety about what sprint it was a part of.

Speaking of stories, story sizing seemed to lose its value. With no sprints, we didn’t need to calculate velocity in order to know how many stories we could cram into a sprint. Discussing size may have had value in terms of making sure the team understood the scope of a story, but ultimately the teams didn’t care what T-shirt size or Fibonacci number was put on each story. What did still matter, though, was writing good stories that had clear acceptance criteria and weren’t too large. Large stories that couldn’t be finished in a week were difficult to manage. But writing small stories was often difficult to do. Sometimes we’d split a story after seeing that it was taking a long time, or we’d just march on for two or three weeks and get it done.

My last few teams were working on infrastructure software–someone that a product owner might have difficulty relating to customer-visible features. So we found that the product owner role wasn’t very active or useful. Typically we would have a manager or designated person on the team take care of accepting stories, which was often rather informal. Often we wouldn’t even have clearly written acceptance criteria, and often the acceptance process was a rubber stamp that didn’t provide any value to the team. On a related vein – the sprint demo didn’t make much sense. We might demo individual stories as needed to facilitate story acceptance, but with the diminished participation of the product owner, we often skipped the demos. In their place, we might demo significant new features or newly introduced technologies to our team as needed. One team had a weekly time slot for this and other technical discussions.

Besides Kanban, another methodology we borrowed from was Extreme Programming (XP). We didn’t strive to follow all of the essential XP elements, so it would be disingenuous to say we were an XP team. But we did follow the most commonly known XP practices, test-driven development and pair programming. Another element of XP is the 40-hour workweek, and we did pretty well at that one too. Many of the other elements were there, like collective code ownership and continuous integration. But not the iterations and not much of the iteration planning.

We kept some of the other Scrum ceremonies. The daily standup was still useful, especially with a remote team. There were experiments with going more lightweight with an asynchronous standup in a chat tool, and in the other direction with adding a daily stand-down. And the retro was still popular, at least once every two weeks but more likely once every week. It wasn’t hard to find recent things to celebrate or improve on.

So there you have it – the elements of “Beyond Scrum” that were remarkably similar at two different companies. Maybe many companies have evolved toward something similar? Let me know if any of this sounds familiar to you.

feature image photo credit: Tom Natt (CC BY-NC 2.0)

Dr. Wiseman’s Luck Factor

13 Thursday Jun 2024

Posted by Danny R. Faught in career

≈ 4 Comments

Tags

luck

Continuing on my quest to better learn how to be lucky, I’m following up on my mini-review of Max Gunther’s book, The Luck Factor (Creating Luck: The Luck Factor). This time I’m discussing the book I set out to read in the first place: The Luck Factor: Change your luck – and change your life, by Dr. Richard Wiseman. It was published in 2003 and doesn’t contain any mention of Gunther’s book of the same name from 1977. They do have several things in common. However, Wiseman conducted research to back his claims, and also presents more elements of luck overall than Gunther. I’ll compare the five main points from Gunther’s book to Wiseman’s four principles and some of their 12 sub-principles. I’m really only paying attention to part four of Gunther, as I did with my earlier review.

Wiseman starts right in to the useful stuff after two chapters of introduction. In “Principle One: Maximise Your Chance Opportunities” he starts the same way Gunther did, talking about how a strong social network increases our luck. Wiseman goes on to tie in having a relaxed attitude, saying that luck is inversely proportional to neuroticism (one of the “Big Five” personality traits). The next sub-principle is about being open to new experiences, similar to Gunther’s “Fortune Favors the Bold” concept. “Openness” is another of the big five personality traits.

Principle two, “Listen to Your Lucky Hunches” matches with Gunther’s “Hunching Skill” concept. I felt that Gunther gave some more actionable advice here, despite not having research backing his ideas, and I especially like how he distinguishes between wishful thinking and informed hunches. In any case, for those of us who aren’t attuned to our own intuition, it’s worth studying.

Principle three in Wiseman’s book is “Expect Good Fortune”. I don’t see a close analog from Gunther, in fact, his “Pessimism Paradox” is basically the opposite. Both actually work well together. Wiseman’s principle is basically the power of positive thinking, and he gives several helpful angles on it. Gunther focuses on being prepared when Murphy’s Law strikes, and to expect that it always will. I believe we can benefit from both of these principles, as long as we don’t try to peg ourselves as entirely optimists or pessimists.

Wiseman’s principle four, “Turn Your Bad Luck Into Good” is hard to characterize. It overlaps a lot with the positive thinking in principle 3. One sub-principle, “Lucky people take constructive steps to prevent more bad luck in the future” hits some of the same points as Gunther’s “The Ratchet Effect”.

Overall, Wiseman comes across as more credible because of the research behind his book, and he devotes much of the book to the analysis of specific things that make some people much luckier than others. In addition, he includes several exercises to help you analyze how to improve your own luck, and the last section of the book further discusses how to learn to be lucky. However, I should note that Gunther’s book was an easier read, and it covers enough unique ground that it’s worthwhile as well. Both books have numerous interesting anecdotes of real people who either have unusually bad or good luck.

Some people respond to this topic with a big “duh, I know all that stuff.” In fact, the people who stand the most to gain are those with the worst luck. I hope they find these books. For me, I have more to learn about how to listen to my hunches, and though I think my attitude toward the things that contribute to my luck is already pretty relaxed, there are a few improvements I can make here as well.

Have you done anything to learn about what to do about your bad luck, or how to have even better luck? I’m curious to hear about it.

Test-driving fizzbuzz in bash

01 Saturday Jun 2024

Posted by Danny R. Faught in technology

≈ 1 Comment

Tags

TDD

Here’s one for the programmers in my audience. At a recent software crafters meetup, someone brought up the fizzbuzz coding exercise, and how funny it would be to code in bash. Examples of solutions in bash were easy to find, but I didn’t see any that included unit tests. So I tried a test-driven (TDD) solution for fizzbuzz in bash. Here’s how it went.

I updated Bats using homebrew on my Mac. There is now a GitHub organization serving as a home for Bats. I uninstalled an older Bats version I already had, made sure to remove the old tap (“kaos/shell”), and reinstalled from its new home using the brew instructions:

$ brew install bats-core
...
==> Installing bats-core
==> Pouring bats-core--1.11.0.all.bottle.tar.gz
Error: The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
...

Pay attention to those errors (the “Error:” label was in red on my terminal, but it was buried in a large amount of other log output). I needed to follow the instructions in the error output before I had the new bats-core in my path:

brew link --overwrite bats-core

I also wanted to use the bats-assert library, which depends on bats-support, so I ran:

$ brew tap bats-core/bats-core
$ brew install bats-support
$ brew install bats-assert

The fizzbuzz exercise asks for 100 lines of output, printing out the numbers 1 to 100, with these modifications: if the number is divisible by 3, print “fizz” instead of the number. If the number is divisible by 5, print “buzz”, and if it’s divisible by both 3 and 5, print “fizzbuzz”. Rather than try to process 100 lines of output in each test, I planned to write a function to return one number in the sequence. I started with this test in a test subdirectory:

#!/usr/bin/env bats

load '/usr/local/lib/bats-support/load.bash'
load '/usr/local/lib/bats-assert/load.bash'

setup() {
  source "../fizzbuzz.bash"
}

@test "fizzbuzz 1 returns 1" {
  run fizzbuzz 1
  assert_success
  assert_output 1
}

I created a dummy function in fizzbuzz.bash so the test could run:

#!/usr/bin/env bash

function fizzbuzz {
  :
}

And now the test does its job:

✗ fizzbuzz 1 returns 1
(from function assert_success' in file /usr/local/lib/bats-assert/src/assert_success.bash, line 42, in test file fizzbuzz-test.bash, line 12) assert_success' failed

-- command failed --
status : 1
output :
--

1 test, 1 failure

Getting the test to pass was easy enough:

function fizzbuzz {
  echo 1
}

Not shown below is the satisfying green color on the last line showing 0 failures (it was red before):

$ ./fizzbuzz-test.bash
fizzbuzz-test.bash
✓ fizzbuzz 1 returns 1

1 test, 0 failures

Next I added a test to the test script to triangulate and force a more useful implementation:

@test "fizzbuzz 2 returns 2" {
  run fizzbuzz 2
  assert_success
  assert_output 2
}

The first test passes, and the new one fails as expected. A simple change to the function makes both tests happy:

function fizzbuzz {
  local num="$1"
  echo "$num"
}

Now finally a test that makes it interesting:

@test "fizzbuzz 3 returns fizz" {
  run fizzbuzz 3
  assert_success
  assert_output fizz
}

Some simplistic logic gets the test to pass:

function fizzbuzz {
  local num="$1"

  if [[ "$num" = 3 ]]; then
    echo fizz
    return
  fi

  echo "$num"
}

So we triangulate again:

@test "fizzbuzz 6 returns fizz" {
  run fizzbuzz 6
  assert_success
  assert_output fizz
}

And that drives a full solution for the “fizz” part of the problem:

function fizzbuzz {
  local num="$1"

  if [[ $((num % 3)) = 0 ]]; then
    echo fizz
    return
  fi

  echo "$num"
}

On to the “buzz” part of the challenge:

@test "fizzbuzz 5 returns buzz" {
  run fizzbuzz 5
  assert_success
  assert_output buzz
}

Here’s what the test output looks like now:

$ ./fizzbuzz-test.bash
fizzbuzz-test.bash
✓ fizzbuzz 1 returns 1
✓ fizzbuzz 2 returns 2
✓ fizzbuzz 3 returns fizz
✓ fizzbuzz 6 returns fizz
✗ fizzbuzz 5 returns buzz
(from function assert_output' in file /usr/local/lib/bats-assert/src/assert_output.bash, line 194, in test file fizzbuzz-test.bash, line 37) assert_output buzz' failed

-- output differs --
expected : buzz
actual : 5
--

5 tests, 1 failure

Again I did a simple implementation that would require triangulation to complete:

function fizzbuzz {
  local num="$1"

  if [[ $((num % 3)) = 0 ]]; then
    echo fizz
  elif [[ $num = 5 ]]; then
    echo buzz
  else
    echo "$num"
  fi

}

One more test to triangulate:

@test "fizzbuzz 10 returns buzz" {
  run fizzbuzz 10
  assert_success
  assert_output buzz
}

A little tweak makes the test pass:

function fizzbuzz {
  local num="$1"

  if [[ $((num % 3)) = 0 ]]; then
    echo fizz
  elif [[ $((num % 5 )) = 0 ]]; then
    echo buzz
  else
    echo "$num"
  fi

}

Now finally, one more test for the “fizzbuzz” output:

@test "fizzbuzz 15 returns fizzbuzz" {
  run fizzbuzz 15
  assert_success
  assert_output fizzbuzz
}

My solution was unsatisfying, but it worked:

function fizzbuzz {
  local num=$1
  if [[ $((num % 3)) != 0 && $((num % 5)) != 0 ]]; then
    echo "$num"
    return
  fi

  if [[ $((num % 3)) = 0 ]]; then
    echo -n fizz
  fi
  if [[ $((num % 5)) = 0 ]]; then
    echo -n buzz
  fi
  echo
}

I was happier after a refactor to remove the redundant logic:

function fizzbuzz {
  local num="$1"
  local output=""

  if [[ $((num % 3)) = 0 ]]; then
    output=fizz
  fi
  if  [[ $((num % 5)) = 0 ]]; then
    output="${output}buzz"
  fi
  if [[ -z "$output" ]]; then
    output="$num"
  fi

  echo $output
}

There are far more concise solutions out there, but I like the readability of my solution. Now, as for getting 100 lines of output when running the scripts directly, I tacked this to the end of my script. This allowed it to meet this requirement while still not affecting how the unit tests work with the fizzbuzz function at all:

if [ "${BASH_SOURCE[0]}" -ef "$0" ]
then
  for i in $(seq 1 100); do
    fizzbuzz "$i"
  done
fi

I tested this chunk of code manually rather than try to automate a test for it.

$ ./fizzbuzz.bash
1
2
fizz
4
buzz
fizz
7
...

And there you have it, a testable fizzbuzz in bash. Some people add a few extra rules to continue the fizzbuzz exercise, and I’m confident that the tests would help support any further additions to the code.

Further reading: I first wrote about the Bats unit test framework in “Going bats with bash unit testing“.

Creating Luck: The Luck Factor

04 Saturday May 2024

Posted by Danny R. Faught in career

≈ 2 Comments

Tags

luck

I often have thoughts forming in my head about how we can actively encourage serendipity to happen more often. Then I had an opportunity to learn more about how others do it.

At Agile Open Northwest recently, I was practicing mob programming. Conference participants had gathered in a nearby hotel in the evening next to a cozy fireplace and a commandeered TV screen. In my sketchy notes from that evening, I found a book title, The Luck Factor, mentioned by the facilitator, Llewellyn Falco. The title piqued my interest. It might have been related to a discussion about having a bias toward action while mobbing, which makes sense to me now, but perhaps not for the reason Llewellyn had in mind.

I found several different books titled “The Luck Factor.” Llewellyn later told me that he was thinking of the one by Dr. Richard Wiseman. So I bought it. But I couldn’t help also getting one by Max Gunther, which was written much earlier. I read the Gunther version first, and here are my impressions of it. The full title, by the way, is The Luck Factor: Why Some People Are Luckier Than Others and How You Can Become One of Them. It was published in 1977.

More than half of the book is spent setting up a number of different things that good luck is mistakenly attributed to, such as paranormal effects and numerology, along with some amusing stories. But it doesn’t really start to deliver on its promises until part IV–”The Luck Adjustment.” Here are the essential parts of the solution, with my paraphrasing:

The Spiderweb Structure – being gregarious and building a broad social network
The Hunching Skill – recognizing when your subconscious is acting on real data and making educated guesses that you should pay attention to (vs. when it’s just wishful thinking)
Fortune Favors the Bold – basically, carpe diem, and make sure to answer the door when opportunity knocks
The Ratchet Effect – when that opportunity turns sour, be just as bold in cutting your losses
The Pessimism Paradox – plan for the worst, because you’ll sometimes need to act on those plans

These are all things I’m pretty familiar with, except the one I could stand to improve the most is my “hunching” skill. There are some especially useful ideas in that chapter.

I have Wiseman’s Luck Factor in my to-read pile now. Looking at the table of contents, it seems there may be a good deal of overlap with Gunther’s book. I’ll let you know how it goes (see Dr. Wiseman’s Luck Factor).

	Danny R. Faught on Seeking the Inner Ring –…
	coutré on Seeking the Inner Ring –…
	Danny R. Faught on Use Your Unit Tests, or E…
	coutré on Use Your Unit Tests, or E…
	Five for Friday… on Four Years after the 343