Patricia Aas
LightNews LightNews
banner
patricia.social.vivaldi.net.ap.brid.gy
Patricia Aas
@patricia.social.vivaldi.net.ap.brid.gy
170 followers 4 following 1.8K posts
Programmer, Co-Founder of @turtlesec (ex-Opera browser, ex-Cisco, ex-Vivaldi browser :vivaldi_red:), infosec, parent, bi 🏳️‍🌈, speaker, CoC required, NB […]

[bridged from https://social.vivaldi.net/@Patricia on the fediverse by https://fed.brid.gy/ ]
Posts Replies Media Videos
patricia.social.vivaldi.net.ap.brid.gy
20/ Relative to population size the 1970 Earth Day protest seems to be the largest US protest ever?
https://en.wikipedia.org/wiki/List_of_protests_and_demonstrations_in_the_United_States_by_size
The other top 3 are George Floyd at 26 million on the high end of a multi day protest, but the US population was much larger in 2020. No kings comes in at 6 million.
September 10, 2025 at 3:37 PM
patricia.social.vivaldi.net.ap.brid.gy
9/ Ok. When you put it like that it is quite damning.

California has 12% of the US population
30% of the homeless population
50% of the unsheltered homeless population
September 10, 2025 at 1:21 PM
patricia.social.vivaldi.net.ap.brid.gy
The Norwegian election is over, so I guess it’s time to read the book nobody seems to like.
Screenshot of book in audible Abundance New York Times Bestseller Read by the authors Ezra Klein Derek Thompson Introduction: Beyond Scarcity
September 9, 2025 at 5:54 PM
patricia.social.vivaldi.net.ap.brid.gy
Last year I wondered how one could strengthen the NOK to make imports cheaper. And it turns out that the US running straight into fascism while tanking their economy was the solution all along 😬
https://e24.no/boers-og-finans/i/4Bw036/dollaren-under-10-kroner
Graph showing a fall from 11.4 NOK per dollar to barely below 10 NOK per dollar
June 12, 2025 at 11:46 AM
patricia.social.vivaldi.net.ap.brid.gy
In the good old days of lightweight browser wars we had the ACID2 test, which reminds me of this: http://acid2.acidtests.org/
The reference rendering which looks like an awkward pixelated smiley face
June 12, 2025 at 9:13 AM
patricia.social.vivaldi.net.ap.brid.gy
YouTube Rabbit Hole Patricia has a question for the 3D printing crowd:

Is the little boat 3D-printing’s Hello World? And why that model?
https://social.vivaldi.net/@Patricia/114655282425237657
Small black 3D printed boat
June 12, 2025 at 8:30 AM
patricia.social.vivaldi.net.ap.brid.gy
Boom! Trademark finally paid off.
Screenshot: The scam account impersonating my company has been suspended
June 8, 2025 at 11:05 AM
patricia.social.vivaldi.net.ap.brid.gy
Changed my profile pic after getting tired of seeing the old picture on the scam account.

Picture from barricade by a closed tunnel in downtown Oslo.

So all of you who remembers who people are based on the profile pic: sorry, I’m the same tbh
Picture of a graffiti painting of a woman’s face, with blue hair, staring distractedly up and to the left of you.
June 7, 2025 at 9:43 PM
patricia.social.vivaldi.net.ap.brid.gy
I’m great at LinkedIn:

«It’s fascinating to see how folks who were still in primary school when I was working on a browser and doing agile, are showing up with their No True Scotsman. I’ve been building products for 20 years. I have programmed […]

[Original post on social.vivaldi.net]
May 26, 2025 at 7:32 PM
patricia.social.vivaldi.net.ap.brid.gy
Setting boundaries is good, good for you GitHub 💜
Work/Life balance ftw 🙌
Button: confirm squash and merge Button: Cancel Error message: Unable to read response from the server. Please try again later.
May 23, 2025 at 6:23 PM
patricia.social.vivaldi.net.ap.brid.gy
4/

Me: what if you’re wrong?

Agile coaches: what do you mean?

Me: what if this is Bad Actually? What if you’re making the organization Worse?

Agile coaches: I don’t get it

Me:

Them:

Me:

Them:
May 23, 2025 at 1:01 PM
patricia.social.vivaldi.net.ap.brid.gy
I feel like I should apologize for my posting. I will probably do it again, though, this is how I manage to force my brain to read something it Really Doesn’t Want To.
May 23, 2025 at 10:10 AM
patricia.social.vivaldi.net.ap.brid.gy
It’s becoming clear to me (on the main social media platform of the Agile Coaches: LinkedIn) that the reason I’m causing a stir is that I did the unthinkable:

I actually read the entire book
Twice
May 22, 2025 at 8:48 PM
patricia.social.vivaldi.net.ap.brid.gy
104/ This is what I mean about «textbook style», this is just regurgitating (10 year old) common knowledge, this isn’t bringing anything new, this is not their work. It belongs in a textbook for a college course or something. This book is not such a book. Or I really fucking hope not.
Technical and Cultural Maturity Organizations at different stages of technical and cultural maturity will find dif- ferent team structures to be effective. For example, by 2013, both Amazon and Netflix had a well-established strategy, using cross-functional teams with end-to- end responsibility for the services they provided to the rest of the organization.12 Meanwhile, traditional organizations adopting Agile- moving to smaller batches of delivery-often lacked the mature engineering practices required to keep a sustainable pace over time (such as automated testing, deployment, or monitoring). They could benefit from a temporary DevOps team with battle- tested engineers to bring in expertise and, more importantly, bring teams together by collaborating on shared practices and tools. However, without a clear mission and expiration date for such a DevOps team, it's easy to cross the thin line between this pattern and the correspond- ing anti-pattern of yet another silo (DevOps team) with compartmentalized knowledge (such as configuration management, monitoring, deployment strat- egies, and others) in the organization.
May 20, 2025 at 4:53 PM
patricia.social.vivaldi.net.ap.brid.gy
97/ On to part 2 «Team Topologies that work for flow» and chapter 4: «Static team topologies»

Note that flow, stream and domain have not been properly defined yet. And cognitive load seems to be anything that makes you unhappy at work.
May 20, 2025 at 3:20 PM
patricia.social.vivaldi.net.ap.brid.gy
85/ «Programs which model problem solving using means-ends or alternatively, nonspecific goal strategies can be analyzed in order to obtain an indicator of the relative information-processing capacity required by the two strategies. This section describes such a procedure.»
May 20, 2025 at 12:42 PM
patricia.social.vivaldi.net.ap.brid.gy
73/ I have thoughts on this, but for now I just want to show this dynamic in the text (see pic). Here they use the work of 3 widely different «thought leaders» to conclude you shouldn’t add new people to a team.
Work Flows to Long-Lived Teams Teams take time to form and be effective. Typically, a team can take from two weeks to three months or more to become a cohesive unit. When (or if) a team reaches that special state, it can be many times more effective than individuals alone. If it takes three months for a team to become highly effec- tive, we need to provide stability around and within the team to allow them to reach that level. There is little value in reassigning people to different teams after a six- month project where the team has just begun to perform well. As Fred Brooks points out in his classic book The Mythical Man-Month, adding new people to a team doesn't immediately increase its capacity (this became known as Brooks's law). In fact, it quite possibly reduces capacity during an initial stage. There's a ramp-up period necessary to bring people up to speed, but the communica- tion lines inside the team also increase significantly with every new member. Not only that, but there is an emotional adaptation required both from new and old team members in order to understand and accommodate each other's points of view and work habits (the "storming" stage of Tuckman's team-devel- opment model). The best approach to team lifespans is to keep the team stable and "flow the work to the team, " as Allan Kelly says in his 2018 book Project Myopia.
May 20, 2025 at 11:20 AM
patricia.social.vivaldi.net.ap.brid.gy
64/ Ok, this is petty, but I had to read it twice so…

A regular full book page is approximately Times New Roman 15, and a references page is approximately Times New Roman 12. The content section of the book is 185 pages, but if we subtract blank pages […]

[Original post on social.vivaldi.net]
May 19, 2025 at 7:52 PM
patricia.social.vivaldi.net.ap.brid.gy
48/ I’m back. Chapter 2 didn’t really bring anything more to the table except ending with a subsection of This Reorg Is Different, It’s The Other Reorgs That Are Bad. Also the Spotify stuff made its entry. And these need to be studied because they seem to be pivotal to this whole book.
Kniberg, Henrik, and Anders Ivarsson. "Scaling Agile ® Spotify with Tribes, Squads, Chapters & Guilds." Crisp's Blog. October 2012. https://blog.crisp.se/wp-content/uploads/2012/11 /SpotifyScaling.pdf. Kniberg, Henrik. "Real-Life Agile Scaling®" Presented at the Agile Tour Bangkok, Thailand, Novem- ber 21, 2015. http://blog.crisp.se/wp-content/uploads/2015/11/Real-life-agile-scaling.pdf. Kniberg, Henrik. "Squad Health Check Model-Visualizing What to Improve." Spotify Labs (blog), September 16, 2014. https://labs.spotify.com/2014/09/16/squad-health-check-model/
May 19, 2025 at 1:15 PM
patricia.social.vivaldi.net.ap.brid.gy
45/ Got a chat platform like Slack or Teams or whatever? A way for people to talk to other people across prossess boundaries *gasp*? Beware «this kind of many-to-many communication will tend to produce monolithic, tangled, highly coupled, interdependent systems that do not support fast flow.»
May 13, 2025 at 7:30 PM
patricia.social.vivaldi.net.ap.brid.gy
41/ First, from user interaction design we actually look for these things, I saw a wonderful picture of a park as an illustration once. I couldn't find it so this will do.

The idea is that "unintended uses" reveal real needs. So if I saw two teams that […]

[Original post on social.vivaldi.net]
A photo from high ground showing a green between buildings at a university, with some paved paths and a myriad of unpaved clearly visible, downtrodden, highly used paths.
May 13, 2025 at 7:14 PM
patricia.social.vivaldi.net.ap.brid.gy
40/ I have so many issues with this text we’ll just have to take them one by one. As a meta comment I am concerned that the authors are once again taking Other Peoples Thoughts and presenting them as if they’re saying the opposite of what they were […]

[Original post on social.vivaldi.net]
«Restrict Unnecessary Communication One key implication of Conway's law is that not all communication and collaboration is good. Thus it is important to define "team interfaces" to set expectations around what kind of work requires strong collaboration and what doesn't. Many organizations assume that more communication is always better, but this is not really the case. What we need is focused communication between specific teams. We need to look for unexpected communication and address the cause; as Manuel Sosa and colleagues found in their 2004 research into aircraft manufactur- ing, "managers should focus their efforts on understanding the causes of unaddressed design interfaces... and unpredicted team interactions... across modular systems." Mike Cohn, one of the originators of the Scrum product-development approach, asks these questions to assess the health of inter-team communication within an organization: "Does the structure minimize the number of communication paths between teams?... Does the structure encourage teams to communicate who wouldn't otherwise do so?» «Here, Cohn is addressing the need to ensure that if, logically, two teams shouldn't need to communicate based on the software architecture design, then something must be wrong if the teams are communicating. Is the API not good enough? Is the platform not suitable? Is a component missing? If we can achieve low-bandwidth communication - or even zero-bandwidth communication - between teams and still build and release software in a safe, effective, rapid way, then we should. This is visualized in Figure 2.5, which is based on Henrik Kniberg's "Real Life Agile Scaling." Figure 2.5: Inter-Team Communication Communication within teams is high bandwidth. Communication between two "paired" teams can be mid bandwidth. Communication between most teams should be low bandwidth. A simple way to restrict communication is to move two teams to different parts of the office, different floors, or even different buildings. If the teams are virtual or mostly communicate over a chat messenger tool, the volume» Continues in next picture «and patterns of the team-to-team communications can help identify communications that do not match the interactions expected for the software architecture. Similarly, if a large team regularly deals with two separate areas of the system, it can be useful to split this team into two smaller teams dedicated to each part, although only if it's the same team members who work on different systems. If the whole team works on more than one part of the system by design (for example, a newer service and an older component), keep the team together. (See Chapter 8 for more on patterns for long-term "continuity of care" for older software systems.) Sometimes, two or more teams may feel the need to communicate on software purely because the code for their parts of the system is in the same version-control repository or is even part of the same application or service, whereas logically, it should be separate. In these cases, we need to use "fracture plane" patterns (which will be discussed in Chapter 6) to split up the software into smaller chunks that can live in separate repositories.»
May 13, 2025 at 7:08 PM
patricia.social.vivaldi.net.ap.brid.gy
34/ Galaxy Brain: if they can’t talk, they can’t collaborate!

It’s almost funny how they draw the exact opposite conclusion from what Conway was expressing. He was expressing a problem, they have written a whole book on creating this problem on purpose.
Picture of parts of a page in the book: «Why are organizations unlikely to discover or sustain certain architectures? Conway provides some clues in his 1968 article: "Given any [particular] team organization, there is a class of design alternatives which cannot be effec- tively pursued by such an organization because the necessary communication paths do not exist." Communication paths (along formal reporting lines or not) within an organization effectively restrict the kinds of solutions that the organization can devise. But we can use this to our strategic advantage. If we want to discourage certain kinds of designs - perhaps those that are too focused on technical internals - we can reshape the organization to avoid this. Similarly, if we want our organization to discover and adopt certain designs - perhaps those more amenable to flow - then we can reshape the organization to help make that happen. There is, of course, no guarantee that the organization will find and use the designs we want, but at least by shaping the communication paths, we are making it more likely. Organization design using Conway's law becomes a key strategic activity that can greatly accelerate the discovery of effective software designs and help avoid those less effective. (In Chapter 8, we go into more detail on how to evolve an organization strategically with Conway's law in mind.)»
May 13, 2025 at 5:54 PM
patricia.social.vivaldi.net.ap.brid.gy
31/ And since I'm honestly worried y'all will think I have completely misunderstood everything, I present a couple of beautiful (told you the graphical designer was good) and completely nonsensical figures from this chapter.
4 applications that seem to consist of a ui layer and a "app tier", represented by 4 blue boxes labeled UI each with a corresponding arrow to their "app tier box", where the 4 "app tiers" have pointers to a single Core DB which has an arrow to a box with Ops on it. Text: Figure 2.2: Software Architecture from Four-Team Organization Four separate applications, each with a separate user interface (UI) and a backend application tier that communicate with a single shared database. This reflects and matches the team communication architecture from Figure 2.1; the diagram has simply been rotated ninety degrees. Four teams labled A to D have a front end dev and a back end dev box and then the backend dev boxes point to a DBA box which then points to an Ops box. Text: Figure 2.1: Four Teams Working on a Software System Four separate teams consisting of front-end and back-end developers work on a software system. Front-end devs communicate only with back-end devs, who communicate with a single DBA for the database changes.
May 13, 2025 at 5:45 PM
patricia.social.vivaldi.net.ap.brid.gy
22/ It’s also important to point out that Conway himself argued, in this paper, the one from which this law is derived, for a flexible organization that can adapt to changing design and geared towards collaboration.
http://www.melconway.com/Home/Committees_Paper.html
Conclusion The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication. This criterion creates problems because the need to communicate at any time depends on the system concept in effect at that time. Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design. Ways must be found to reward design managers for keeping their organizations lean and flexible.
May 12, 2025 at 7:10 PM