wrong tool

You are finite. Zathras is finite. This is wrong tool.

How corporate culture excludes me, or why I never bothered interviewing at Amazon, Facebook, and Google.

by Leave a Comment

Every so often, I read an article breathlessly talking about the greatness of any particular meeting process and how everyone should aspire to such a meeting culture. And it got me thinking about my career choices.

I never interviewed at Google earlier in my career because they wanted my grades. My grades undersold my abilities because of my neurodiversity. And anyone who thought they measured me accurately was probably a place I never wanted to work at. And then there was this whole class of companies founded by ex-googlers that I associate with that culture and choose not to even consider. I didn’t trust them to judge me based on deeply flawed metrics.

I never interviewed at Facebook because I saw how they had these all-night hack-a-thons, and I was about to be a dad, and I never wanted to work at a company where spending the night hacking was a requirement for my job. In particular, I knew that the people who could spend time would build social relationships that endured, and I would be formally excluded from them or have to choose not to see my kid. There were these youtube videos of the corporate culture and the hacking, and I was like – Nope, not for me. At Zynga, we introduced hack-a-thons, and folks wanted to mimic the all-night nature, and I remember throwing a temper tantrum in an exec meeting, and we agreed that they would not be all-night extravaganzas.

And so similarly, if a recruiter said ex-Facebook, I was like – probably not the kind of place where wanting to be with your family and in your bed will be a place for career growth.

I never interviewed at Amazon and had panic attacks when folks at VMware wanted to introduce Amazon-style meetings because, again, because of my neurodiversity, I knew it would exclude me. But I was always curious whether it was as bad as I thought.

Amazon came to VMware to have a meeting complete with a six-pager, and I was in the meeting because they needed my buy-in to get some technical work done. The meeting was precisely the disaster I expected. I was expected to read a print-out (I use text-to-voice) in some standard font (I use Open Dyslexic). I was expected to read this wall of text in 20 minutes (I scored in the bottom 3% of the population in reading and retaining information) and offer comments.

Did the Amazon employee ask if this works for me? No. Instead, I was expected to endure. So I did my best. What made it worse was that my other coworkers happily did this work. That was humiliating. I felt I was being denied access and treated as a semi-human being. And I realized I could never work with Amazon as a partner or an employee. And companies would copy this style, and I would be pushed out of those companies as well. And that this megalith of a corporation was about to kick me out of the tech industry. Talk about motivation to make VMware win.

And if I was in a charitable mood at the beginning of the meeting, I was livid by the time we got to my chance to talk. I was like, damn if they are this inconsiderate to partners, I can’t begin to imagine how they treat employees, and I thought – nope, not for me. They came to get my support, and their meeting structure did the wrong thing.

In the end, I was determined to ensure Amazon failed. I wanted them to fail. Because if their success meant more of these meetings, by god, I would do everything in my power to fight back.

I will observe their proposal was ridiculous, and it never went anywhere, more or less for the reasons I described in the meeting. I wasted an hour reviewing a ridiculous proposal and being humiliated.

A win, I guess?

Every so often, someone asks why it is such a big deal, and Sheri Byrne-Haber (disabled) explains it oh so well. Because those meetings are designed to make people like me less effective, I wonder if that’s the intent. But I know me, and mine are not welcome, and I will leave.

Now, I will observe that I had to grow up as well. When I got into a position of power, I, too, wanted meetings that only worked for me. And my team blew a gasket and demanded change, and so I changed begrudgingly. But it was only when I got into a shouting match with a senior executive who wanted the text, not a draining meeting, and we argued. I learned that to be inclusive, I had to accommodate his needs as much as he had to accommodate mine. So I used voice-to-text to produce documents, and he used tools to create text I could process via audio systems.

The point is that any rigid system is a rigid system. And its purpose is to force people to conform and, if that conformance doesn’t work for them, to force them out. And if you want to work with all the best and the brightest, then you need to be flexible and creative and not rely on rigid rules of how meetings must work.

https://www.linkedin.com/pulse/why-amazon-six-page-meeting-process-doesnt-work-sheri/

57 architecturalist papers: generated software and created software

by 1 Comment

Over the years of writing and architecting software systems, I saw the emergence of automatically generated layers of software that were nominally supposed to eliminate a class of software development or even software developers as an employment category.

Borland C++ 3.1

For example, in the 1990s, higher-level programming languages and dynamic compilation of code were supposed to eliminate the need for low-level programming. I remember taking classes in the early 1990s where garbage collection and object-oriented programming would unburden software developers from resource management.

At the same time, we had the emergence of frameworks that promised further productivity gains, like the Distributed Computing Environment and CORBA for distributed systems. As for building Graphical User Interfaces, we had the proliferation of toolkits like OpenView, X-Motif, Borland’s Application Framework, Java Swing, Microsoft .NET Framework, etc.

Over the next 30 years, the story stayed more or less the same. Every year there would be some new technology that would, once again, unburden the software developer from toil.

And, of course, if you happen to be the person paying the software developer, make it possible to have fewer of those developers working for you.

I recall in 1994, a Professor at Brown University remarked to the students in computer science his concern that there would not be enough high-paying jobs in the field. The emergence of OO programming, and the ability to have people work remotely, would reduce the value of a degree in computer science over the long haul.

And he was right, but not quite in the way he anticipated.

All those technologies did reduce the need for highly skilled technology experts to build much of the world’s software. In 2003, I had to write my own time-series database for a product. In 2022, I would spend more time deciding which one to use.

The available software building blocks are more powerful, flexible, and compelling than at any point in the history of computer science.

And that has enabled more people to write software that I could not have conceived of in shocking time frames.

That point was brought home to me in 2009 when a small team of engineers at Zynga leveraging AWS, PhP, and a home-grown NoSQL database built a game on a distributed systems architecture with over 2000 servers. And none of them had a Computer Science degree.

And yet we still invest in software, building new products, and hiring new engineers.

Why?

Competition. It turns out that when everyone can make a scalable game without a CS degree, the magic is not in making the scalable game but in building a scalable game. And when there is a large pool of competing choices, and success only goes to the best game, marginal and incremental improvements result in huge wins.

This brings me to my somewhat non-obvious conclusion: software products’ success is a function of how easy it makes the lives of people who do something useful. The problem is that when anyone can do something, it has no commercial value.

For example, when everyone can build a scalable game, the value of a scalable one is zero. It’s like with special effects; when everyone can have great special effects, the value of special effects in a movie is zero.

So what did the framework and toolkits make easier? They made the expected stuff easier, so you can work on the element differentiating your product or game. You still need to invent a new game mechanic, and that new game mechanic, because it is new, requires new code. And, here’s where it gets fun; eventually, you find new game mechanics that require new hardware, which requires new frameworks, which require…

And if the demand for new games is significant, then the need for new game mechanics is large, and the demand for new software is powerful. We all wonder why we are not more productive while playing games that are more beautiful, engaging, and deeper than ever before.

We live in a world where the amount of software is growing. And more people are writing software than ever before.

And that’s a good thing. But the need for new innovative software remains. And that innovative software is not generated; it is created. And that new software must be created when the boundary between the digital world and the human or physical world changes.

56 architecturalist papers: what if the different people never came?

by Leave a Comment

In my post yesterday, I attempted a rebuttal of Mr. Jassey’s arguments about the superiority of in-place work.

My meta-argument was that a diverse workforce has a diverse set of needs. And that what works for some does not work for others.

A great meta-question is – so what? Does it matter to an organization if some folks are excluded, and some are not? Is cultural homogeneity an asset or a disadvantage?

When a company asserts specific lived experiences are valid and others are not, they explicitly articulate that specific human experiences suit their culture and others are wrong.

Those whose experiences fit into the wrong category self-select against that company. And over time, if it is successful, the company views its choices as correct because those who don’t fit in never show up.

They never bothered to come and talk to you because they saw that you thought they were terrible and that rejection of their existence meant there was no space for them there. But it’s just working from home? Right? Except it isn’t. Where does that end when you assert your lived experience is correct and the other person is wrong? Why should it stop at how we work together? Why not how we dress? How do we address each other?

“We chose to do it this way, and we are successful, therefore we were right.”

What was a choice, a preference, becomes because of the group’s success criteria for articulating what is generally correct and generally incorrect for all human beings.

And again, so what?

Diversity and diverse perspectives matter because otherwise, you suffer from groupthink. If everyone does it one way, and all successful people do it that way, and no one objects to how we are doing it, then it must be the right way to do things. And what happens, invariably, is that someone else figures out a better way to do it, and then the group collapses as the new way triumphs over the old course.

Several years ago, I wrote about Usain Bolt. Usain Bolt was too tall for a sprinter. That was the orthodoxy. But a coach decided to ignore orthodoxy, and guess what? Usain became the greatest sprinter of all time.

Or Ervin Johnson was too tall to be a point guard. But another coach saw his passing and skills and decided that the advantages he brought to the game because of his vision and height and reaching from the point position outweighed the benefits he got to his team as a front-court player.

History is littered with companies, teams, and organizations convinced they were doing things the right way. By asserting that their lived experience was correct over other people’s lived experiences, they drove talent away. That talent then thrived elsewhere.

A rebuttal of some of the points of Mr. Jassy

by 2 Comments

Note I come to work five days a week. I like being in the office. I enjoy being around human beings. And have been leading remote teams for almost 20+ years. In that time, my groups have delivered over 10 billion dollars in actual money, many multiples of that in shareholder value.

Mr. Jassy wrote this memo to his staff, telling them why he would require everyone to come to work.

Update from Andy Jassy on return to office plans (aboutamazon.com)

So he starts with this:

It’s easier to learn, model, practice, and strengthen our culture when we’re in the office together most of the time and surrounded by our colleagues. It’s especially true for new people (and we’ve hired a lot of people in the pandemic); but it’s also true for people of all tenures at Amazon. When you’re in-person, people tend to be more engaged, observant, and attuned to what’s happening in the meetings and the cultural clues being communicated. 

Except if you have ADD and sitting in a meeting where you cannot sit still gets in the way. Or you are deaf, can’t hear what people are saying, and don’t have zoom translate what is being said in real-time.

For those unsure about why something happened or somebody reacted a certain way, it’s easier to ask ad-hoc questions on the way to lunch, in the elevator, or the hallway; whereas when you’re at home, you’re less likely to do so

I am surprised by this one. The emergence of technology like Slack or the DM function in Zoom has democratized communication. Finding time for a senior leader to ask them a question is tricky. And the senior leader in the elevator can walk away from you. But when you send them a message, they tend to take the time to respond because they can do so asynchronously.

In the more productive brainstorm sessions I’ve been a part of over the years, people get excited and blurt out new ideas or improvements to prior proposals, quickly advancing the seed of an idea, and leading to the broader group getting energized and feeling that it’s onto something. This rapid interjecting happens more often in-person because people feel less inhibited about jumping in or even interrupting sometimes. 

I am a cis-gendered white man at the apex of my profession, which worked for me. How many women and non-white and non-cis-gendered men have we trashed over the years because they didn’t speak up?

My first meeting back in person was the same old guys talking with all of the women and others silent.

It was so bad we had to introduce zoom to deal with the problem.

Serendipitous interactions help it, and there are more of those in-person than virtually

This one surprised me. The number of in-person interactions is an order of magnitude smaller than the interactions with people digitally. Just count the volume of people you contact over email, the number of people your email goes out to, etc. Mr. Jassy feels that is low-value communication.

Regardless, Mr. Jassy has made his choices, declared that he believes they are correct over other people’s lived experiences, and can force his employees to choose to work for Amazon or leave.

55 architecturalist papers: Facebook v Zynga Microchannel, the Apple Store, D&D, and killing platforms

by 2 Comments

IBM PS2 60 and 80 side-by-side

In 1981, IBM introduced a revolutionary computer that radically transformed the tech industry, the IBM-PC.

What made the IBM PC revolutionary was its open-system architecture and the royalty-free nature of its use.

Specifically, anyone could create an IBM clone, and anyone could develop software for said IBM clone and make money without paying a dime to IBM.

IBM hated that. So their solution was in 1987 to create the Microchannel PS/2. The intent was to create a new divergent market of PC’s that no one could make clones of.

What happened was that the market split between PS/2 and EISA, and the PS/2 became a failed computer system and a historical artifact and a warning to those who would want to close an open platform.

In June 2008, Apple introduced the App Store. The Apple App Store was the first massive commercial success of a cell phone app store. And it created a standard for how to take royalties from creators. And it was a huge success. So much so that we have had lawsuits that are still going through the court systems to determine the boundaries and limits of the market rules Apple can enforce in the market they created.

In June 2010, Facebook saw the success of the Apple Store and decided they wanted a piece of the Zynga action. Facebook had created an Open Platform, and that Open Platform enabled Zynga to grow like wildfire. But Facebook wasn’t making any money from Zynga. And so, there was a stand-off between Zynga and Facebook. Zynga and Facebook signed a deal that required Zynga to hand over 30% of its revenue to Facebook. That 30% revenue haircut killed Zynga.

Facebook’s thesis was that by creating a new currency, Facebook Credits, that Zynga customers would use, they would increase the total number of people who had digital money, and thus more money would be spent. The thesis failed, and Zynga suffered.

In both Apple and Facebook’s cases, they saw intellectual property creators who used their platforms as free-loaders. In Apple’s case, the tax was declared up-front, so you knew what you were getting into. In Facebook, it was an after-the-fact revision that destroyed a business.

But what happened to said intellectual property creators? As my son recently said – “why does mobile gaming suck?”

Gaming is a hit-driven business. One hit makes all the money, allowing you to make the next game. 30% is a massive tax, restricting the money you have to make further investments. And so the gaming industry has moved back to open platforms, ironically, the Windows PC.

This now brings us to the recent decision by Hasbro to introduce OGL 1.1. A lawyer covered it well here – https://medium.com/@MyLawyerFriend/lets-take-a-minute-to-talk-about-d-d-s-open-gaming-license-ogl-581312d48e2f

If you parse the Lawyer’s responses, it boils down to trying to create an Apple-like App Store for D&D content. Essentially, you hand over your financials and content for a smaller slice of the pie for the right to play.

In effect, it destroys the open ecosystem that D&D had. For example, suppose I have a website with a random generator of D&D content. That random generator is illegal.

Now Hasbro is betting that people play D&D and don’t care about the open content and that the creators will have to suck it up and deal.

Except, and this is a big exception, that isn’t true.

The iPhone was a singular technology with no ability to be replaced. Folks used Facebook because they wanted to connect with friends. Those platforms had value outside of the gaming industry. D&D is a game and a platform.

But it’s an extraordinary game where the player and the GM create content while playing. And the GM can adapt content from other gaming systems to their game. And the GM can adapt rules to their game.

In short, I expect the TTRPG community to discover the power of system-neutral gaming. And that the internet will increase with systems that allow you to convert to the gaming system of your choice. Except for the new restricted one.

My take, and it’s hopeful, is that D&D will continue, but tabletop role-playing will finally escape the long shadow of its creator and his original game.

But going back to software architecture and platforms, it’s always tempting to control a market, and there is a lot of value in doing that. But when you extract a lot of money from a market, you eventually kill the market. And over time, those creators whose businesses are hits will move to open platforms.

Where else to find me

by Leave a Comment

kostadis_roussos | Twitter | Linktree

54 architecturalist papers: career progression for those of us who are under-represented

by 1 Comment

I intend to write a lot about why you should go and read this https://hackingcapitalism.io/

And then realized I could write very little.

It would be best if you read Kris Nóva’s Hacking Capitalism because it is a highly well-written document by an outsider on how to function and succeed in the alien tech world. It would be best if you read it because Kris Nóva (@nova@hachyderm.io) is a fantastic person who is impressive and distills a lifetime of insight into a tight actionable document.

And that’s the only reason you should read it. And if you need me to tell you why beyond that, here’s my life story.

At NetApp circa 2002, a great manager named Jonathan Crowther took me to lunch to discuss my career. It was the first time any manager had done that.

I was frustrated because my career had stalled out. And I didn’t understand why.

And he smiled and said that the problem was that I only approached people as functional units that needed to solve my problems or I needed to solve theirs. That I never treated people as people.

And I remember staring at him, and then he explained, “when you come in on Monday, you never say – how was your weekend? It’s always – I need this.”

I stared at him. I suspect I am somewhere on the spectrum. And it was a moment of clear revelation.

I spent the entire weekend thinking about this one conversation. A key benefit I had was that I had done a lot of acting, enjoyed D&D, and had an absurdly high executive function. And so I came on Monday morning and acted. I have a youtube video where I talk about this here.

What resonates with Ms. Nóva’s document is that she detaches herself from the reality of understanding why and accepts that things are and that she must devise rules on how to win based on that.

I lack her precision of English, wit, insight, and, to be quite frank, experience. And I wish, when I was 22, she had given me this document.

So who should read it? If you were not born in the United States, you were not a white CIS-gendered man, and you are not privileged, you should read this document.

The United States is an alien country. Its rules are strange. And its culture is derived from 300+ years of interaction between property rights, the evil belief that labor should be enslaved, that extreme Christian Dogmas are fundamental, and a sense of supreme righteousness and contempt.

For example, let’s consider ownership.

A year ago, I had an opportunity to talk to a Chinese woman, from mainland China. And she was talking about ownership and how she was struggling with her career because of that. And I realized she was talking about ownership in a way that sounded like a colorblind person talking about colors.

And then we talked about “what is ownership in the USA.” In the USA, ownership of property is a sacred right. When you own something, you own it. You can do whatever you want to it. And nobody can tell you otherwise. A considerable amount of the conflict in this country is putting boundaries on the ownership of people by others and the limits of ownership of common goods by individuals at the expense of the group. The idea that the country protected property rights from others and the government was eye-opening to her. Her life experience in Xi’s China and property rights was not that. And as we talked about ownership, she said – “oh, so that’s what ownership means.”


I love this country, and as a Greek from a village, a Canadian from Montreal surrounded by more small-town Greeks who fled Greece due to a civil war, a world war, and a junta, the culture of the United States and beliefs frequently leave me perplexed.

Hacking Capitalism is a guide to making this system work for you without understanding the why and just understanding its weak points.

Ubiquity and the ventilator and adding 15 years to everyone’s life

by Leave a Comment

My father is Prof. Charis Roussos. He’s currently 78 years old. And he’s a legendary figure.

To make Prof. Roussos’s impact tangible, let’s compare how set designers imagined the future of hospital medicine.

In 1966, the set designers of the sci-fi show Star Trek imagined the medlab of ~2254 looked like this.


The hospital was a single doctor with a digital chart.

But in 2009, the set designers for the film Star Trek imagined the medlab in 2233 looking like this.

Notice the ventilator, the machines surrounding the hospital bed? Prof. Roussos made them a necessary part of medicine.

But why did this ventilator become so ubiquitous in just 43 years?

Before his research, there was this thing called “shock.” Patients would enter “shock” and die. And the why was a mystery.

But its existence meant that a whole class of things we take for granted are impossible. Surgeries that could save your life but might lead to “shock” were very risky.

But was shock?

He and his teams proved that shock happened when blood pressure dropped.

Let me explain.

Typically you have a specific volume of oxygenated blood pumping through your body. We all know that the heart is a muscle, and we all know about the lungs, but what we didn’t realize was that there were some equally if not more essential muscles, “the lung muscles or the thoracic muscles.”

The body needs oxygen; otherwise, it dies. And without the lung muscles moving, you don’t breathe and die.

But for the lung muscles to move, they need oxygen as well.

Under normal conditions, this is not a problem. There is enough oxygen coming in and enough blood going around for everyone.

But when a patient is under distress, and there is less blood to go around, the brain needs to make some tradeoffs. Well, it can’t stop breathing, so it keeps the lungs working and starves everything else, including itself.

But how much blood do these lungs need? Well, about 25% of the total blood flow.

So what was shock – less blood being pumped through the heart meant less oxygenated blood for everyone, which meant that vital organs started to fail, which led to death. To deal with that, the brain then tells the lung muscles, “WORK HARDER,” and sends even more blood, and the lungs work harder, and vital organs get further starved. . Until they are exhausted, and the brain realize it can do nothing, gives up, and the patient dies.

Shocking.

These lung muscles were the key to keeping people alive!

But how to do that? Well, if the brain only cared about oxygen, what if we fed the patient oxygen or artificially moved the lungs?

And that’s where ventilators come in.

What if we used ventilators to move the lungs artificially, allowing more blood to flow to other parts of the body?

That simple idea saved people who would otherwise have died and enabled surgeries and procedures that in the past were too risky.

You can hear him talk about this here.

52 architecturalist papers: the different flavors of availability

by Leave a Comment

In a recent sequence of discussions on availability at work, I realized that there are different flavors.

But first, a history lesson.

Before virtualization became a thing, the physical data center physically existed. And its destruction, although possible, was extremely rare.

The destruction of an entire physical data center was extremely rare, and we referred to it as a “meteor strike or nuclear war.”

For practical purposes, availability was about dealing with physical component failures. For example, if a server had a disk, and the disk died, could the application on the server keep running?

As hardware components became increasingly resilient and the cost of hardware plummeted, the weak link became the software.

Because rearchitecting software to become intrinsically highly available was impossible, new software frameworks came into existence.

One of the most impressive was vSphere-HA because it said the following

  1. If you have highly available storage and enterprise storage was highly available
  2. If you have shared storage, and enterprise storage was shared
  3. And you capacity connected to that storage, all of your applications will restart after 5 minutes.

vSphere HA and its more boutique solutions more or less solved the availability problem.

And the power of vSphere-HA to systematically solve the HA problem across an entire application fleet greatly expanded the value of VMware’s technology value proposition.

Except, a new availability problem emerged.

In the past, a single software could not destroy a single data center or all data centers. The scope of the blast radius of an operator error was quite limited.

But with virtualized infrastructures and cloud infrastructure, a single button click can destroy an environment in minutes.

For example, at Zynga, an operator error caused by a lousy user-experience design deleted the production Cityville deployment. Cityville had over 10 million Daily Active Users (DAU) and 30 million Monthly Active Users (MAU).

Why was this possible?

Because in the past, you couldn’t delete a server, the applications in the server, the network connections associated with that server, and the data contained in those servers with a single button click in minutes because it would require logging into hundreds of systems. Why? Because the nature of the systems relied on multiple administrators of infrastructure coordinating to either provision or delete infrastructure.

Let’s use an analogy from social media. Before Facebook, I couldn’t share the news with millions of people using a few button clicks to use an analogy. I had to talk to a lot of people. And so, the blast radius of my news was quite limited. Facebook made it easier to share good information like I have a new child very quickly, and sad news like a friend died very quickly. It also made it possible to share fake news and lies very quickly as well. The same technology could be used to do both. And the societal damage of that rapid dissemination of phony information is confirmed.

Virtualization and later cloud moved the entire data center that the application depended on into a single database. The single database allowed agility to grow, shrink, and adjust infrastructure demand to meet the changing application demand. It also made this database the single most significant vulnerability to your environment.

And so software engineers rightfully focused on how to make that database available. But the problem is that no amount of software available can solve operator error, and worse, mistakes that destroy the database in its entirety.

As more and more effort was put into making the central system more robust and available, the overall design became more and more fragile.

But what kinds of errors? Remember, the physical data center rarely goes away in its entirety, but several servers? Those fail all of the time. Worse, as the servers become less available to become cheaper and more disposable because technologies like vSphere HA or cloud-native 12-factor application styles expand, their failure rate increases.

And this cheaper hardware that is more disposable is possible because of the very same centralized databases that when they fail destroy everything. Antifragility makes it clear that the more and more you make everything depend on a single system, the more and more the entire system becomes fragile.

So we have this peculiar phenomenon that the entire virtual infrastructure of the data center resides in a single piece of software that if it fails, everything is gone. And the thing that can cause it to fail is not under the control of software: things like Human error, or data corruptions in parts of the stack that are unknowable, or ransomware, etc.

Without any personal internal knowledge, the Facebook DNS debacle is a great example. The software allowed the network engineering team to make widespread infrastructure changes across Facebook in minutes. And human error combined with technology errors (just another word for human errors) resulted in the entire Facebook infrastructure is unavailable.

IT operators understand this point, as did DevOps teams and the SRE teams. And this is why they refrain from having a single system control their entire infrastructure. The scope of a single error is why those groups like to have more k8s clusters instead of one large one. Or why backup admins have backup software from a different vendor from their primary storage.

Centralizing things allows for unprecedented agility and failure.

What to do?

My take is threefold.

The first is that the era of centralized databases that control the entire infrastructure is closing. Instead, we will have many databases. In the k8s space, the idea of a few large k8s clusters is an anti-pattern. And this is why I am such a huge fan of products like Tanzu Mission Control. They line up with the future.

The second is that those centralized databases will have to be built leveraging blockchain systems that protect against byzantine errors and, in particular, human errors.

The third is that the ability to recover from those database errors in a timely fashion will become a critical differentiator. A once-in-a-decade event is terrible if it happens on a Friday and a company ending event on Black Friday. Software stacks that make that recovery quick and easy will win.

51 architecturalist papers: transactions and arrangements and architecture reviews

by Leave a Comment

One of the best program managers I have had the chance to work with observed that companies have challenges when transactional-based decision making and arrangement-based decisions come into conflict.

Transactional-based decision-making is what I call strict enumeration and documentation in the form of a contract. Once both sides agree on the document, then even if people change, the decision remains. The trust is in the record, and the change controls surrounding the document. This kind of decision depersonalizes the decision. These decisions tend to be transparent.

Arrangement-based decision-making relies on trust between the two parties. The parties establish trust in various ways, but typically it’s about making sure that the personal goals between both leaders align. Arrangements are remarkably durable and transportable. Meaning that once you establish an arrangement with someone, trust is the basis of subsequent decisions much faster. It also means that decisions without going through a complex process. The problem is that these decisions tend to be opaque.

Both models taken to extremes can be a disaster. I have worked in both. And they both suck.

The law is THE example of a transactional system. Overly transactional environments turn into bureaucratic, legalistic environments.

A pure transactional system can turn into a totalitarian state. A great example is – “the only way to change this spec is to call a meeting of the change control board and submit a request.”

A pure arrangement system can turn into a cult where belief in the great leader is paramount and the phrase “blah said” is used to justify or denounce everything. That disagreement with the great leader is an unforgivable sin. A great example of this is when someone says – “but SR ARCHITECT FOO said”. Or alternatively – an old-boys network – that is impenetrable.

I’ll also observe that both approaches feel natural to different people. My personal experience is being Greek and Canadian and living in the USA. As a Greek, I believe that laws are suggestions. That relationships, and in particular, family relationships, trump everything. As someone who lives in Sunnyvale, CA, I have learned that in the USA, laws matter, but that the laws are structured to satisfy arrangements among the wealthy.

A transactional system feels like a spectacular waste of time because personal relationships trump everything and that, ultimately, transactional systems are a facade for arrangements.

But I have learned that that is naive. The critical flaw of arrangements is the opacity of building trust and the boundaries of trust. Transactional-based decision-making creates a public record of the moment trust was built and describes the trust boundary. Without such a record, trust-building naturally devolves to family, culture, background, and other attributes.

This brings me to how I think about architecture reviews. The purpose of the review is to create a trust boundary between the approver and the author. The more high-level the spec, the more trust that has to exist. That trust is typically built over a series of smaller successes or previous professional successes. The more detailed the spec, the less trust that exists. A key trust moment as an architect is when you are willing to stop being the sole approver of an area.

The key illusion in all of this is that as an architect the spec actually defines what is built. The reality is that unless you are writing the software, some other human being is going to take that document and do what they think the right thing is. My job is to make sure that they are thinking about the problem in a way that aligns with a reasonable solution.

Decrying arrangements because they are old boys networks is wrong. Decrying transactional-based systems because Process is also wrong. Like most everything in life, there is a balance. And like most everything in life, navigating that balance is the art of living and being a software architect.