https://minnenratta.wordpress.com/feed

Believe it or not, I entirely skipped Facebook back in the day, because I was already on LinkedIn. LinkedIn seemed to me to be not only predating, but also to be much more poignant in its goal: maintain a network of colleagues, former colleagues and other professional acquaintances, anchored around an updated, public, sincere version of my CV. In contrast, Facebook seemed to offer an admittedly nifty UI, but attached to a “make your private life public” focus, that I didn’t understand. Honestly, when it came to Facebook’s value proposition, I was at “why would anyone want to do that” levels of incomprehension.

When I had another look at Facebook, a few years later (I had to create an account because I was testing one of their first iterations at SSO), I was still unconvinced of the value of moving my personal (as opposed to professional) life onto an endless public scroll. Still, I finally discovered one answer to that “why” question that had puzzled me: people would do it… to brag.

Social posturing, a very unsavoury, but very common activity in the history of mankind, had found its home online, on Facebook. So, I rolled my eyes and kept sticking to emails, chat rooms, and when I had to update my CV or keep in touch with an old colleague, LinkedIn.

You may find this very snobbish, but it’s just a useful approximation: I’m pretty sure that many a grandmother has used Facebook to share updates about her life with old friends and nephews, but, upon the whole, it was safe to assume that most people were using Facebook mostly to brag, most of the time.

This is all very ironic when I consider that, while I was holding my nose up at Facebook and other online brag arenas, LinkedIn was becoming the place where people would come to show off, professionally.

I spent years assuming that people would generally be truthful in what they publish on their LinkedIn profile, not because of some inherent honesty, but because it would be published to a network of peers, able, by definition, to spot any inflation or twisting of one’s accomplishments. After all, some of these people know what you did, and didn’t do, in that job.

It came as a sudden realisation for me that, not only would people not hesitate to fake and embiggen their worth, experience, and abilities in front of current and former colleagues, but that their network would just pick up the habit and play the same game, with gusto.

In hindsight, all of this simply illustrates my long-standing naïveté on the nature of human group dynamics. Absent incentives to the contrary, it is always easier for people to drop their standards and start trying to advantage themselves in the same way, rather than pushing the originator of the bad habit back to the original moral standard. Peer pressure is not a stable loop.

Shameless bragging was just the beginning though: probably because LinkedIn is a network supposedly for our professional side, the transition to the “Facebook of LinkedIn” created an opportunity for the manifestation of two other very laudable activities, which are strongly present in professional life: bullshitting and sycophancy.

These days I look at LinkedIn and I chuckle at my blindness. What I originally perceived as a dry, meritocratic place of professional connection, has become a place where it’s fine for your current authoritarian, and broadly incompetent boss, to pontificate on what distinguishes real leadership from, say, authoritarian management, and where it is fine (and maybe expected?) for you to compliment your boss on their excellency at that “real leadership” thing. You also do it in plain sight of your current and former colleagues, whom, instead of scorning your behaviour, will fall upon themselves to one-up you in the praise of the dear leader.

I think it was enough when strangers asked me to connect for no reason, and young, beautiful, inexistent sales/recruiters sent me private messages about how struck they were by my profile and/or the company I worked for; while the posturing and boot licking mostly happened out of my sight, in private, or, at worst, in meetings. Now, instead, we have the digital version of life at the court of Louis XIV, the Sun King.

Finally I’m wrapping up, but first I want to have a look at those who actually gain from the current state of the complicated Internet.

---

The winners

So, cui prodest?

When humans add arbitrary complexity to the world, the beneficiaries tend to be those who specialise in dealing with man-made complexity: a long time ago it was high priests of the deities we dreamt up, to give meaning to the world, then it was various bureaucracies, plus notarial institutions, international law firms, consulting companies, and of course any market’s big incumbents. Some of these accrued power, others money, and a few got both.

The balkanisation of the Internet seems to be benefiting the same actors that benefited from the previous complications : bureaucracies, notarial institutions, law firms, consulting companies, and big incumbents.

This time around though, there’s one extra benefit for national authorities. The “old style” internet, the internet of global protocols, publicly documented after months or years of competition and more-or-less sane discussion among meganerds, was remarkably insulated from political powers: “You don’t like our service dear head of state? Ok, we will just move to another datacenter, but don’t worry, your nation’s population will not even notice we have moved. In fact… wait a moment.. done”. The new landscape instead, where a company’s online presence in a given country is pinned on a lot of country-specific logic and often country-dedicated infrastructure located on that country’s land, is vulnerable to the same pressures that a state can apply on a factory, or an ore mine, including of course the possibility of officers marching into a datacenter and seizing data, in some instances unique, untransferable personal data.

Frankly, the only return that I can construe as positive, for the general population, is a reduction of the winner-take-all dynamic of the global Internet market of a decade ago. Still, the systemic benefit has mostly accrued to the totalitarian and original version of the trend, the Chinese version. A scenario where Amazon gets out-competed in a European country because a local competitor can do something Amazon cannot, thanks to, say, GDPR, doesn’t seem likely. I don’t think (and I really hope not) that western democracies are on the path to China-like state-controlled nation-nets, so I don’t expect the balkanisation to create isolated technological ecosystems, but maybe some business software vendors will be able to play the regional card in the domain of security and regulation savviness, to win some contract that would have otherwise gone to a global market leader. So, there’s your silver lining, if you will.

Still, even that positive side, probably best exemplified by the multiplication of regional, national, or even local payment methods, shows a kernel of what we lost since the time of the flat world: those players that manage to succeed in the payments arena, slicing away important market chunks from the credit-card incumbent, do so within national borders, and mostly fail (or not even attempt) to scale beyond those borders. While the feature set of new payment methods is remarkable, none has yet replicated the decades-old achievement of worldwide accepted credit cards.

It’s fair to ask if AliPay would ever have existed without the balkanisation, but that same phenomenon has made it (and most other new payments) much less amenable to adoption by non-Chinese financial institutions, by design.

Am I being a hypocrite? Haven’t I profited from this extra complexity in my profession? I estimate that between 20% and 40% of my time in the last ten years has been spent addressing a complication directly or indirectly born of territorial concerns mapped on the Internet. In my profession this probably puts me on the lower end of time allotment: I’ve been both lucky and careful in minimising the time spent on those topics, it could have been much more, I must thank many colleagues who often acted as the initial line of analysis while I was absorbing the distilled information to come back with a solution. Still, I would happily trade that for work on topics that could actually benefit users. There’s really no lack of those.

The end

Maybe this whole arc is just another way to tell the story of a relatively homogeneous “1st world” under the American hegemony dissolving and then re-coagulating into sharper and smaller regional spheres of influence. Technology being only one of the many things being influenced.

Or maybe this is just a long coming-of-age story: the Internet, a young, simple, idealist rebel, with great potential, starts interacting with the rest of the world, and the world brings all the compromises, complications and nuance it’s known for, until that rebel becomes a full, respectable member of society. Everything comes with strings attached.

Yet, in an alternate reality, that young idealist rebel could also have acted as a model, a model on how to use engineering and maths to smoothen the pointless inequalities built into the physical world. This is my belief because, if you look under the hood, what is keeping us safe, to this very day reducing the likelihood of leaks and fraud, what is empowering individuals and stimulating the best competition, what is providing the infinite commodity and opportunity of online services, is good computer science. Nothing else.

I have a hard time, even at my most compassionate, to frame the rest as anything more than well-intentioned entropy.

In the previous chapters, I described how the initial abstract, decentralised, standards-based internet born in the anglosphere and mostly detached from geographical constraints, has evolved (devolved) into something much less homogeneous to build and operate. Here begins the wrap up.

---

Outcomes

But isn’t all this complication just the cost to pay for the proper enforcement of individuals’ legal rights and the protection of their data in a previously untamed digital frontier?

First, that cost is huge, especially the opportunity cost. I’m not sure if I managed to describe the magnitude of missed opportunities properly.

I’ll try again.

Maybe we can begin to picture what we missed by having a look at what the Chinese user experience of WeChat is, with its fully integrated communication+social+payments+identity solution, and then try, with our imagination, to project it upwards and outwards, at a worldwide scale, with world-class talent working on it, in a non-authoritarian context (so that the integration doesn’t automatically smell of state control), with multiple companies competing in the same, simple playground for providing the absolute best experience to users. Something so fluid that puts the search+browse+register+finally-get-the-service paradigm where mobile apps put physically going to the train station desk to for a ticket: in the something-went-wrong niche.

That vision can be more or less detailed, more or less utopian, and more or less enticing to your taste, but it should provide a stark contrast to what we got instead. Rather than new levels of seamless service integration, we largely have the same online experience today that we had over ten years ago, and in some aspects, it is actually much worse! Fancy clicking on a cookie banner, or twenty, today? Finding much relevance in the first page of Google search results of late?

Second, the return for paying this enormous cost is unclear: is the balkanisation of the internet really shielding us from abuse? Giving us more control over our data? Avoiding leaks? Is it pushing companies to create more locally-conscious online products?

Security-wise, any bad actor can walk right through country-of-origin-based filters by using a VPN at near-zero cost, and I’ve yet to see a case where country-related laws have increased the actual security of a decently built system (but they do provide enough security theatre to make non-technical people feel safer). In some rare cases I’ve seen very weak systems being forced to upgrade, and get to a standard level of security; even then, the relevant rules that pushed the improvements were not those that territorialize and complicate the landscape. Parts of China’s critical systems robustness law come to mind, and while they can be considered another political pressure tool, they are also a mostly sensible ruleset for robust systems anywhere. As usual, sound IT security practices are mostly unconcerned with physical world geography.

I would argue that the best way to secure data is to have a simple policy, defined with mathematical crispness, carefully implemented in a single, well-replicated system, bonus points if open-source. That doesn’t allow a random politician to inject what they think is “common sense”, but it’s certainly more secure than going for continuous duplications, filters and exports to store the data in multiple different systems, each playing Scrabble with various chunks of logic to match the law-du-jour.

The Internet, and in general modern computing, is an environment where the only decent security is point-to-point, there are no good or bad neighbourhoods to pass through. Your machine has to be individually secure, if it’s not, then it’s probably already hosting a keylogger, and if you are not using encryption for your interactions, you are in trouble, even if you are talking with a machine on the other side of the street. The good news is that most of this has become the out-of-the-box setup of any modern computing device, from phones to desktops.

On the other hand, projecting political boundaries onto the Internet gives a false perception of safety in “local” interactions. When an office server is “secured” by closing access to calls coming from other countries, someone in that office is mistakenly thinking that geography actually matters.

Unfortunately, it matters only to lawmakers and companies that don’t want to get fined 2% of their annual revenue.

An attacker has multiple, easy ways to perform calls from any geographical area. For people only moderately tech-savvy it’s actually easier to bypass a service’s geo restrictions than it is to send an email to their company’s system administrator and ask them to whitelist Greece during their Greek work-vacation. These days, scattering and multiplying the source of an attack is the baseline of even the most casual malicious actor on the Internet (and, yes, they would be doing it regardless of geo restrictions).

The last time, and frankly almost all other times I had the privilege to defend against an attack, the calls were coming from almost every country you care to name (including China, but excluding North Korea, so now you know where to you can have a safe audience via geo restrictions); and this was not some secret agency or moustache-twirling industrial competitor, it was very likely an amateur in a garage who had some fraction of bitcoin to waste on a botnet, and they only managed to ruin the weekend to me and my SecOps team.

In the previous chapter I described how ultimately China not only succeeded in isolating its population from mainstream internet, but, by doing so, it created a whole different technological ecosystem, with broad impacts on large international companies. Now we get to the core of the matter, the current state.

---

Borders multiply

Ok, so now we have to deal with exploded complexity if we are doing Internet-stuff without ignoring China. It’s not the end of the world. Can we get back to worrying about plastic in the oceans now?

Unfortunately, the phenomenon seems to be replicating itself, more or less in slow-motion, in multiple countries. There have been many attempts to regulate the Internet, from governments attacking peer-to-peer (on behalf of artists and the entertainment industry), to the Trump-era abandonment of the principle of Internet neutrality (on behalf of the big telecoms), but I see Russia as the real second-mover on this.

Russia has done it in a very subtle way: many years ago it introduced a law that requires personal information collected online to be stored in a Russian (i.e. located on Russian ground) datacenter first, and only later “exported” to a non-Russia-located system (by the way, there are a few fun facts about encryption and security in Russia, but let’s not go there now). This means that when, disgracefully, my Russia-serving website is asking for your first name at registration (if only to show a nice “Welcome Evelyne” at log-in), that data needs to be stored first in Russia. Should we implement a multi-step personal data storage architecture where, under certain conditions, for some users, we first store it in a (hopefully useless) database in Russia?

Are we sure we understand those conditions? Architecturally, it is also much simpler to just bounce everyone’s personal data into a Russian database. While it would result in a simpler solution, you can imagine how this would become a PR bomb for any major brand.

As a matter of fact, these days, that approach would not just be a PR bomb, it would be a serious legal liability: multiple other countries have since enacted similar laws about the storage and “export” of personal information. Very democratic countries this time.

I see the Russian approach to territorialising the Internet via personal data regulation as a kind of evolutionary viral adaptation of the Chinese idea of creating a separate state-controlled Internet: the Great Firewall would not take hold in a modern democracy, but raising concerns about personal information being moved around… that’s something that resonates much better with the “guarantee personal rights” ethos of democracies.

In the last decade Western-style democracies have reached a paroxysm of concerns around data privacy: your first name and last name, or, dear me, your address of residence, stored in a secured database, could be discovered by a third party, and then… then what? I’m not waving off doxxing, but for some reason, these days, we are supposed to worry about the privacy of our name in the same way we worry about protecting our clinical data, or passwords, or our latest jewellery purchase (I learnt that that can be a life-impacting secret to some people).

For perspective, consider that back when phone directories existed (they still exist, but you get my meaning), unless you were in a witness protection program, or you were a celebrity, a head of state, or a tinfoil cap weirdo who didn’t want to show up in the directory, I could find your full name, phone number and address starting from only one of these, or just pick some random person and mail them an offer for a yearly subscription to Horses and Hounds. A leaflet is most certainly coming for you, Sir Ryder Stead, Equine Hall, 1 Meadowlane.

I didn’t need the tools and the years of learning required to hack a protected database, I just had to browse this big book, which, for my city’s entries, was conveniently sitting in my home, and in every home, and every café, and train station, and most phone booths.

Reading from it was a metaphor used to describe an exceedingly boring read, wasn’t it? It was such an anodyne piece of data, that one of the most ubiquitous scenes in movies was the protagonist walking into a café, looking up someone’s address in the phone directory, ripping the whole page out, and often proceeding to show the ripped page to the café owner asking for directions to that address.

I don’t remember anyone in the audience crying out in outrage for the blatant disregard of personal information protection. It is so unremarkable that I couldn’t easily find an excerpt on YouTube, so you get a Fandom page. If anything, the one shocking detail was how the owner was perfectly fine with some guy vandalising their phone book.

If we compare that long-lost reality with today’s privacy obsession, it’s obvious that enriching privacy protection laws with a little extra clause such as “and the personal data must reside in this country and not another” is a pretty minor change in the eyes of today’s public opinion.

That minor shift, though, has major architectural implications: all of a sudden, for each interaction that contains personal information (which, by some laws, is pretty broad and at times maliciously ambiguous), we have to consider where the person is connecting from, what’s their nationality, what’s the nationality of the account they logged in with, if any, where they want a service or good delivered, where our hq is located, what is the relevant regional subsidiary, if any, plus plenty of other variables that could only have been dreamt up by a legislator who thinks that the Internet is in another floppy disk.

This is just to determine which data protection law is applicable of course, then we need to implement, and maintain all the logic for storing, processing and moving the data to a data centre in the right country, for the right duration, for a given law. If you think that just applying the strictest combination of all the “protections” is a viable approach, just picture the size of the design space that natively respects the California+Kremlin+Brexit+Bruxelles intersection. My current guess is that that space is a single button changing colour when you click it, storing nothing; and that only until we address accessibility concerns, of course.

Unless. Unless of course, you build your solution for one country only, forking or directly reimplementing your customer-related systems for each new country you need to cover, and never try to merge the data of the same person across borders.

It doesn’t help that the fines for breaching some of these laws are now increasingly defined as “up to a maximum of X% of the annual company revenues”, which means that already pretty risk-averse corporate legal offices go straight into overdrive, drafting legal-IT policies that would require a university department’s worth of research just to confirm if they are internally consistent. We are fast getting to the point where a thousand e-commerce accounts leak is more of an existential risk to a company than a petrol tanker leak.

Many years ago, I was working in a big company with sales across the world, and a rich customer database. One of the most entrenched limitations of its otherwise pretty decent architecture, was that customers had a separate id and profile per country, stored in separate machines. This was not due to some explicit purpose, it was just the best that one of the oldest systems composing the landscape could do. We fought with that complexity every day, plans to solve the problem and unify profiles never moved forward, and people who had accounts in more than one country still had (and still have) a shameful experience. But what was back then a stupid, user-experience-impacting architectural mistake, these days is increasingly a requirement, and thus that technological limitation from more than 20 years ago is now a feature, an asset. Picture that for progress.

All of this means that, whenever there’s a human on the other side of the interaction (and that’s still pretty common nowadays, even if some of the humans seem to be acting more and more like bots), the Internet is no longer homogeneous: clusters of territorialized systems sketch stronger and stronger geo-political borders onto a previously smooth landscape. These borders are very hard to cross, like impossibly high mountain ranges, their ruggedness a function of politics, messy software architecture, and terrified legal counsels.

It’s important to remark that we have always had axes of segmentation proper to the online world, almost since its big bang moment, silently exploding through 28.8 kbauds modems. After all, capturing chunks of the free-floating online universe born of the html+network+email quantum soup is the big-game hunting of the 21st century: device-specific development environments and marketplaces, bundled browsers, telecommunication companies bloatware in smartphones, and more.

Until recently though, this competitive game was happening on the backdrop of a mostly open market, from one end of the planet to the other, and it tended to go through cycles of divergence and convergence, with islands of incompatibility having to win over the planet, or merge back, or disappear.

I don’t know if market and technological forces can continuously re-converge to decent global standards, despite the compounded complexity of competitive user-base grabbing and political force projection from around the physical world.

This is the second part of the long text (I don’t dare to call it an essay) that I wrote on the progressive segmentation of our initially unified Internet. In the previous chapters I covered those early, very unified (and also very Anglo-American) days, now the first border appears…

---

The first border

You see, from a software professional point of view, the fact that some pages are not accessible from inside China is not really a game changer: so what, I have to deploy my content and logic into an identical node hosted in China? Fine, that’s what infrastructure automation is for, I’m already doing this in multiple continents just to get a 10% page performance improvement.

On the other hand, this becomes a whole different matter if the people of China are using a completely different platform, running on different cloud systems that only superficially resemble those of Amazon Web Services. It means that to get the same or similar results I have produced on the Internet of the non-Chinese world, I have to re-implement all of my logic on Chinese-specific systems. This is like the integration of the Italian fiscal printers, or Japanese delivery addresses, except that in this case the whole business logic, the whole code base, is the fiscal printer. You are not dealing any longer with specificities at the edges, you are rebuilding the same solution in a different technological environment.

This might look like just one more expense line in the already gargantuan list of expenses of a multinational company, but complexity is not a line. Complexity is non-linear: creating and running two solutions does not cost twice as much as creating and running one solution. For instance, Conway’s law alone multiplies the costs beyond those of creating the system itself, because those two systems will beget two parallel organisations, increasing the organisational complexity of the company itself. Having multiple tech organisations, doing very similar, but not identical, things, is always a very painful puzzle; a puzzle that every middle manager, and many would-be top managers, have a vested interest in not solving. Richemont & YNAP come to very recent memory, but there is no lack of examples of death-by-organisational-complication, in the roller-coaster of amazing successes and tragic disasters that is the history of software. Moreover, cases like Microsoft & Skype or Oracle & Sun are well-known because they are the result of big acquisitions in the public eye, but for each of those, ten others are very internal, very private, and still very ugly.

All of this does not even include the technical complexity itself: the complexity induced by the need to have two technological landscapes interact, in our case, the Global one and the Chinese one. Also, did I mention that most of the Chinese technological stack is documented in Chinese, with code written in a mix of English and Chinese? Just to give an idea of the technical complexity: SalesForce was struggling to deploy a really solid China-local CRM solution with good global integration. For years.

As long as we were just dealing with a subset of the users of the Internet having some pain accessing some content, the landscape was still flat: your favourite online newspaper could still use your identity, that was provided via, say, your Facebook login, at minimal integration cost for the newspaper. But once the platforms and infrastructure start to diverge, we are creating a new dimension altogether, one that is similar but phase-shifted from the original Internet. You can picture it as another plane, resting at an angle and intersecting the original internet dimension along an infinite line, a boundless mirror interface. When your identity is managed in WeChat, your favourite newspaper has few options other than reimplementing itself within the WeChat ecosystem, using a WeChat-approved integrator, with WeChat-supported subscription payments; as for ensuring that the links in the newspaper’s articles work, well, let’s say it’s not something that can fit in a sentence, and I’m not completely up to date about the WeChat link policy, but that’s already proving my point: there is a WeChat link policy, and a changing one at that.

The beginnings

Once upon a time, there was a network of computers spanning the whole world, where each computer could connect following the most effective route, without having to worry about physical, political, or technological barriers.

A computer on that network could decide to host an email service and emit its email addresses, or expose a file-transfer protocol port and act as a source of data to any other computer, not to mention, of course, serving a very special kind of files: html files. Running a web server back then was a matter of reading a page of documentation, installing it on your own computer, getting a domain, for a few dollars, and adding it to Yahoo and AltaVista.

After Google came around, people even managed to find you without having to drill down through seven layers of categories and subcategories! It was glorious.

But this is not about the DIY ethos of early internet publishing, it’s about the experience of consuming its results. I remember, as a teenager, the surprise of stumbling into the, very public, CIA country directory, with a brief data sheet of each country, including population, main resources, important religions, and of course geopolitical considerations about current political figures. There was nothing there that you couldn’t read in a diplomacy magazine, but still, I was amazed that, from Europe, I was reading documents edited and served by a US intelligence agency. Moreover, I was doing this just after spending two hours reading a sci-fi collaborative fiction, with hundreds of pages, plus illustrations, from dozens of authors and artists (yes, I was that kind of teenager).

It was an odd feeling, it was as if the world had become suddenly flat, and everyone could see each other directly, over an infinite horizon. Granted, the flat land was mostly populated by nerds with a flair for heavily textured backgrounds and baroque fonts, but, if one ignored all those cat animations, it felt like a brand-new dimension. A dimension where apparently everyone was expected to be able to read English.

The process that defined that new dimension was staffed by individuals who spent inordinate amounts of time writing monospaced walls of text, mostly defining communication protocols, and then fought over them in bulletin boards and conferences with all the passive aggression and snarkiness that you can expect from spirited academic discussions (you can approximate that community to the IETF for simplicity, even if it was quite a bit broader even back then), and, as imperfect as that process was, it succeeded in creating something eminently working, and working the same regardless of location or jurisdiction.

Commerce

Then things became much more commercial, and most of the cats and quirky fonts disappeared, or rather, they were swamped by the growing presence of real-world businesses that were discovering the beauty of the infinite horizon: in the flat dimension, the billboards could be seen from everywhere!

I joined the crowd of makers of e-commerce a couple of years after that trend took off, and by then the focus was delivery. Payments were already very much part of the flat dimension; we can complain as much as we want about the likes of Visa, but by the time the Internet had become an embryonic commercial space, credit-card companies had already brought payments into the fold of flat, everywhere-is-here space. In fact, the “addressable market” was usually defined as those places where people could get a Visa from their bank. The rest was a rounding error.

Thus, delivery, not in any artistic or engineering sense: actual physical delivery of physical goods in physical hands. The billboards were visible everywhere equally, they had grown bidirectional too, you could talk with those billboards, you could talk in dollars, and the businesses behind the billboards were listening; so many people wanted their stuff, but those people were behind borders, customs, oceans!

While the internet was growing from using six different colors on a single line of text to wikipedia-as-the-sum-of-all-knowledge and massively multiplayer games, the physical world had not changed, it still had plenty of barriers, both of the rocky and of the paper-pushing variety.

An interface had appeared, between the Internet dimension, with its single unified landscape, and the physical world with all its divisions and division-bred complications. The interface was messy, but it was pretty much a sealed interface: the earth-born complications were not impacting the part of the universe that had originally moved to the Internet and was not physical to begin with.

I don’t want to underplay the complexity of the interface with the physical world. It was, and it still is, a maelstrom of buggy lines of code; a very expensive or, if you are a software services company, a very lucrative maelstrom. Whole companies have disappeared fighting that maelstrom, never to be seen again. Anyone who had to integrate with Italian fiscal printers, or calculate Brazilian taxes, from a generic global system, knows what I’m talking about.

Yet it was just an interface, one specific area of the flat dimension where it had to worm-hole back into the physical dimensions. All the rest, the ability to show the billboards, to communicate, to subscribe, to pay, and to link all of this together, didn’t have to deal with anything except the one Internet. Circa 2010.

By then China had already spent a few years investing in the Great Firewall, but its impact only became relevant when the combination of the Great Firewall, and China’s rising tech prowess triggered the great platform split. Thus, arguably in the second decade of the new millennium.

---

I’ll stop here for today. This is just the first chunk of a long text I wrote almost one year ago. I’ll publish the next chapters in the next few days and weeks.

A manager left the company, either because their boss fired them, or because the manager decided to change (note to self, I should write something dedicated to the effects of management volatility).

Recruiting the new manager was an intense effort (we hope at least!) and the team has been more-or-less-officially leaderless for a while. Everyone is looking forward to the new manager’s arrival.

You are the new manager. How much of the previous setup do you leave unaltered, and how much instead you change. When do you make those changes, if any?

Looking around the team, especially upwards and outwards, you notice a few things :
– Lately the team has been under-represented in coordination meetings, and thus is seen as opaque, and possibly struggling to keep up.
– Your boss has been selling your arrival to their boss(es) as great news. After all, you are the positive spin on the bad news of your predecessor’s departure, and some of her bosses were in turn involved in your recruitment. They all have a stake.
– The culture in the company is that a manager’s main duty is to set up their team for success, but a lot of the team success is measured through reports, which, of course, have been lacking or less-than-engrossing lately. So the general assumption is that the team has “room for improvement”.

Looking at yourself, you also can state the following :
– The team setup is a bit different from what you are used to, and thus what you consider optimal for yourself. You’ll need to change some of your habits, to support the team properly in their current setup and ways of working, or else change the team and processes to suit your own.
– You moved from a previous company which was alright, and you were given a pretty good package to jump. You don’t know how it’s placed compared to your peers, but HR during negotiations was clear that they were making quite an effort, which might or might not be true.

Finally, looking at the team you see :
– The team is distressed. Maybe because the old boss was bad, or because it was a pretty good boss, and they are worried you’ll be worse. Maybe because there was a person within the team hoping to get the promotion, to whom the others may or may not look up as kind of the unofficial authority in the team. Regardless of the specific reason, it’s rare that a change of team management leaves the team in question placid.
– The team is aware that they are not well perceived by the other teams and hierarchy, but they are unsure why. Some team members have more specific opinions, but in general they too subscribe to the general company culture that, whatever the reason, it is likely related to how the team was and is managed.

All the arrows point in the same direction: you better do something, more specifically, change something. The sooner, the better.

Why sooner rather than later?

You see, there’s this thing in human nature where, as soon as you are in charge of something (say, a team), whatever happens is increasingly likely to be seen as your fault/merit. Large groups of people are really not good at causality. This means you have nothing to gain, personally, in not changing things.
At the same time, changing your mind, changing something that you have set up yourself (or implicitly sanctioned by keeping it in place for a while after you joined), still carries a stigma, despite all the talking around the right to make mistakes.
The stakes of “reassessing the status quo” will never be as low as when you are just starting. You can also expect the resistance to those changes to be low : you have the newcomer’s advantage of being able to (almost expected to) march in with requests that allow you to “do your job correctly”.

Now, it’s true that changing everything on your second day on the job is unlikely (these days) to be met with approval. You are supposed to observe before acting. Mind you, it was not always so, we must probably thank Toyota and others for at least clearing the fact that no, not every team and job is the same, and that a “professional manager” can’t just bring-in the universal best practices of management and apply them strictly.
Nowadays, you need to at least display a certain amount of discovery effort before applying your recipe, even if it was printed crystal clear in your head since day 0, or even before.

Anyway, that observation period is supposed to be shorter than your probation period. Quite a bit shorter in fact. The whole context is set up so that your perceived value as a newcomer is massively a function of the number of team adjustments you’ll make, the more the better. Besides, your boss needs something to write in the end-of-probation-period report. They can’t just write: “She seems to be learning the context well”. So, don’t dally.

Luckily for you, all of these aligned incentives mean that you just have to introduce changes that go in the direction of what is expected from a manager in the most basic sense. Unless you go for something unusual, once you apply some changes, most judgements on results will be postponed by many months in the future, and it’s likely not going to be very factual either.

In the most basic sense, management is perceived as organising and running. Still staying basic: good organising is supposed to bring clarity through structure, and good running is good reporting.

So, what do you do? You let a few weeks go by, then you add some roles, redefine others, open a position or two, and then focus on your next report (the second is more important than the first). Heavens-forbid that it contains some bad news (as opposed to the bad situation you inherited).

Unfortunately for the company though, a complex, organic system has plenty of non-linear behaviours, plenty of hidden equilibria that make the whole work, and every time you change things with little understanding of those non-linearities and feedback loops, you are introducing a lot of confusion. The first to suffer is generally focus on results, because people subjected to even peripheral change will refocus on assessing the implications of the change and re-learning the organisation around them.

The real damage, though, is dealt by the new (extra) structure, and the new (extra) roles. That’s complexity injected into the organisation by the least knowledgeable person (you, soon after you joined), and for feeble, mostly self-serving, reasons.

Both the accrued complexity and the instability are generally discounted, or completely ignored (and selfishly ignorable). At the same time, all the incentives push you in the wrong direction.

Until the context is changed, and the incentives realigned, the first 100 days are when a manager will be most tempted, and with the least personal risk, to self-serve at the company’s expense.

Interestingly, for an individual contributor (I hate this jargon so much, I need to find a better name for it), I feel that the first 100 days are set up exactly the other way around. Perhaps managers should be managed like individual contributors, with the same expectations and culture around their early days? Is it even possible? I don’t know, but those few companies that mandate, whatever your role, that you shut up for the first few months of your tenure, and just observe, are probably not very wrong.

Immutability will solve all our problems, but only if it’s applied perfectly everywhere.

Mock everything.

Microservices, the more, the smaller, the better.

Advice that can be applied with little understanding of the problem rarely has good results, but it provides short-term satisfaction, a feeling of safety and, thanks to the ease of application, a delusion of speed.

You find a rule that is easy to apply everywhere, without any attached “it depends” clauses, a rule that you can just throw at the problem without doubt or surprise, in other words a rule that allows you to stop thinking, and you run with it. Until, at times years later, you look around and you discover you made a mess.

I’ve dozens of examples of rules that people are expected (and enjoy) to apply mechanically. Picking one group to use as exemplar is difficult, but I think naming patterns should do.

In programming we often have to give names to things. In software we create things very easily, and thus we do it all the time, I love it, but it’s a mixed blessing. It’s a bit like being a too-powerful-for-your-own-good wizard, who wonders what name to give to yet another eldritch entity he materialised with a flicker of his fingers. Is it a physical object? Is it a concept? Is it something that exists already, but you can’t recognise in its current aspect? Or is that similarity only superficial and you should resist the temptation to use the same name as before? And so on.

In short, giving good names is hard; which means that it is easy to give in and use naming patterns.

Once a developer starts using naming patterns they think less and less about the right name for what they are looking at. It could start with things that were legitimately difficult to name (and maybe should not have existed in the first place), but soon even entities that would be relatively easy to name become instant word salads of generic platitudes. Many a thermostat, pro-rata invoice, or window handle have been born as HeatingManagerImpl, ContractDataDto, or IUserInterfaceStrategyManager, without a second thought, nor a second chance.

Turning off the brain while coding is easily mistaken for effectiveness. I’ve even had people complain of the lack of a “naming convention” because “without it, giving names is hard”. My dear, finding good names is supposed to be hard, and I’ll be damned if I give you an excuse to shift to sloppy names under the pretence of standardisation. Take responsibility and call it “Foo#13”, at least the problem will not hide under a coating of glutinous prefixes and postfixes.

This does not mean that there is no useful guidance about giving names, there’s plenty, and here’s some, just to get a feeling :

• Use simpler, more abstract names for high-level concepts, and more specific, possibly longer, composed names for specific implementations of those abstract concepts.
• Minimise specialistic jargon, but use names that are meaningful and used by the people who work in the domain you are addressing.
• Avoid using synonyms for different concepts, and conversely avoid using different words for the same concept.
• If, after a lot of effort, you still can’t find a good name, do wonder if perhaps you created a weak construct that has no significance and review your design.

Again, these are just examples, far from exhaustive, but they are all providing guidance that will be unlikely to push you into mechanical, rapid, unthinking naming.

Notice that none of the points above make it easier for you to find a name, if anything they make it harder, because they stop you from picking a bad name, while they don’t answer the question “what is the name of this thing?”. That’s still for you to answer, and now you also should avoid some common mistakes.

This is often the defining feature of virtuous guidance: to add constraints that avoid common pitfalls, pushing you towards a harder, truer, path. Without feeding you a solution. It’s a feature of valuable practices and disciplines that has become more visible and noticeable to me over the years. Tdd, for instance, is almost entirely a constraints machine.

The complementary observation goes well beyond rules, to me it has become a ubiquitous heuristic of knowledge-based activities, from software design to organisational thinking, from product strategy to staffing: if it’s setting you on autopilot, it’s likely a bad idea/rule/choice/design/professional stance/mindset.

For simplicity, I’ll call these things that set you on autopilot “fudge”. Because fudge is sweet on the short term and lethal on the long term, because fudging one decision after another is often the result, and finally because “fudge” has a tradition for being used in software engineering talk. I really hope I got my naming right! We will see.

I can easily bring this to the space of development methodologies : every “agile” framework that highlights a recipe is doing a huge disservice to its practitioners. Instead of solving for “x” using all their skill and knowledge in agile principles and practices, where “x” is their context, they apply answer “42” to “x” and then, if they are still awake, they rediscover their skills and knowledge as they try to make “42” work. By the way, that’s the least negative outcome: very often there’s no skill rediscovery, no return to principles-based thinking. As the pace increases (because, hey, that agile transformation has yet to produce results), the tempo is tolerable only if the next organisational decisions are taken with machine-like speed, applying more recipes.

Principles (and careful thinking about problems) die in the race for the next recipe.

So, what I am saying is that the rule is “never apply rules that provide a solution”?

No, because that is itself a rule that provides a solution, it will have you stop thinking, because it is yet another fudge rule. If you try that, reality will once more provide a cold shower to your little, homogeneous set of automated decisions. For instance, you’ll find that trying to work out everything from first principles is too resource intensive, and it doesn’t provide enough structure for large scale collaboration. If you manage to break free from that rule’s spell, you’ll probably decide that you need some quick, problem-solving solutions, some hard and fast structures in your organisation, some basic practices that you won’t reconsider every other day, to free time to use good, hard, practices and disciplines on the creative, deep knowledge-based work.

So the rule is “Think! Find good rules that improve your decision-making, but no rule will ever think for you. Be wary of those that would have you believe otherwise”.

Just enough

The distinction between fudge and non-fudge contains another dimension : even non-fudge practices can be used blindly, especially when you crave that misleading feeling of safety and productivity. For instance, many tdd users picked up the practice with the expectation of not having to know design, because tdd would supposedly design the software for them. Tdd done well will accentuate and accelerate the pains induced by design mistakes, giving you more and earlier opportunities to improve your design, but to improve your design you’ll still need to know, and, more than knowing, to feel, where the breeze of a good solution is breathing from.

One way I model this is with the metaphor of spectra of idea application. Whenever there’s a rule/state/practice/idea, we can identify its opposite, and thus we are defining a spectrum. It’s for me an established fact that even the most virtuous idea turns out to be a horrible liability when you go 100% one way or another of the spectrum. Doing 100% something entails applying it blindly. A very good idea can certainly yield good outcomes for a while when applied blindly, but it’s a very fragile situation. The lack of thought entailed by the 100% application means driving without sensory input and without a feedback loop: it will eventually derail into disaster.

This is what I call the emptiness at the extremes: the lack of good outcomes, the lack of conscious thought, and ultimately the lack of humanity, that is to be found at the extremes of the application of any idea, no matter how good (or bad) it is.

For instance, if I put team empowerment in relation with top-down decision making, I will find at one end the rule “the team has the final say on everything” and on the other end I’ll have “the team does what it is told to do”. I am a huge proponent of team empowerment, but I think that establishing as absolute rule that a team decision will never be overridden introduces a fragility around situations where, for instance, the team starts a self-destructive cycle, or where the team is simply not mature enough.

We need to have just enough top-down decision making to safe-guard against those rare corner cases (presuming that the organisation is doing its job of growing generally mature teams, otherwise those corner cases are not rare at all). That little bit : “just enough”, makes the system centred on team empowerment stable: without actually removing any empowerment it keeps the organisation alert, rather than an automaton repeating a mantra.

Within that “just enough” lies the skill, the ability to think based on principles, the deep knowledge and multivariate model pruning at which trained humans excel. All those elements are required to move out of fudgey-rule-application and into wisdom. They are a hook that allows the complexity of the outside world to seep into the originally “pure”, mechanically applicable, idea, and thus make it worthwhile.

Since the difference between the presence and the absence of the “just enough” clause is the difference between the presence and absence of thought, between idiocy and self-adjustment, and thus between long term disaster and potential flourishing, it would seem that all the value, once the main good idea is found, is coming from that messy hook into the complexity of human skills and context.

I believe the irreducibility of complex systems explains why the lack of a just enough clause is a recipe for instability and disaster for any effort related to knowledge-based work. Still, I would like to describe my own theory for why it is so, from a more evolutionary angle.

Why should it be so? Why we can’t just blindly apply rules?

Why are we doomed to choose between the guaranteed eventual failure brought by clear, thought-sterilising fudge rules and messy, still at least potentially wrong, hard to explain disciplines?

Because, I believe, knowledge-based work is defined by difference : it’s the space where we have not yet developed a mechanical strategy for good results. As soon as a problem is solved, especially in software, where instantiating a library that solves that problem is a matter of instants, that problem does not belong anymore to our field, it belongs to the background, to the scaffolding of civilisation.

This has put evolutionary pressure on all the remaining problems : in order for a problem to persist, and thus catch your attention as a knowledge worker (i.e. you have not solved it with a google search, a chat with GPT, and resulting seamless instantiation of a solution), it must fall into those problems that have yet to get a mechanical solution. Presuming that you can pick some rule and expecting to solve that problem without continuous adjustment and ingenuity, means facing one of the fractal tigers of our universe with a stick.

So there’s no hope to solve the problems that plague knowledge-based work?

No, just like careful design and excellent coding can achieve good software, and that has become easier since the days of punch-cards, there’s hope: by careful experimentation, and by using all our ingenuity, we can build better and better theories, defining more powerful models, and reduce the space of knowledge-based work, of heuristics, of craftsmanship.

But that’s highly focused work, not stuff that you do in-between steering committees, and certainly not without very good formal training.

Until that happens to whatever you are dealing with today, we are all better off not thinking that any of the easy solutions at the extremes will lead us out of the forest, we better stay awake and wary of any rule-induced comfort zone.

I stopped using “fudge” towards the end. Probably not a good name then.

Almost exactly one year ago I posted a list of lessons I learnt about software development organizations. Recently that post generated a lot of interest, with people approving, disapproving or generally commenting one or more of my pointy points. Some feedback can be seen in the comments section of the post itself here, but most of the conversations happened on Hacker News. In general the discussions triggered on Hacker News were so rich and interesting, often branching away from the original topic, that I decided to sit back and enjoy reading it all, amazed by the thoughfulness of the exchanges and giggling all the time. I refrained from participating in the discussions for two main reasons : first, I feel more contemplative during the holiday season, and indeed here was much to contemplate; second, I really didn’t want to risk sterilizing or polarizing the discussions with an “actually I meant…”.

Now that the action seems to have mostly petered out, I feel free to do exactly that: here is my “actually I meant…” post, and other thoughts.

#9 Hire only for good reasons. Being overworked is not a good reason to hire. Instead, hire to be ready to catch opportunities, not to survive the current battles.

I’ve read a lot of reactions to the second statement of this point : “Being overworked is not a good reason to hire” and they were all very interesting. I stand by it and I wish to articulate it further : a software organization produces systems, systems produce more work (yes, even perfectly working, bug-free software). If you are tackling 50% more than what you should, adding more people will grow the share of work to do at least as much as the share of work being done, and you’ll have more people overworked.

For a software organization, overwork is more of an environmental variable dependent on the company’s culture, the organization’s engineering culture and, in some rare and transient cases, actual external pressures. So, if you and your people are tackling too much, I suggest that you need to prioritize, reduce noise (increase focus), improve engineering and general work ethics (in this order). Once the priorities are in place, everything that was dropped (and likely much more which was not being considered due to the amount of “extra work” that “needed to be done”) becomes opportunities.

You can decide to recruit for some of those opportunities, but at the very least you will be doing it without the pressure of people being crushed by overwork; even more important, you’ll recruit within the specific scope of an opportunity and that will inform your recruitment parameters and color the new entity with goals and a character, this is infinitely better than adding to a generic goo of “workers”.

There’s of course another reason why recruiting for current work is not a good idea, it is uncorrelated to #9 and it pertains to the project lifecycle rather than broader organization dynamics, but it is still very valid and deserves mentioning: the mythical man-month. Anyone interested can look it up.

#32 Delivery dates…

The whole point here is not that delivery dates are bad per-se, but that they tend to polarize attention to something very easy to understand: the fact that there are “things that depend on the date”. Moreover, dates seem to loom larger and larger as time passes; if they were not one from the beginning, soon they become a dogma. Hence the example of the surgeon fixated on surgery duration: the problem is not the data-point (the duration) the problem is that the less competent the surgeon, the more she will focus on that one easy-to-understand data-point. The more incompetent people you have, the more the cult of the date will be strong and damaging, creating its own heroic narratives (the developers who work week-ends, the testers that test during the night, the early morning go-no-go meeting…). All of this theater takes the focus away from critical thinking about what needs to be delivered.

I should also note something that I left on the side when I wrote #32 and possibly deserves a point of its own, so:

#32.b Time synchronizations make for irrational organizations. Inter-department dependencies (think Software and Marketing), but also internal dependencies (for instance, Development and Testing) are often established around time synchronizations. This reinforces the status of dates as a major success indicator and isolates people in their own time-box: critical thinking about the overall goal dies as teams focus on respecting the rendez-vous with the next team. Avoiding time synchronizations is difficult, but it is a very good heuristic for organization improvements: it tends to lead to cross-functional teams covering much of the value chain.

#8 Fire people whenever you can. There’s often someone to fire, but not many opportunities to do so. When you are given a lot of opportunities to fire people, it is often due to a crisis situation and you’ll likely fire or otherwise lose the wrong people. People appreciate when you fire the right people, so don’t worry about morale.

The brain-dump nature of the list allowed for some surprising interpretations by people that obviously come from contextes that are very alien to the one I was implying; getting a glimpse of those contextes through their (at times horrified) reactions has been very instructive.

So, my context: imagine an organization that does not distinguish between productive and unproductive people, converting every hire in a bunch of mandays to allocate over one or more projects, those mandays being the only numerical metric used to describe the capability of the organization: “they can deliver 12K mandays in six months”.

When I say unproductive I mean it literally, near-zero or negative productivity people, true blackholes of team motivation. Organizations that for years have been hiring to grow their mandays, instead of knowing and managing their actual performance, are magnets and creators of extremely poor colleagues, at every level. Firing someone in a pile-of-mandays organization can be tricky and time-consuming: plenty of people will react badly to the idea of reducing the available mandays, after all it’s reducing the organization “productivity”. Hence, it’s best to start early.

I’m definitely not talking about drawing a line between top-performers and everyone else, to use the later group as hunting ground for this month’s “competitiveness-boosting-sacking”, in a soft re-enactement of Stephen King’s The Long Walk. If the only line you can draw is between great people and ok people, it’s better to focus on coaching, rather than mastering the company’s dismissal procedures.

#2 Don’t be prudish. If you fear that people will lose faith in you because of the foggy goals and dire situation statement you are painting yourself in a heroic corner.

This initial part of #2 relates to a very subtle equilibrium that the head(s) of a software organization has to contend with. Corporate politics generate a stream of “news” every day, it is a social-network with very real power struggles. Software development, and, generally speaking, productive work, doesn’t fit well with such amount of noise; besides, when the context is heavily entropic, some of that noise might include talk of dismantling everything and sending it packaged to the other end of the Earth. Every second Tuesday.

Since there’s always a death-ray pointing at your organization (and yes, this is a movie reference), it is good to at least apply a low-frequency filter when passing along the “news”, so that good and productive people can carry on without too much hassle.

At the same time having the trust and respect of your good and productive people is enormously helpful when you need to steer one way or another without reverting to authoritarianism (which is a bad idea, btw).

These two elements combine into a dangerous cocktail: you don’t want to be perceived as lost in a stormy sea, because you’ll scare your people AND possibly have them lose their trust in you, which you need. Not to communicate negative news and uncertainties in your vision is both comfortable and bathed in the light of common sense and altruism. This is how machismo and, more broadly, heroic approaches to leadership often present themselves. The problem is that when you do this you isolate yourself from the people that your are supposed to guide: you tell a very shallow tale of the situation, which the teams cannot use to take their own decisions without your clarifying help (and validation) and you build a rosy image of yourself and your decisions which will entrap your thinking and stop your people from spotting and solving the most difficult problems, those that you certainly could not solve alone.

So, you need to communicate even when you are uncertain and when you have to picture a bad situation, or you’ll isolate yourself and your people from reality, but you also need to carefully sort the real concerns and useful insights from the general, scary noises.

There would be more to say

For instance, I’ve not delved here in the details about The Entropic Organization, because I’ve already expounded on it a bit in the original post’s comments and because I find that while it does deserve further enrichment, readers have generally got the meaning and the character of it, so, for now I’m content.

Finally, as I said in the beginning, the discussions were rich and of broad topic, and I could end up adding a page of comments to each of the original points and many of the resulting threads, but I want to get this post out, so I close it here.