“Real Artists Ship”

Colin Johnson’s blog


Professional Practice

February 17th, 2017

Is there such a thing as a set of skills that apply across all of the professions? When I first started to come across (still rather rare) university departments of “professional practice”, I was bemused. Professional practice in what? Is there really enough common to being a nurse, barrister, dentist, accountant, town planner, occupational therapist, etc. etc. to call all of their activities “professional practice”? These seem, at least initially, to consist almost entirely of a lot of profession-specific skills/knowledge/understanding.

But, over time, I’ve started to wonder. Perhaps we are at the stage with professional practice schools that we were at with business schools a few decades ago. There was certainly a cynicism at one point that “business” could be taught generically. What business? Is there really enough in common to running a bassoon factory, a chain of gyms, an online career consultancy, an au pair agency, etc. etc. to call all of their activities “business”? At one point, these would have been seen as needing radically different skill-sets, but over time we have started to realise that some common understanding of finance, accountancy, PR, marketing, project management, strategy, staff appraisal, etc. are useful in all areas of business, alongside a knowledge of the specific business domain.

Perhaps there is something to be gained by bringing together dental nurses, architects, and solicitors for part of their education, and having some common core of education in e.g. dealing with clients. Perhaps the idea of a generic professional practice school isn’t such a ludicrous idea after all.

The Bleakest Shop in Christendom?

February 11th, 2017

A shop called “BARGAIN BOOZE” is pretty bleak, but at least you know what you are getting. To buy this shop, and decide to rebrand by covering up the word “Bargain” using parcel tape, and on another part of the sign tearing off the word “BARGAIN”, so that the shop is now simply called “BOOZE”, is distinctly more depressing. (This was in Sherwood; it has now all been refurbished!).

***** Booze

Contradiction in Law

February 11th, 2017

Why aren’t more legal-regulatory systems in conflict? A typical legal decision involves a number of different legal, contractual, and regulatory systems, each of which consists of thousands of statements of law and precedents, that latter only fuzzily fitting the current situation, with little meta-law to describe how these different systems and statements interact. Why, therefore, is it very rarely, if at all, that court cases and other legal decisions end up with a throwing up of hands and the judgement-makers saying “this says this, this says this, they contradict, therefore we cannot come to a well-defined decision”. Somehow, we avoid this situation—decisions are come to fairly definitively, albeit sometimes controversially. I cannot imagine that people framing laws and regulations have a sufficiently wide knowledge of the entire system to enable them to add decisions without contradiction. Perhaps something else is happening; the “frames” (in the sense of the frame problem in AI) are sufficiently constrained and non-interacting that it is possible to make statements without running the risk of contradiction elsewhere.

If we could understand this, could we learn something useful about how to build complex software systems?

Exciting News (1)

January 26th, 2017

First law of Exciting News: Inevitably, when you get an email from some company entitled “exciting news” it is going to contain an announcement that they have “merged with” (been taken over by) a “major partner” (a larger, rather more anonymous company), and that they are “looking forward to the opportunities that are offered by this exciting new development” (ready to make some more money from you by offering you a slightly diminished service level).

Combinations (1)

January 23rd, 2017

One of the points where mathematics and day-to-day intuitions jar is in estimating numbers of combinations and similar combinatorial problems. I’ve just made a booking on Eurostar, and my confirmation code is a 6-letter code. Surely, my intuitive brain says, this isn’t enough; all of those people going on all of those journeys on those really long trains, day-in, day-out. Yet there are a vast number of possibilities; with one letter of the 26 letter alphabet for each of the 6 letters in the code, there are 26^6=308,915,776 possible combinations. Given that there are 10 million Eurostar passengers each year, this is enough to allocate unique codes for passengers for around thirty years. It then make you wonder why some codes are so long, like the 90-digit MATLAB registration code that I had to type in by hand a couple of years ago.

Vagueness (1)

January 19th, 2017

Love it that this bookshop in Margate manages to divide books into three categories: “General Interest”, “Extra Stock” and “Whatever” (there are some other shelves with more specific categories).

General Interest

Extra Stock

Whatever

Thinking about bookshops and their categorisation schemes reminds me of a bookshop from years ago on Queen’s Road in Brighton, just down from the station, which had, in addition to books on the shelves, large piles of books in the middle of the floor as if dumped there by a dumper truck. At the back of the shop, there was a shelf of pornographic books; in place of the usual bookseller euphemism of “Erotica” as a header for the section, this shop had plumped for the rather more direct word “Filth”.

Amazingly I have just found a picture of that very shop, and an article from The Argus about its closure (well, abandonment) in 2002; the wonders of the interweb, eh?

Ironic (1)

January 16th, 2017

"For years now, I've been doing the same presentation on change for

(actually from quite an interesting article: Lessons from the A47 and the University Bubble.

Kruft (1)

November 20th, 2016

I often refer to the process of taking the content that I want to communicate and putting it into the 200-by-300 pixel box reserved for content in the middle of our University’s webpages as “putting the clutter in”. I get the impression that my colleagues on the Marketing and Communication team don’t quite see it this way.

Mistypings

November 17th, 2016

Been doing quite a bit of python programming this week. So far I have managed to mistype python as:

  • pyhton
  • phythion
  • phtyton
  • phtyon
  • phytion
  • pthyon
  • phyton
  • pytohn

Feedback (1)

November 6th, 2016

Bought the an album called Sex from Amazon a few days ago (by the excellent jazz trio The Necks). Inevitably, this caused the following request for feedback to appear in my inbox a few days later:

"Colin, did 'Sex' meet your expectations? Review it on  amazon.co.uk

Followed, inevitably, by the following when I next went onto the Amazon website:

You purchased: Sex (Used)

Mental Blocks

October 27th, 2016

We all seem to have tiny little mental blocks, micro-aphasias, things that we, try as dammit, cannot learn. My mother couldn’t remember the word “volcano”—she was a perfectly fluent native speaker of English, with no other language difficulties, but whenever she came to that word it was always “one of those mountain-things with smoke coming out of the top” or similar, followed by several seconds until the word came to her. I have a block on the ideas of “horizontal” and “vertical”. Whenever I read these, I feel my mind blurring; I know which two concepts they map on to, but for a second or two (which feels like an eternity in the usual flow of thought) I cannot fluently map the words onto the concepts. Usually I break the fog by making a gesture with my fingers—somehow, this change of mode (moving my fingers from left to right strongly associates with the word “horizontal”) dispels the confusion, it must trigger a different part of my memory associations. Quite where these odd little blocks come from—and, why we can’t just learn them away—is fascinating.

Casual Swearing (1)

October 25th, 2016

I like the casual use of—often rather strong—swearing in very day-to-day situations. Last night, there was a small group of people standing outside the Sainsbury’s Local on the corner. The following conversation took place:

- Have you got the hummus?
- Yeah, sure.
- Thank fuck.

The singsongy rhythm of the last couple of phrases was particularly neat.

Interesting/Plausible

September 30th, 2016

A useful thought-tool that I learned from Tassos Stevens: “It is easier to make the interesting plausible, than the plausible interesting.”.

Family Stories (3)

September 26th, 2016

When I was around 10-11 years old, my parents made a shed at the back of the garden, by putting a door and roof on a small space at the back of the garage. This was used to store gardening supplies—compost, plant pots and the like—and bottles of the dubious home-made wine and beer that was popular at the time.

One summer day I decided, on a whim, that this needed a label putting on it. So, using a chisel and hammer from the garage, I gouged the words “TOOL SHED” into the paint and wood, fairly deeply. Then, realising that the shed wasn’t used to store tools, I panicked; but a simple solution came to mind. As a result I carved the word “NOT” above the word “TOOL SHED”, with an asterisk added to retain the symmetry of four letters on each line. As a result, the shed had (and retained for several years) the label:

*NOT
TOOL
SHED

and was thus referred to in my family for many years subsequently.

I believe that I am the only person alive who remembers this.

Verboten (1)

September 22nd, 2016

I like the literalism of this graphic from Dreamland at Margate, particularly the one depicting “May cause motion sickness”:

Dreamland ride restrictions graphic

Public/Private

September 12th, 2016

In the public sector, we are oft being urged to emulate the supposed good practices of the private sector. According to Liam Fox, these include being fat, lazy, and playing golf on Friday afternoons. Should I be writing these practices into our latest strategy document?

“How are you?”

September 12th, 2016

It sometimes surprises me quite how formulaic the smalltalk at the beginnings of conversations is. I know that it isn’t acceptable to respond to the question “How are you?” with a list of your latest ailments and insecurities, but it is still sometimes surprising how much that part of a conversation is a cognitive readymade, without any ready deviation. I remember a couple of incidents in the days after my father died.

  1. Meeting a colleague a few days after my father had died. Wanting, gradually, to let people know what had happened, I responded to his “How are you?” with a “Actually, not so good.”, expecting to get a query back about what had happened. Instead, I just got the response “Great, I’m fine.”, as if I had said (as I would 99.9999% of the time) “I’m fine, how are you?”. Literally, my response hadn’t been processed at all. If you want some evidence for hearing being a process of anticipation then you’ve got it there. There’s no other response in the “repertoire” to “How are you?” other than minor variants on “Fine, how are you?”, so the brain doesn’t even really bother processing what has been said. Any response is just treated as the standard one.
  2. Speaking to my uncle a day or two after my father had died (I had already told my uncle). This time, he asked first: “How are you?”. My response, understandably: “Not too good.”. My uncle’s response—no criticism intended, this is just a point about how deeply embedded language structures are—”Oh, why is that then?”. I was, very unusually, struck dumb for a few seconds. For a moment I thought “Perhaps I didn’t tell him that Dad had died?”; for surely, someone wouldn’t say something so crass to someone who had just lost a parent—surely it would be obvious why I “wasn’t too good”. Eventually, I managed to stutter out “Well, you know, Dad died yesterday.” It is bizarre how fixed our linguistic patterns are that, even after one of the worst things that can happen to you, saying that you are anything other than “fine” causes our whole language generation system to collapse.

Doppleganger (1)

September 9th, 2016

On this week’s Only Connect, there was a beardy chap with glasses who described himself as “having a maths degree and playing the bassoon and cello” who was on a team defined by their liking for Indian food. I had to check for a moment that I hadn’t accidentally appeared on the programme and forgotten all about it.

The Fallacy of Formal Representations

September 9th, 2016

I went to an interesting talk by Jens Krinke earlier this week at UCL (the video will eventually be on that page). The talk was about work by him and his colleagues on observation-based program slicing. The general idea of program slicing is to take a variable value (or, indeed any state description) at a particular point in a program, and remove parts of the program that could not affect that particular value. This is useful, e.g. for debugging code—it allows you to look at just those statements that are influential on a statement that is outputting an undesirable value—and for other applications such as investigating how closely-coupled code is, helping to split code into meaningful sub-systems, and code specialisation.

The typical methods used in slicing are to use some formal model of dependencies in a language to eliminate statements. A digraph of dependencies is built, and paths that don’t eventually lead to the node of interest are eliminated. This had had some successes, but as Jens pointed out in his talk, progress on this has largely stalled for the last decade. The formal models of dependency that we currently have only allow us to discover certain kinds of dependency, and also using a slicer on a particular program needs a particular model of the language’s semantics to be available. This latter point is particularly salient in the contemporary computing environment, where “programs” are typically built up from a number of cooperating systems, each of which might be written in a different language or framework. In order to slice the whole system, a consistent, multi-language framework would need to be available.

As a contrast to this, he proposed an empirical approach. Rather than taking the basic unit as being a “statement” in the language, take it as a line of code; in most languages these are largely co-incident. Then, work through the program, deleting lines one-by-one, recompiling, and checking whether the elimination of that line makes a difference in practice to the output on a large, comprehensive set of inputs (this over-simplifies the process of creating that input test set, as programs can be complex entities where producing a thorough set of input examples can be difficult, as sometimes a very specific set of inputs is needed to generate a specific behaviour later in the execution; nonetheless, techniques exist for building such sets). This process is repeated until a fix point is found—i.e. none of the eliminations in the current round made a difference to the output behaviour for that specific input set. Therefore, this can be applied to a wide variety of different languages; there is no dependency on a model of the language semantics, all that is needed is access to the source code and a compiler. This enables the use of this on many different kinds of computer systems. For example, in the talk, an example of using it to slice a program in a graphics-description language was given, asking the question “what parts of the code are used in producing this sub-section of the diagram?”.

Of course, there is a cost to pay for this. That cost is the lack of formal guarantee of correctness across the input space. By using only a sample of the inputs, there is a possibility that some behaviour was missed. By contrast, methods that work with a formal model of dependencies make a conservative guarantee that regardless of inputs, the slice will be correct. Clearly, this is better. But, there are limits to what can be achieved using those methods too; by using a model that only allows the elimination of a statement if it is guaranteed under that model to never have a dependency, it ignores two situations. The first of these is that the model is not powerful enough to recognise a particular dependency, even though it is formally true (this kind of thing crops up all over the place; I remember getting frustrated with the Java compiler, which used to complain that a particular variable value “might not have been initialised” when it was completely obvious that it must have been; e.g. in the situation where a variable was declared before an if statement and then given a value in both possible branches, and then used afterward that statement). The second—and it depends on the application as to whether this matters—is that perhaps a formal dependency might crop up so infrequently as to not matter in practice. By taking an empirical approach, we observe programs as they are being run, rather than how they could be run, and perhaps therefore find a more rapid route to e.g. bug-finding.

In the question session after the talk, one member of the audience (sorry, didn’t notice who it was) declared that they found this approach “depressing”. Not, “wrong” (though other people may have thought that). The source of the depression, I would contend, is what I will call the fallacy of formal representations. There is a sense that permeates computer science that because we have an underlying formal representation for our topic of study, we ought to be doing nothing other than producing tools and techniques that work on that formal representation. Empirical techniques are both dangerous—they produce results that cannot be guaranteed, mathematically, to hold—and a waste of time—we ought to be spending our time producing better techniques that formally analyse the underlying representation, and that it is a waste of time to piss around with empirical techniques, because eventually they will be supplanted by formal techniques.

I would disagree with this. “Eventually” is a long time, and some areas have just stalled—for want of better models, or just in terms of practical application to programs/systems of a meaningful size. There is a lot of code that doesn’t require the level of guarantee that the formal techniques provide, and we are holding ourselves up as a useful discipline if we focus purely on techniques that are appropriate for safety-critical systems, and dismiss techniques that are appropriate, for, say, the vast majority of the million+ apps in the app store.

Other areas of study—let’s call them “science”—are not held up by the same mental blockage. Biology and physics, for example, don’t throw their hands up in the air and say “nothing can be done”, “we’ll never really understand this”, just because there isn’t an underlying, complete set of scientific laws available a priori. Instead, a primary subject of study in those areas is the discovery of those laws, or at least useful approximations thereto. Indeed, the development of empirical techniques to discover new things about the phenomena under study is an important part of these subject areas, to the extent that Nobel Prizes have been won (e.g. 1977; 2003; 1979; 2012; 2005) for the development of various measurement and observation techniques to get a better insight into physical or biological phenomena.

We should be taking—alongside the more formal approaches—an attitude similar to this in computer science. Yes, many times we can gain a lot by looking at the underlying formal representations that produce e.g. program behaviour. But in many cases, we would be better served by taking these behaviours as data and applying the increasingly powerful data science techniques that we have to develop an understanding of them. We are good at advocating the use of data science in other areas of study; less good at taking those techniques and applying them to our own area. I would contend that the fallacy of formal representations is exactly the reason behind this; because we have access to that underlying level, we cannot convince ourselves that, with sufficient thought and care, we cannot extract the information that we need from ratiocination about that material, rather than “resorting” to looking at the resulting in an empirical way. This also prevents the development of good intermediate techniques, e.g. those that use ideas such as interval arithmetic and qualitative reasoning to analyse systems.

Mathematics has a similar problem. We are accustomed to working with proofs—and rightly so, these are the bedrock of what makes mathematics mathematics—and also with informal, sketched examples in textbooks and talks. But, we lack an intermediate level of “data rich mathematics”, which starts from formal definitions, and uses them to produce lots of examples of the objects/processes in question, to be subsequently analysed empirically, in a data-rich way, and then used as the inspiration for future proofs, conjectures and counterexamples. We have failed, again due to the fallacy of formal representations, to develop a good experimental methodology for mathematics.

It is interesting to wonder why empirical techniques are so successful in the natural sciences, yet are treated with at best a feeling of depressed compromise, at worst complete disdain, in computer science. One issue seems to be the brittleness of computer systems. We resort (ha!) to formal techniques because there is a feeling that “things could slip through the net” if we use empirical techniques. This seems to be much less the case in, say, biological sciences. Biologists will, for example, be confident what they have mapped out a signalling pathway fairly accurately having done experiments on, say, a few hundred cells. Engineers will feel that they understand the behaviour of some material having carefully analysed a few dozen samples. There isn’t the same worry that, for example, there is some critical tight temperature range, environmental condition, or similar, that could cause the whole system to behave in a radically different way. Something about programs feels much more brittle; you just need the right (wrong!) state to be reached for the whole system to change its behaviour. This is the blessing and the curse of computer programming; you can do anything, but you can also do anything, perhaps by accident. A state that is more-or-less the same as another state can be transformed into something radically different by a single line of code, which might leave the first state untouched (think about a divide-by-zero error).

Perhaps, then, the fault is with language design, or programming practice. We are stuck with practices from an era where every line of code mattered (in memory cost or execution time), so we feel the need to write very tight, brittle code. Could we redesign languages so that they don’t have this brittleness, thus obviating the need for the formal analysis methods that are there primarily to capture the behaviours that don’t occur with “typical” inputs. What if we could be confident—even, perhaps, mathematically sures—that there were no weird pathological routes through code? Alternatively, what if throwing more code at a problem actually made us more confident of it working well; rather than having tight single paths through code, have the same “behaviour” carried out and checked by a large number of concurrent processes that interact in a way that don’t have the dependencies of traditional concurrency models (when was the last time that a biosystem deadlocked, or a piece of particle physics, for that matter?). What if each time we added a new piece of code to a system, we felt that we were adding something of value that interacted in only a positive way with the remainder of the code, rather than fearing that we have opened up some kind of potential interaction or dependency that will cause the system to fail. What if a million lines of code couldn’t be wrong?

Sofa-ry, so good-y

September 8th, 2016

I have my own sofa, courtesy of Habitat:

Colin: 3 seater charcoal fabric sofa

(Bonus points to anyone who can get the origins of the pun in the title.)