Big Powerful New Data

Power and language are both crucial currents for innovation. Two alternative tools for macro analysis of an economy’s innovative capacity and output then suggest themselves. Firstly, a power-centric analysis of changes in the economy, from in physical and political senses. Secondly, linguistic analysis of mass printed and digital material produced in an economy, from standalone and comparative perspectives. These techniques can complement one another, given that shifts in power and language also interact. Power-centric analysis of technology is a technique introduced by Russell et al in “The Nature of Power: Synthesizing the History of Technology and Environmental History”. An example of linguistic analysis of the economy is the R-word index run by The Economist, where the frequency of the word recession is used as an indicator of recession.

In a power analysis of the economy, energy flows and transitions are modelled qualitatively or quantitatively. Using this lens, we may note that the rise of the Internet has accompanied surging electrical power needs in large relatively centralized datacentres, with cloud computing being the current extreme of this. At the same time it has disintermediated middlemen such as travel agents. The move of labour – and spending of biochemical energy – from a travel agent in an office to the consumer at home or on a smartphone in turn requires increased electricity requirements for mobile phone towers and households. Given this analysis we can get insight into Google’s investment and research into alternative energy and distributed generation technologies such as solar photovoltaics. We might also note that, globally, the Internet mostly runs on coal. Combining the physical energy analysis with political analysis, we can see where innovation actors are constrained by energy and whether shifts in power are dominated by local or foreign actors, be they wind power entrepeneurs or multinational oil companies.

A focus on physical power can yield quantitative metrics of joules and watts that are not available to more structural approaches such as the system of innovation model. It focuses on facts about the economy that are fairly readily available for most countries, and also in comparative form. Though power analysis does include the labour market and its use of biochemical energy, this focus on economic output may make analysis of innovation capacity relatively indirect. How much did the energy use of a US mathematician change over the twentieth century, except as a consumer of productivity tools, such as computers, available to all professionas? This is a technique pioneered by historians, and it may speak most clearly in retrospect, requiring extrapolations to deduce capacity which are more prone to subjective policy hobby horses.

The linguistic approaches strengths and weaknesses seem to complement power analysis. By focusing on words, it will tend to weight research and development activity more strongly, such as use of terms in journal articles or social media. One weakness of linguistic analysis is that mass corpuses of content must be available to do “big data” style analysis. A developing economy, particularly in the poorest parts of the world, may not produce enough readily available searchable content to discover meaningful shifts and opportunities. Relying on the linguistic approach too heavily in a poor developing country may skew policy too much to theoretical research and ignore useful innovations happening on the ground but not on Twitter.

The innovation systems approach may have a weakness that the initial categories of organization (university, R&D lab, etc) constrain future analysis, missing trends which cut across traditional organizations. In this way both power and linguistic analysis may show up perspectives that do not emerge as readily in the otherwise more comprehensive innovations systems approach, and thereby supplement it.

Invention As A Hub

In a linear model of innovation, innovation is imagined to proceed through an orderly sequence of steps, from pure scientific research, to applied science, formulation as a technology, then developing and scaling up distribution of that technology as a product. One alternative model might be that of a “techno-social hub”. In a techno-social hub model, science, applied science, capital provision, product development and the exchange of products and services in the market are connected to each other through a media of technology and social processes. This can be represented graphically as a techno-social hub node connected by a single edge to nodes representing research, applied research, and so on. These nodes are similar but not identical to the stages in the linear model of innovation.

The techno-social model is an improvement on the linear model, as it distinguishes different factors in innovation without unrealistically segregating those factors. It represents that once a technological or process innovation is made, influence doesn’t flow in a straight line, but feeds back to different parts of society via the artifact or social change. For example, the development and use of the Newcomen steam engine in factories in 18th century Britain opened up the possibility of applied research and prototypes of steam trains by the early 19th and the capital provision required to build railway networks. The steam engine also spurred pure research in thermodynamics and was an influence on the psychological theories of Freud.

Operationally this model recognises the importance of institutions and organisations that support each aspect of innovation, such as universities for basic research and markets for exchange and use. By emphasizing the links between different stages it might direct policy makers and people in the field to the importance of good communications amongst organisations, via physical co-location, libraries, journal publication, less formal collaboration over the Internet, and so on. It recognises that, in William Gibson’s phrase, “the street finds its own use for things”, and that research and capital should be able to dynamically react to new uses of a technology.

A disadvantage of the model may be underemphasizing the links between closely related areas, such as basic and applied research. By placing technology at the centre of the model, it tends to technological determinism. The social aspect of the techno-social may also be too broad a category to effectively operationalise for setting innovation policy. Overall, however, the techno-social hub model avoids the constraints of the linear model at the cost of being slightly harder to say, and draw.

Industrializing The Noosphere

We are not practicing Continuous Delivery. I know this because Jez Humble has given a very clear test. If you are not checking your code into trunk at least once every day, says Jez, you are not doing Continuous Integration, and that is a prerequisite for Continuous Delivery. I don’t do this; no one on my team does it; no one is likely to do it any time soon, except by an accident of fortuitous timing. Nevertheless, his book is one of the most useful books on software development I have read. We have used it as a playbook for improvement, with the result being highly effective software delivery. Our experience is one small example of an interesting historical process, which I’d like to sketch in somewhat theoretical terms. Software is a psychologically intimate technology. Much as described by Gilbert Simondon’s work on technical objects, building software has evolved from a distractingly abstract high modernist endeavour to something more dynamic, concrete and useful.

The term software was co-opted, in a computing context, around 1953, and had time to grow only into an awkward adolescence before being declared, fifteen years later, as in crisis. Barely had we become aware of software’s existence before we found it to be a frightening, unmanageable thing, upsetting our expected future of faster rockets and neatly ordered suburbs. Many have noted that informational artifacts have storage and manufacturing costs approaching zero. I remember David Carrington, in one of my first university classes on computing, noting that as a consequence of this, software maintenance is fundamentally a misnomer. What we speak of as maintenance in physical artifacts, the replacement of entropy-afflicted parts with equivalents within the same design, is a nonsense in software. The closest analogue might be system administrative activities like bouncing processes and archiving logfiles. What we call (or once called) maintenance is revising our understanding of the problem space. 

Software has an elastic fragility to it, pliable, yet prone to the discontinuities and unsympathetic precision of logic. Lacking an intuition of digital inertia, we want to change programs about as often as we change our minds, and get frustrated when we cannot. In their book Continuous Delivery, Humble and Farley say we can change programs like that, or at least be changing live software very many times a day, such that software development is not the bottleneck in product development.

With this approach, we see a rotation and miniaturisation of mid-twentieth century models of software development. The waterfall is turned on its side.

Consider, as an example, the 1956 Bennington paper Production of large computer programs. It was revisited in 1983, giving, with today, three points of comparison. The original states four problem areas for large real time control systems (p5), summarised in my words as

1. Expensive computing time
2. Reliability
3. Tooling and scaffolding, here named supporting programs
4. Legibility through encyclopaedic, institutional documentation

The first two of these we might think of as due to the problem domain or a simple function of the technology available. The second two are activities which take a great deal of effort but are, at least  in hindsight, specific to the software methodology of the solution. The creation of extensive scaffolding and an extensive bureaucratic literature is baked into the problem statement. The high modernist tone of this enterprise is loud and clear in the design statement on p10, where the solution is expressed as a challenge of central planning.

[T]he disadvantages of decentralization cannot be tolerated. 
[...] 
The control program must be centralized. This complicates design and coding since communication between component subprograms must have a high bandwidth. The use of each of the thousands of central table items must be coordinated between 100 or so component subprograms. Organized, readable specifications for the design and coding phase accomplish part of this task.

This is not to suggest Bennington was wrong, exactly: a realtime control system does require a much greater degree of design coherence than loosely coordinated programs run by manual operators. The bureaucratic solution for his information problem – centralise a top down design, then document voluminously and mercilessly, so lower levels are less likely to interpret the design differently – also suited both a twentieth century military organisation and the high modernist zeitgeist. The implied design of the control system actually still seems reasonable. The technical substrate of punchcard driven mainframes is unfamiliar but also understandable as a toolset. It is the presentation of the bureaucratic waterfall process that has the pathological familiarity of the newly archaic.

Having just made a process / system distinction, that same distinction is criticized by a useful paper on applying humanistic cultural terms, like “modernist”, to software. In Postmodern Software Development, Robinson, Hall, Havenden and Rachel characterise much software development as uncritically and unwittingly modernist. This is especially the case for “software engineering”, a term coined in conjunction with, and in opposition to, “software crisis”.  Robinson et al highlight weaknesses of the modernist project as dangerous in software development. Three of relevance are 1) The assumption of a single Truth ill-suits the social process of requirement gathering, where there is no definitive statement of The Problem 2) Knowledge of experts (technologists) is privileged in ways that diminish user experience 3) Separating systems from the people and processes that build and use them redefines the technical as that which does not fail.

Expanding on the third point, process clearly impacts the shape of a system. In a physical artefact this becomes trivially obvious. You can’t have a lost-wax technique bronze without wax. In software the process is historically more abstracted, or obscured by individual craft variation (where there is no team process and it devolves entirely to individuals). An example of how team process impacts system structure is the systematic use of unit tests. Unit tested methods and classes tend to be shorter and more clearly decomposed. What is familiar and reusable in Bennington’s control system is a high level information architecture, at the level of a very high level engineering pattern like “bridge”. 

The ways in which software process shapes artefact design merits discussing separately and empirically. For now, let me suggest two symptoms of waterfall. The first is addition of visible features without removal of others, expanding in each version, like members of a well established bureaucracy. Though retail packages like Microsoft Word often receive this flak, corporate change management software like BMC Remedy makes it look a paragon of flexible usability.

The second is the growth of extensive secondary codebases around the named system. These secondary codebases are usually scripts, but in the forms of scheduled jobs, auxiliary standalone shell scripts, arbitrary repair SQL stored procedures, or proprietary internal languages based around input or output manipulation. Scripting languages and their like are useful for all sorts of systems, but in these cases the actual and perceived risks of deploying the main application grow to a degree that any relatively rapid or small scope change happens as a workaround in the secondary codebase. The secondary, scripted codebase becomes a kind of shantytown around the monumental and infrequently updated core. It has a shantytown’s advantages of rapid adaptation to its builder-users, and its disadvantages in lack of infrastructural support or longer term planning. It might not even be checked into source control – it’s only a script, you see – and so one day the whole thing can be washed away in a tragic magnetic mudslide. The high modernism of the waterfall method creates core systems which are Brasilias of software, dictatorial and unchanging. In the extreme, they become “miles of jerry-built platonic nowhere”, in Robert Hughes words; and as with Brasilia it is only the shantytowns grown around them that let them function as systems at all. James C. Scott and James Holston have described the way the minutely planned new city nevertheless failed to plan sufficient accommodation for the sixty thousand workers needed to build it. These condangos then squatted on nearby land; by 1980 75% of the population of Brasilia lived in unplanned settlements while the planned city of uniform apartments and vast empty squares had less than half its projected population.

Bennington, though, was too good an engineer to build a system that didn’t work. If the system had failed he also probably wouldn’t have published the paper. I still like his advice on testing:

The need for comprehensive simulated inputs and recorded outputs can be satisfied only if the basic design of the system program includes an instrumentation facility. In the same way that marginal-checking equipment has become an integral part of some large computers, test instrumentation should be considered a permanent facility in a large program.

The planning, creation and maintenance of a subsidiary testing infrastructure is not really something that can happen entirely at the end of a project, in an official “Test” phase. You have to be thinking of and designing for it all along. Another interesting insight into process is found in Bennington’s 1983 review of his own paper. Before the control system in the paper was built, they built an extensive prototype with about 30% of the instruction count of the final system. In other words, they didn’t do waterfall at all, but iterated with two fairly long cycles. This wasn’t described in the 1956 paper. It didn’t suit the narrative of top down high modernist design. Since the beginning, the only way to succeed at waterfall has been to cheat.

One of the first and simplest steps recommended by Humble and Farley is checking all configuration for all environments into source control (though not using the same project). This immediately crosses two constructed, overspecialised boundaries – firstly between top designed code and the rest of the pieces that make a system work, and secondly between the roles of development and operations (hence the DevOps portmanteau). Strict role separation is another modernist Taylor-Fordist legacy, where workers focus only on their tiny piece of a factory production line, rather than having an awareness of the final system and overall process. In a way, though, many software release processes are not as organized, smooth or productive as Henry Ford’s Model-T factory. Two years ago we had a release which required six hours of manual effort to upgrade and configure. This was merely an extreme version of the more typical half to one hour installations of related applications. The manual effort was inevitably highly repetitive and error prone. Frustration at this pain helped push us down the deployment automation path, and similar releases now take seconds to minutes. Going by the examples in Continuous Delivery, both the initial circumstances and the potential improvement are fairly typical. 

In our case previous discussion of deployment automation had foundered on the potential scope of commands needed by a more sophisticated tool. However, when we sat back and analysed our manual release instructions, we found they were almost all composed of a small number of frequently repeated steps in a small number of files, based on conventions of ownership previously agreed with the support team. The first working prototype, demonstrating automated deployment of the notorious six hour release, took less than a week’s effort from one junior developer. (Ok, one wunderkind junior developer, but the design was not complex, building on existing test and plant management tools. It was fruit no one realized was low hanging until we tried to reach up and pluck it.) These improvements begun to mesh with other automation in a virtuous cycle. So more frequent, automated, regression testing gave us the ability to release more frequently, by dropping the one off cost of regression, and deployment automation let us install the new release in production without the support team hunting us down with machetes.

The factory production line is not my fanciful metaphor; it is the organizing principle of the whole Humble and Farley book. They prefer the term pipeline and invoke WE Deming rather than Taylor and Ford, but they still entangle themselves in that industrial and managerial tradition. The cultural change required to do continuous delivery (and its partner process, agile) can be wrenching and the benefits significant. Yet after this change, the sequence of steps suggested by Humble and Farley is not that different from those suggested by Bennington sixty years earlier. 

The combination of agile methods for requirement gathering and systematic deployment automation is manifested by miniaturisation and concretisation. The same process steps are followed but are made so cheap they can be run on small features and trivial changes instead of specification documents hundreds or thousands of pages long. Interfaces between phases of the cycle stop being documents handed over by humans and become running interfaces in tools like maven or Jenkins. Once this happens it is more obvious the process is an optimizable machine. Abstract phases on paper are replaced by specific failure conditions from the toolset. This explanation of a toolbox of specific technologies and techniques is very much the content of Humble and Farley’s book. The intent behind a particular technique is explained, but not in the abstract.

In his book The Mode of Existence of Technical Objects, Gilbert Simondon introduces the term concretisation to describe the process of initial top level designs in early machines being transformed over time to efficient machines built of mutually interlocking components. Through a series of marvellous historical examples, including cathode ray tubes and tidal power turbines, he shows how components which are initially designed to clean up after one another attain an elegant coherence as functional interdependence is refined. In one example, the Guimbal tidal power generator became much more efficient once it stopped being an generator separately attached to a pipe of moving water, as in previous designs, and was instead inserted within the water pipe itself. This allows it to shed excess heat, and without the removal of those heat sinks the generator would not even fit in the pipe. 

To design such a thing you must imagine its problems already fixed. Simondon memorably terms it the “theatre of reciprocal causality”, and we see it in software when a refactored class makes both unit testing easier and the function more coherent. He also introduces the concept of a milieu – an environment which changes to become mutually supporting for the evolved technical object. So Google’s datacentres and custom machine designs evolved together, with improvements in one – lower footprint, standard components and no cases – complementing and initiating improvements in the other – robotic management in the air conditioned dark. Likewise in software development, quick installs in QA allow more frequent tests, building confidence in coverage, making refactoring easier, allowing more features at higher quality, and so on. 

It reminds of the process of feature discovery Eric S. Raymond described in his introductions to open source software development, The Cathedral and the Bazaar and Homesteading the Noosphere. Homesteading is a rich metaphor that captures the sense of constructed possibility in a new piece of software. (Almost too rich; should we worry about violently displaced indigenous Noospherians?) Open source software offers some more rejections of high modernism – user-builders instead of elites; limited central planning; forking as a lifestyle choice. (Git is postmodern source control: everyone has their own version of the truth and they choose whether to accede to alternative consensus versions. Also consider the contemporary ubiquity of plugins for browsers or IDEs.) Humble and Farley describe something larger scale and more controlled, an industrialisation of the Noosphere. Simondon suggests:
 

Industrial construction of a specific technical object is possible as soon as the object in question becomes concrete, which means that it is understood in an almost identical way from the point of view of design plan and scientific outlook.

This, in other words, is what continuous delivery looks like. Perhaps it is one of a family of industrialisation techniques. For the team I work in, the software and its milieu is not this concrete or scientifically controlled. But we can now see there from here.

I once saw a senior executive expound the concept of a development organisation as a Software Factory. In this vision you would make the process of gathering requirements so rigorous, controlled and well-understood that turning them into working software in production would be a mechanical, industrial process. It is one of the stupidest things I’ve ever heard, but it’s the logical endpoint of high modernist, waterfall software engineering. To treat requirement articulation as the main problem of software is ultimately to attempt to mechanize and rationalise the client and the user, to turn a person into a computer. It is a doomed utopian project that happens when engineers are bewitched by the aesthetics of predicate logic, the way Le Corbusier and the international style architects were bewitched by the geometry of town plans viewed from the air. Meanwhile, we would push boutique, custom installations on users and operations teams because we considered each release to be a unique snowflake requiring manual handling. In a sense, we spent sixty years of software development looking the wrong way. When we turn our attention to optimising the software deployment pipeline as a machine and its milieu, then we are toolmakers again, and human.

-

References

Bennington – Production of large computer programs
Holston, James – The High Modernist City: An Anthropological Critique of Brasilia
Hughes – The Shock of the New, ep 4, “Trouble In Utopia”
Humble, Farley – Continuous Delivery
Raymond, Eric S. – The Cathedral and the Bazaar
Raymond, Eric S. - Homesteading the Noosphere
Robinson, Hall, Havenden, Rachel – Postmodern Software Development
Scott, James C – Seeing Like A State, chapter 4: “The High-Modernist City:An Experiment and a Critique”
Simondon, Gilbert – The Mode of Existence of Technical Objects, 1958. 1980 Mellamphy trans.

Test Driven Development As Computational Positivism

Test driven development is a craft answer to a seemingly quite formal theoretical problem, verification and validation. This can be seen as a vernacular versus institutional architectural style. We can also compare it to different styles of science. When considering historical astronomy, Roddam Narasimha interprets radically empirical approaches as a different style of science, which he terms “computational positivism”.

[W]hile the Indian astronomer found the epicycle a useful tool of representation, he would cheerfully abandon the classical epicycle if he found something which was more efficient or led to a shorter algorithm and to better agreement with observation. For somebody subscribing to Greek ideals, however, this attitude would presumably seem sacrilegious – the rejection of the epicycle would question the basic assumption that the circle is a perfect figure preferred by nature, and hence precipitate a major philosophical crisis.
–
Narasimha, Axiomatism and Computational Positivism

Or in more familiar terms, the approach of the Keralan School was to discount theories and models and go with whichever calculation was most predictive.

In computing the problem of verification and validation had a clear academic answer. It came from the same school of thought – Dijkstra, Knuth, et al – that delivered major algorithmic and language design innovations, many of which (eg structured programming) were unintuitive conceptual shifts for the working programmer. The answer was formal methods, with the classic citation being Carrol Morgan’s Programming From Specifications. I was trained this way and remain sympathetic, but it hasn’t penetrated everyday practice. (Granted I should read more on the latest work,  but I suspect formal methods suffered from the same misreading of the software crisis as other spec-centric high-modernist schemes. I also suspect they will live again in another form, both good topics for another day.)

Test-driven development, by contrast, saw rapid uptake among working programmers, even if it is short of universal. Formal proof and TDD aren’t equivalent techniques, as one is deductive and one inductive. Proof is also a stronger standard. Both involve some degree of upfront investment, but unit tests are much lower cost to interweave into an existing codebase or introduce in an incremental way. One way to think of TDD is a vernacular style suited to an artisan scale, in contrast with the high cost institutional approach of formal methods. It’s the caravan or service station of refinement from specifications.

This is the hoary old craft-practical vs academic-theoretical dialectic. It’s useful, but obscures as well as reveals. Formal methods practitioners never saw proof as replacing testing, let alone automated testing. On the other side, looking at JUnit as an example, the originators like Kent Beck and Erich Gamma were hardly without university links, and their Smalltalk background wasn’t mainstream. 

This is where Narasimha’s typology seems to apply, the idea of not doing science without theory, but doing science in an alternative mode. One of the striking aspects of TDD as described in the original JUnit essays, like Test Infected, is their relaxed attitude to the ultimate implementation. This is computational positivism – the only measure is whether the formula hits a requisite number of data points. The symbolic coherence of the solution itself is not granted any weight; the code can be spaghetti. Though aesthetically displeasing, there’s an argument that its empirical rigour is more scientifically sound.

The experience of using unit testing widely across a codebase usually shows a different emerging property. By decomposing into testable components, the overall coherence of the design actually tends to improve.

Though Keralan astronomy was superior to European for some hundreds of years, post-Newtownian astronomy finally trumped it for precision, together with a very powerful corresponding theory. The right test for such an ambitious scheme in software would be a computationally positivist one, just as for all the bodgy solutions that preceded it: sure it’s pretty, but does it keep the test bar green?

The Consensus Reality Based Community

1. There’s a concept from science fiction criticism which has become a favourite of mine. Indeed it seems fundamental to this 21st century glocal postmodernity of ours, the concept of consensus reality.
1.1 It is worth remembering that this consensus often refers to the beliefs of the society in the work under criticism, in which marmalade may be money, spaceships may fly faster than light, and handheld communicators with vid screens may be ubiquitous.

2. The idea of consensus reality neatly captures several insights.
2.1 Reality proper, what Kant called the unsynthesized manifold, is unavoidably mediated by our senses and brain.
2.2 Our model of the world is socially constructed by a group we live in.
2.3 Powerful institutions of mainstream thought – like large newspapers – work within certain parameters of perception.
2.3.1 The first page of search engine results are representative. They are consensus reality engines. Common sense engines, in Bruce Sterling’s words.
2.4 Something in the consensus is inevitably and always wrong.
2.4.1 The consensus contains arguments with known for and against positions.
2.4.1.1 The argument itself can be wrong, irrelevant, meaningless side effect, not resolvable as either pro or con, etc.
2.5 Broad consensus realities often have enduring correlations with events.
2.6 Consensus is reinforced by breadth.

3. Kuhn’s concept of a scientific paradigm resembles a consensus reality, but is far more systematic.
3.1 Consensus reality includes cultural convention and everyday discussion including obvious internal logical contradictions.
3.2 Consensus reality is intuitive.
3.3 Consensus reality may be surprising – chance events – but not unanticipated ones.
3.3.1 “Black swans” are demonstrations of consensus reality.
3.3.2 Commuting to work is also demonstrative.

4. A reality based community responds to empirical sense-data.
4.1 Measures.
4.2 Adjusts in response to changes in data.
4.3 Follows technique.
4.3.1 Technique may be systematic. It may have a model.
4.3.1.1 The model may be tested empirically and systematically.
4.3.1.2 One might use a randomised controlled trial, or survey, or historical data source, or blind peer review.
4.4 Reality based communities survive by adaptation.
4.5 Strongly reality based communities would necessarily be scientific communities.
4.5.1 No serious political community today is also a scientific community.
4.5.1.1 Establishing professional pools of expertise for these processes is necessary but not sufficient.
4.5.1.1.1 Any such group analysing a public problem is inherently political.
4.5.1.1.2 This is technocracy.

5. The consensus reality based community is always broad, often well-established and always vulnerable to disruption of its reality.
5.1 This is the nature of Karl Rove’s insult.
5.1.1 By always anchoring themselves in well established consensus reality, Rove’s opponents fail to react to events initiated by his faction which change the broad understanding of reality.
5.1.2 Rove’s faction has since, with amusing consistency, repeatedly showed themselves to not be reality based.
5.1.2.1 This faction acts as an alternative consensus reality based community.
5.1.3 In rejecting the dominant consensus reality, and its rhetoric of objective evaluation, they went straight on and also rejected a reality base for their community.
5.1.3.1 This is not a survival technique.
5.1.3.2 On the day of the 2012 US Presidential election, both major parties expected to win.
5.2 The consensus reality based community may even tacitly acknowledge it is not reality based.
5.2.1 This is a society in which the consensus ritual detaches from its social meaning.
5.2.2 Incongruence between political consensus reality and reality manifests in scandal.
5.2.2.1 Fin de siècle Vienna.
5.2.2.2 Late Ming China.
5.2.3 Incongruence between social consensus reality and geophysics and biology manifests in natural disaster.
5.2.3.1 The Aral Sea.
5.2.4 Incongruence between financial consensus reality and economic and psychological reality manifests in financial crisis.
5.2.4.1 CDOs and CDSs.
5.2.4.2 South Sea Bubble.
5.2.4.3 Louisiana.
5.2.4.4 Tulips.

6. The siblings of consensus reality are the consensus future and the consensus past.
6.1 Revision is the change of the consensus past.
6.2 Changes to the consensus future feel like betrayal or relief.

Link From Twitter

Twitter have damaged their phone app by adding a feature. This is a problem software is particularly prone to, so let’s sift through it.

I was surprised to find Twitter useful. It had originally seemed a concentration of the least interesting ingredients of online culture: celebrities wittering moments from their shadow lives in a medium where smalltalk was enforced by a strict character limit. That’s not wrong, but it is incomplete. Twitter can be rendered functional, for me, by following interesting people, who link in depth, and by dropping anyone who emits more than two dozen undirected tweets in a week. 

Despite my faddish embrace of the medium du jour, two of the best discussion groups I am a part of are still closed mailing lists of mutual friends. It is also easy, with mail, to copy other random people that might care. This electronic mail thing really seems to have a future. Someone should look into that.

With this use pattern, and the primacy of the smartphone in a busy life, a fair proportion of the times I find something cool on twitter involves mailing a link.

Until recently, the email composed by twitter consisted of a link, my default signature, and an empty subject. This wasn’t great. Typing a subject, like typing anything on the phone, is a bit of a pain. Blankness is lousy microcontent, a terrible breach of information etiquette for a platform focused on short semantic bursts. Feedly – heck even Safari, dog that it is – at least has the sense to use the title of the web page in question.

Twitter fixed this bug. The latest version of the app sets email subjects to “Link from Twitter” and, as well as the link, adds a note to “Download the official Twitter app here. The fix of course is worse than the bug. Not having a subject just looks careless, like leaving your fly undone. “Link from Twitter” looks like somebody paid you €5 to tattoo an advertisement on your arse and then moon out car windows.

The time spent to delete that guff and replace it with something more meaningful is time wasted. Pretty much anything would be more meaningful to most recipients, who care about what was sent, not how it was sent. The empty subject is better. The subject “lol” would even be better, as at least it tells the audience about the content instead of whether it was sent by carrier pigeon or whichever. This is true even if you drink from the twitter firehouse; then you waste even more time.

If Twitter really thought it was important to squeeze some self-promotion into my email, they would find a way that added to my user experience. Why are people using the tool in the first place? It’s for snippets of content in a social network context. I don’t care that something came from Twitter, but I might care that it came from a particular user on Twitter. Maybe quote the tweet the link originated from, or mention the @user. Maybe link back to that tweet. Maybe I followed a few onward links, and am mailing that, so provide a breadcrumb trail of that history with a chain of vias. Do neat things that bring people into your conversation. Don’t make my email look like a spam. And don’t waste my time.