Symbiotic Design

Do we build code, or grow it? I was fortunate enough to attend a Michael Feathers workshop called Symbiotic Design earlier in the year, organized by the good people at Agile Singapore, where he is ploughing biological and psychological sources for ideas on how to manage codebases. There’s also some links to Naur and Simondon’s ideas on technical objects and programming that weren’t in the workshop but are meanderings of mine.

Ernst Haeckel - Trachomedusae, 1904 (wiki commons)

Ernst Haeckel – Trachomedusae, 1904 (wiki commons)

Feathers literally wrote the book on legacy code, and he’s worked extensively on techniques for improving the design of code at the line of code level. Other days in the week focused on those How techniques; this session was about why codebases change the way they do (ie often decaying), and techniques for managing the structures of a large codebase. He was pretty clear these ideas were still a work in progress for him, but they are already pretty rich sources of inspiration.

I found the workshop flowed from two organizing concepts: that a codebase is an organic-like system that needs conscious gardening, and Melvin Conway’s observation that the communication structure of an organization determines the shape of the systems its people design and maintain (Conway’s Law). The codebase and the organization are the symbionts of the workshop title. Some slides from an earlier session give the general flavour.

Feathers has used biological metaphors before, like in the intro to Working Effectively With Legacy Code:

You can start to grow areas of very good high-quality code in legacy code bases, but don’t be surprised if some of the steps you take to make changes involve making some code slightly uglier. This work is like surgery. We have to make incisions, and we have to move through the guts and suspend some aesthetic judgment. Could this patient’s major organs and viscera be better than they are? Yes. So do we just forget about his immediate problem, sew him up again, and tell him to eat right and train for a marathon? We could, but what we really need to do is take the patient as he is, fix what’s wrong, and move him to a healthier state.

The symbiotic design perspective sheds light on arguments like feature teams versus component teams. Feature teams are a new best practice, and for good reasons – they eliminate queuing between teams, work against narrow specialization, and promote a user or whole-product view over a component view. They do this by establishing the codebase as a commons shared by many feature teams. So one great question raised is “how large can the commons of a healthy codebase be?” Eg there is a well known economic effect of the tragedy of the commons, and a complex history of the enclosure movement behind it. I found it easy to think of examples from my work where I had seen changes made in an essentially extractive or short-term way that degraded a common codebase. How might this relate to human social dynamics, effects like Dunbar’s number? Presumably it takes a village to raise a codebase.

Feathers didn’t pretend to have precise answers when as a profession we are just starting to ask these questions, but he did say he thought it could vary wildly based on the context of a particular project. In fact that particularity and skepticism of top down solutions kept coming up as part of his approach in general, and it definitely appeals to my own anti-high-modernist tendency. I think of it in terms of the developers’ theory of the codebase, because as Naur said, programming is theory building. How large a codebase can you have a deep understanding of? Beyond that point is where risks of hacks are high, and people need help to navigate and design in a healthy way.

((You could, perhaps, view Conway’s Law through the lens of Michel Foucault, also writing around 1968: the communication lines of the organization become a historical a priori for the system it produces, so developers promulgate that structure without discussing it explicitly. That discussion deserves space of its own.))

Coming back to feature teams, not because the whole workshop was about that, but because it’s a great example, if you accept an organizational limit on codebase size, this makes feature/component teams a spectrum, not good vs evil. You might even, Feathers suggests, strategically create a component team, to help create an architectural boundary. After all, you are inevitably going to impact systems with your organizational design. You may as well do it consciously.

A discussion point was a recent reaction to all of these dynamics, the microservices approach, of radically shrinking the size of system codebases, multiplying their number and decentralizing their governance. If one component needs changes, the cost of understanding it is not large, and you can, according to proponents, just rewrite it. The organizational complement of this is Fred George’s programmer anarchy (video). At first listen, it sounds like a senior manager read the old Politics Oriented Software Development article and then went nuts with an organizational machete. I suspect that where that can work, it probably works pretty well, and where it can’t, you get mediocre programmers rewriting stuff for kicks while the business paying them drowns in a pool of its own blood.

Another architectural approach discussed was following an explicitly evolutionary approach of progressively splitting a codebase as it grew. This is a technique Feathers has used in anger, with the obvious biological metaphors being cell meiosis and mitosis, or jellyfish reproduction.

The focus on codebases and the teams who work on them brings me back to Gilbert Simondon’s idea of the “theatre of reciprocal causality”. Simondon notes that technical objects’ design improvements have to be imagined as if from the future. They don’t evolve in a pure Darwinian sense of random mutations being winnowed down by environmental survival. Instead, when they improve, especially when they improve by simplification and improved interaction of their components, they do so by steps towards a potential future design, which after the steps are executed, they become. This is described in the somewhat mindbending terms of the potential shape of the future design exerting a reverse causal influence on the present: hence the components interact in a “theatre of reciprocal causality”.

This is exactly what programmers do when they refactor legacy code. Maybe you see some copy-pasted boilerplate in four or five places in a class. So you extract it as a method, add some unit tests, and clean up the original callers. You delete some commented out code. Then you notice that the new method is dealing with a concept you’ve seen somewhere else in the codebase. There’s a shared concept there, maybe an existing class, or maybe a new class that needs to exist, that will tie the different parts of the system together better.

That’s the theatre of reciprocal causality. The future class calling itself into existence.

So, given the symbiosis between organization and codebase, the question is, who and what is in the theatre? Which components and which people? Those are the components that have the chance to evolve together into improved forms. If it gets too large, it’s a stadium where no one knows what’s going on, one team is filming a reality TV show about teddy bears and another one is trying to stage a production of The Monkey King Wreaks Havoc In Heaven. One of the things I’ve seen with making the theatre very small, like some sort of Edinburgh Fringe Festival production with an audience of two in the back of an old Ford Cortina, is you keep that component understandable, but cut off its chance at technical evolution and improvement and consolidation. I’m not sure how that works with microservices. Perhaps the evolution happens through other channels: feature teams working on both sides of a service API, or on opportunistically shared libraries. Or perhaps teams in developer anarchy rewrite so fast they can discard technical evolution. Breeding is such a drag when drivethru immaculate conception is available at bargain basement prices.

Cyranautical Loyalty

Loyalty cards are loyalty simulators. The corporate entity wishes to retain your business, so it assesses your service to it quantitatively. The class, or achieved level in the loyalty system, triggers a specific script in workers for the corporation. Loyalty is an animal feeling, for people and dogs. If we think of a corporation as a rule driven machine, that does not have emotions or emotional understanding itself, or at least something that is not an animal, we can see why the loyalty must be simulated. From the corporation’s perspective, loyalty is something quantified for the advantage of the organization. In happy circumstances this is a symbiotic collaboration of profit gained for services rendered, though the relationship can be parasitic too, with the corporation exploiting its customers, or customers exploiting loopholes in a poorly designed loyalty system.

Now many people in service roles work hard to genuinely help people out, and really do like to see people looked after. I’m not dismissing (or idealizing) that human connection. The two elements that distinguish a loyalty program as a simulator in a fairly precise sense are firstly the corporate authored script, and secondly the systematic tracking of loyalty state (microsocial class), which in turn determines the roles of actors in the script. Humans write the scripts, and then different humans play them out. We go along as workers and customers with the script because it is our job and because it is convenient, or pleasant. In working with the script it’s hard not to have some emotional response, however attenuated, and loyalty simulation becomes loyalty stimulation. (Perhaps your formidable willpower, dear reader, means you never respond emotionally to corporate transactions, and have never cursed at a late charge on a phone bill, but I certainly have.) At this point we grant the corporation some agency, and it is simulating loyalty in much the way the AI in a Turing Test simulates intelligence.

You can expand this viewpoint to encompass a whole worldview of corporate simulation, as in Baudrillard’s descriptions of Disneyland, “capturing all the real world to integrate it into its synthetic universe”. If we focus instead on the script, the actors, and the tracking of state, we can see loyalty programs as early adopters of gamification. Airline gold class status is the original level treadmill. The scripts of greeting are little interactive fictions, choose-your-own corporate adventures. Humans write the scripts and different humans act the roles. Help desk scripts run the same way: once you exit the robot-driven entry point (press 2 to choose Mandarin, etc), a customer simply enters another script with first level support, where, initially, your lines and choices are still very constrained.

In the play Cyrano De Bergerac, Cyrano woos Roxanne by providing words to be delivered by another man with a more handsome face. The psychologist Stanley Milgram experimented with this idea, finding people reacted to people parrotting other’s words without suspecting they came from another. They gave people the benefit of the doubt that their thoughts were their own, which honestly is usually a good working rule, if you aren’t in a psychological experiment, or living in the twenty-first century. Milgram called the actors in his scenario cyranoids, after the play. It can seem a disturbing concept, as if controlled by another mind. But isn’t every first level help desk, every routine call centre call, every canned gold class greeting, a cyranoid scene? It is software using meat to impersonate meat. It is an inside out mechanical Turk, with the Turk on the outside and the machine within. Corporations and computing have really just made it cheap and banal. A military boot camp is full of cyranoid experience, of ritual interaction backed by systematic tracking. Or the political state itself, like the pre-modern state of special ranks, official clothing and carefully graded formal titles. We can be loyal to a state. We can be cyranoids going over the tops of trenches in our thousands, following a script written by someone else who lived before we were born.

These pre-Turing simulators are nuanced and complex but computationally crude. It’s all IF-THEN, central storage is tremendously expensive ink on paper and the bandwidth is a nightmare. The signal to noise is appalling and you constantly have to resort to hacks like having deserters shot.

Though we are sometimes fooled by crude or sophisticated gamification, we often participate in it actively, as well. Many soldiers of the Great War were sincere volunteers, putting themselves forward for what they saw as a greater cause, or in defense of people dear to them. A mechanistic view of society, where everyone is a robot programmed by some ritual, is too much a caricature. The cyranoid is an everyday feature of formal social structures, ones people have been using for millennia. The new aspect is simply computational cheapness, so we can now have cyranoids in high fidelity loops, remote procedure calls and chains of responsibility. The script is still acted by a person, who chooses with each interaction whether to stay on script or to improvise and face the systematic consequences, or benefits, of such disruption.

With the contemporary explosion of gamified systems, and every app and online marketer trying to quant a few extra percentage points out of our custom, we navigate in and out of cyranoid scripts, tacking and gybing based on advantages of the moment, from our own obligations to the structured rewards and compulsions of the systems we sail between. Cyranoid is too passive a term. We have made a society of cyranauts

Ink and Rubber

To a developer, an unfamiliar system can be like a picture drawn with an Etch-A-Sketch. You can see what is there, and some relationships between the pieces, by location, style or theme. When you have to alter the picture, though, difficulties arise. The Etch-A-Sketch eraser is quite coarse. It is easy to destroy existing parts of the picture. This is if you can find the eraser at all, and it hasn’t fallen behind the couch, or been chewed by the dog. If you really have to remove something, you may as well just pick up the whole thing and shake it back to a blank slate.

If you are very attached to the picture, it is still possible to add detail on existing empty ground. When large areas of white space are still free, you can choose a space to draw something new fairly easily. Once the picture is detailed, or you need to make a change related in a specific way to the existing picture, this is basically reduced to coloring in between the lines.

We code like we are painting with ink.

Our instinct is not to reuse and refactor, but to tweak and rewrite. Why? Fear and pride, perhaps. We aren’t born coding, though, so these emotional reactions are learnt because of some aspect of working with software. I’d suggest both behaviours stem from incomplete or untrusted knowledge of the existing code.

Peter Naur described programming as theory building.

Programming in this sense primarily must be the programmers’ building up knowledge of a certain kind, knowledge taken to be basically the programmers’ immediate possession, any documentation being an auxiliary, secondary product.

Naur is talking of a mental model, not the formal and external symbolic expression of an equation or a Java class. The model may need to be sophisticated, but it is also defined by its working immediacy. Your model of the code today may easily be different to a year ago, even if the code has not changed. Naur doesn’t relate the two, but to me it is also reminiscent of what sociologist Patricia Hill Collins calls everyday theory. Hill Collins is referring to theories of society, and she contrasts everyday theory with High Theory constructed in and for an academic setting, like, say, Marx’s dialectical materialism. Everyday theory is collective and social, may lack scholarly depth at times, but it also has the workaday vigour of something used every day to navigate a system.

If we follow Naur in considering the main activity in programming to be building mental models, even if the deliverables are software artefacts, one implication is the cost of building a theory – the cost of learning – dominates everyday coding. Writing a new class is then easier because the mental model is built by the writer while they are writing. At a larger scale, this suggests why the greenfield myth is so beguiling. Architecture suffers the same costs of understanding as programs. There’s a lot of interest in microservices at the moment, which is basically the rewrite elevated to an architectural ideal. I guess it works very well in certain domains and organisations, but I haven’t used auto-balkanisation of this sort myself, and at any rate there are many running systems not written that way.

Colouring-in behaviour is a bit harder to describe. It’s when a developer goes to painstaking effort to minimise changes to lines of code, especially structural elements like methods and classes. It’s similar to what Michael Feathers recently described as shoving, except he is using a different spatial metaphor.

Colouring-in is mentally cheaper because of scope. The scope of your working theory doesn’t have to include the interaction of class structures and broader parts of the codebase. From the perspective of the developer and that specific fix, it can even seem neater than more structurally impactful solutions, such as factoring out new methods or consolidating emerging redundancy. Poor unit tests exacerbate this, increasing the risk of errors after changes are made, discouraging refactoring.

Unit tests are also interesting for mental models because they are effectively worked examples of the theory the developer was using at the time. Good tests illustrate an idea as well as describing edge cases, and this decreases the cost of learning, and provides quicker feedback on the suitability of the programmer’s working theory.

The computational material of software is often brittle for a user in the way it runs, but the material itself is strikingly plastic at development time. It’s less like ink painted on paper and more like lego fused with rubber bands. Refactoring recognises this plasticity, and works with it. Compared to reinforced concrete, software is easy to change. Sometimes our minds are not.

Ethical Ambiguity With Pockets

I found myself contemplating the origin of a pair of shorts. They are comfortable, 100% cotton shorts in Uniqlo’s highly functional minimalist style, casual but neat. They extend to mid-thigh, have two side pockets, and are held up with a threaded cord. They are “branch bankers’ rig”, to borrow Les Murray’s description in The Dream of Wearing Shorts Forever, sending signals of respectability without excessive formality in Australian and Singaporean society, and while Murray correctly notes they are “ideal for being served last in shops of the temperate zone”, I can confirm that on the equator they are perfectly adequate for being served Sunday brunch in a five star hotel on Orchard Rd, at least if worn with a collared shirt and a sufficient sense of entitlement. They were bought this year at the enormous Vivo City shopping mall in Singapore, and are purple, because I let my young daughter choose the colour.

Uniqlo, part of the corporate parent Fast Retailing, is known in the industry for maintaining high quality at a cheap price point. To achieve that, it carries a relatively small number of styles, but in dozens of colours. The dyeing process is tightly quality controlled and capital intensive. For example Uniqlo suppliers like Lu Thai Textile describe precise dyeing plant relying on specialized mechanical equipment for dipping and computer assisted design (CAD) for looms. Lu Thai is a vertically integrated company including cotton farms and spinning. Lu Thai’s website describes cotton farms in Akesu in Xinjiang province, so perhaps these shorts were made from cotton farmed in Xinjiang, and shipped elsewhere in China to be weaved and dyed. Lu Thai also has a presence in Shandong province, for example, which is more industrialised and with more middle class jobs. Shandong GDP per capita is US$13,262 vs US$8,755 in Xinjiang, and factory operator versus cotton farmer pay would typically reflect this difference.

Uniqlo also mentions China, Vietnam, Cambodia and Bangladesh as significant production centres for the company. Uniqlo has an internal system of technical specialists parallel to its management structure, at the top of which are around twenty takumi, or fabric masters, situated in production centres; going by the annual report they are mostly Japanese. Stitching is typically a more labour intensive process than dyeing, and in the case of these shorts, relatively unsophisticated compared to a dress shirt. This makes it likely to be focused on cheaper labour sites, though the label for these shorts states they are MADE IN CHINA. As noted in the course, and shown in the movie China Blue, sewing machine operators in South and East Asia are most often women. Lu Thai Textiles, which also makes shirts, features a photo on its website of a large factory floor where the sewing machine operators are 80% female; this is part of the company’s public narrative for this work. Fast Retailing was the subject of the 2011 book The Glory and Disgrace of Uniqlo, accusing it of “harsh, slave-like conditions” at overseas factories. Uniqlo’s business strategy of a small number of styles allows them to make massive bulk purchases from suppliers, sometimes taking the entire stock. This drives down unit costs through economies of scale, but also through tremendous pricing power over small suppliers. As Uniqlo has been expanding rapidly, this puts pressure on the more vulnerable participants in its supply chain, people like Jasmine in China Blue.

Uniqlo 2010 2011 2012 2013
No violations 9 6 8 10
Minor violations 52 56 59 95
Major violations 50 63 51 45
Severe violations 19 19 34 19
Highly unethical, review of contract 2 0 7 1
Total 132 144 159 170

According to their own Corporate Social Responsibility reports, as Uniqlo supplier factories increased from 132 to 170 from Financial Year (FY) 2010-2013, severe ethics violations went through a spike of 21 to 41 in FY 2012, with 7 contracts reviewed in that year, and some contracts cut. For comparison, the one contract reviewed last year for Uniqlo is more typical. Two Chinese factory contracts were also cut for use of excessive, unpaid overtime and child labour – a fifteen year old working a job requiring a sixteen year old.

It is dismaying to learn that Uniqlo, until a few years ago, seems to have payed more attention to fabric quality than the health and safety of people that make their company successful. Fast Retailing only seemed to improve the working conditions supply chain under consumer scrutiny, the power of their global brand working against opacity. It is also interesting how speculative this process of investigation has to be. The tag on these shorts has a 45 character code on it, which in a firm with Fast Retailing’s robust quality culture, is almost certainly a unique identifier for tracking from early in the supply chain all the way through to retail stores. I wonder what it would mean to make that information public, or to use technology to connect specific participants in the supply chain in a social network built around a specific item. Would such a panopticon of shorts be an ignorable gimmick, a huge invasion of privacy, a way of re-establishing human connection over the top of abstracted capitalist commodity exchange, or a way for privileged rich people to harass their unwitting global servants online?

Gough

Gough Whitlam’s political career was over before I was born, but his mythological career was just beginning. He was a man made in heroic proportions, a handsome face with a telegenic gaze, six foot four and a booming baritone voice in the educated accent of the Australian middle class. Gough’s voice may now define Australian soundbite oratory. “Well may we say God Save The Queen, because nothing can save the Governor-General”; “It’s Time”; “Crash through or crash”. His very names – either of his names – fall with the heft of a Patrick White novel. The last Australian prime minister to serve in the military. Intellectual, charismatic and impatient.

Clifton Pugh's portrait of Whitlam

Gough wasn’t my hero. He wasn’t a childhood idol or a teenage political ideal for me. I am not born of that leftist tribe. But he is a heroic figure, playing all the right chords on our acculturated meat brains. He had his sweeping policy triumphs like Medicare and China diplomacy, the great raiser of the koala bear leviathan, his electoral victories, his electoral defeats.

I used to think the Whitlam government’s impatience in ramming through so many changes so quickly was its great mistake, that it died of whiplash. This is the conventional wisdom, but I’m no longer so sure. Complex systems can change incrementally for certain things, but they are homeostatic too, they slip back into established paths. Sometimes you have to change lots of things at once for any change to stick. Sometimes history shifts with a crack. You blink, and everything continues, but everything is changed. The black and white television has switched to colour.

Gough’s story has villains and Gough himself had tragic flaws. The intellectual that couldn’t get the numbers to add up, the charismatic leader that couldn’t keep his cabinet together. The betrayal, the unravelling, the dismissal. But this is a modern Australian story, not a Greek tragedy. Whitlam-Odysseus went home with his Penelope, became a professor, and won saucepans on Sale of the Century. The adoration of the living man was a bit close to royalty, for me. He had a long life, and a good one. Now he has climbed into a heavenly V8 the size of a small tank, and driven off, trailing clouds of glory. We should paint him on the doors of our temples and the walls of our pool rooms, to ward off evil and scare away the ghouls of complacency.