Category Archives: Information Metaphysics

Change Time

After some time trying to think about almost nothing, the last 24 hours have been an alarm call. As others come out of hibernation too, they post interesting stuff and Radio 4 provoked me with a discussion on facts and truth. Now Marc Cooper is at it, with difficult  links about computation and I’m all on Edge
Before I read about “discrete tensor networks”, I need to write down my own ideas about time, so I will know in the future what I thought, before my mind was changed.

I am ill-equipped for this task, having only 1 term of university maths to my name so I intend to talk in vague, abstract terms that are hard to argue with.

Much of physics is very dependent on Time, like almost all of computer science and business management theory. You can’t have change without time, it seems. Einstein talked about space-time, mostly in the language of mathematics. I can just about order a beer in math(s) but I can’t hold a whole conversation. I know what the first 3 dimensions are: left-right, up-down and back-forward. My personal model of the 4th dimension is that same space in continuous state-change through time. There are a few things I’m not happy about:

  • There is no evidence that time is either continuous or constant.
  • We only have evidence of time being a one-way dimension.
  • What the heck does ‘continous state-change’ mean? Is state a particle or a wave? Make your mind up, physics!
  • There’s that troubling many-worlds interpretation of the universal ‘WAVE’function (which I don’t understand either) which says that everything that might have happened did, in other universes. I don’t like this. Yes, that’s my entire justification – I don’t like the conclusion of a thought process I don’t even understand. It doesn’t feel right.

I’ve been learning about the functional programming language Clojure which does not ‘mutate (change) state’. It doesn’t have ‘variables’ like the more common imperative languages such as FORTRAN, BASIC, C, Java or Python. In Clojure, data flows through functions and is transformed from one form to another on the way. It is basically magic. In a pure functional program, no state is changed. State-change is called a “side-effect”. Sadly, side-effects are required to make a program do anything useful in the real world. Arguably, the purest magic is encapsulated in the world of mathematics and the physical world is a messy place that breaks things.

Clojure models time. It does not model the real world by replacing the current value in a variable and throwing the old value away but by chaining a new value onto the end of a list of all previous values.

Now let us extend this idea ‘slightly’ in a small thought-experiment, to a 3-D network of every particle state in the universe.

Space-time now has 2 regions:

  1. The past – all historic states of those particles as a theoretical chain of events
  2. The future – all possible future states of the universe; effectively an infinity of all possible future universes that could exist, starting from now.

Which brings us to what I mean by ‘now’ – a moving wave at the interface between the past and the future, annihilating possible future universes. Time becomes a consequence of the computation of the next set of states and the reason for it being a one-way street becomes obvious: the universe burned its bridges. Unless the universe kept a list, or we do, the past has gone. Time doesn’t need to be constant in different parts of the universe, unless the universe state ticks are synchronous but it seems likely to be resistant to discontinuities in the moving surface. I imagine a fishing net, pulled by current events.

It’s just an idea. Maybe you can’t have Time without change.

[ Please tell me if this isn’t an original idea, as I’m not very well read.
I made it up myself but I’m probably not the first. ]

A Functional Mindset

When I started learning Clojure, I thought I knew what functional programming was but I’ve learned that the functional paradigm is now more than I expected.

Everyone agrees that it’s a computational model based on evaluation of mathematical functions, which return values. This is generally contrasted with imperative programming languages such as FORTRAN, C, JavaScript or Python, which are also procedural and some of which are object-oriented but may make functional coding possible, in a hybrid style. I wouldn’t recommend learning functional concepts in a language that gives you short-cuts to stray back  to more familiar territory.

Clojure is a member of the Lisp family, first specified in 1958. The unusual feature of Lisps is their homoiconicity – code and data are the same thing. Learning Clojure has informed my thinking about business process change.

Some modern, functional languages such as Clojure use immutable data whenever possible, to eliminate side-effects. This allows better use of multi-core processors but requires a complete change in thinking, as well as programming style. ‘Variables’ are replaced by fixed ‘values’, so loops have to be replaced by recursive functions. New data can be created but it doesn’t replace old data. Yesterday’s “today’s date” isn’t automatically wiped when we decide today has happened.

Objects with their methods and local data were designed for simulating the current state of real-world objects by changing (mutating) object data state. The object model, like relational databases, has no inbuilt representation of time. Functional programming splits these objects back into separate functions and data structures and because values can’t change, they may be transformed by flowing through networks of functions, some recursive, to keep doing something until a condition is satisfied. Eventually, code must have a side effect, to tell us the answer.

Rather than computation being a conditional to-do list with data being moved between boxes, it becomes a flow of data through a network of ‘computing machines’; and the data and machines can be transformed into each other.

I hear that map, reduce & filter data transformation functions will change my world again.

My First Algorave


On Saturday night I went to ‘Algorave Birmingham’, curated  by Antonio Roberts at Vivid Projects. I said I might write ‘a review’ but I’m not going to, because I wouldn’t know how. This is ‘a reaction’ – a digital feedback loop, an emission from the event horizon (should have worn my ‘Big Bang’ T-Shirt – the noughties Brum band, not the nerd show.)

My background is information technology. My current work is writing. I use the word ‘work’ in the artistic sense: something I spend my time on but may never get paid for. Themes recur. Are science and art actually different things? Is maths real or a model? Is software any different to magic, existing only outside the physical realm and communicating via intermediary objects?

Q: How much can you strip away from music and it still exist as an idea: melody, scales, pitch?

I came to Algorave via my functional programming experiments. I’m trying to learn Clojure, a member of the Lisp family of languages but with added time-travel. It messes with whether time is a wave or a set of discrete steps that can be retraced. Not real time, obviously but the model of time our software deals with. Time travel outside of the magical realm would be crazy-talk.

Dance music is often first. Drum machines. I got really frustrated the first time I saw how hard it was to programme beats. Where was the programmatic interface? Sampling, pitch-shifting, the ‘sound’ being manipulated by code. Digits being manipulated by digits, like the higher order functions of functional programming. I wondered a few weeks ago if processors had got fast enough to generate live noises. They have. A Raspberry Pi has http://sonic-pI From there I discovered Clojure has, via ‘Overtone’ on ‘SuperCollider’, which resonates with my theory of a super-massive idea colider to mash-up memes.

Algorave Birmingham presented live coders generating sound and visuals. At times I felt that the graphics were pulsing to the beats but I don’t know if that really happened. I saw two pixelated women on the screen typing on ‘real’ laptops and a live drummer on digital drums. Virtuality virtuosos. I had a chat about how to make a hit record and forgot the name of the Kaiser Chiefs but remembered Black Wire who were the first band with a drum machine that I actually liked, because it didn’t sound mechanical, then The Kills who insisted everything was analogue, but now I’m looping.

A: I enjoyed the pulsing white noise. Software can do things that aren’t possible in Reality.

Moderately Grouped

One of the rules I try to live my life by is: “Small pieces, loosely joined”

Then this happened.

I don’t know who I am any more. I already feared de-selection from the cult of Unix and now this.

Then I realised that although I favour hi-fi separates, I don’t  design my own amplifiers and hand-wire the components. I don’t compile Linux from source every time. I’m not a fanatic.

Tooling-up for agile state-transition

This post started out in life as an answer to a question about ‘backlog tooling’ on the LinkedIn ‘Lean & Agile’ group. Someone had given the culturally acceptable answer that the best solution is simple cards or post-it notes on a board or wall. I normally just let that pass because I don’t have a better solution to offer but this time, THIS happened:

I’m about to be intentionally provocative. We know that we are engaged in transforming a multidimensional network of business functions from one poorly understood and transient state to another, currently ill-defined, future state that we hope will emerge from the mist as we travel in it’s general direction. In organisations of any size, this change process is likely to run in parallel with other change programmes, some of them probably deliberately kept secret by people whose pay grade exceeds their ability to make rational judgements about the basis of who “needs to know”.

Amongst this chaos, the chosen tool of ‘the Agile Community’ is a single, 2-dimensional view of a ‘list of lists’, sometimes known as ‘a tree’ or ‘a star’, all of which are topologically equivalent representations of items’ states in the backlog of each Product development. Our best software tools are little more than a model of cards on a board.

Why do we expect the complex, dynamic agile change process to map any more adequately onto a tree of cards than it does onto a hierarchical management structure? Have we learned nothing from our mistakes of modelling within the limitations of the filing cabinet and the typewriter? Perhaps agilists don’t value tools because our tools aren’t fit for purpose.

If all you have is lists representing vague descriptions of changes between two mental models you hope your whole team all share, perhaps the limited nature of the backlog tool isn’t your biggest problem. The backlog items reference changes to an implicit model of roles and the objects in the business domain of your product. My advice is to make it explicit.

Agile as something you do

I have spent the last 2 evenings in Birmingham listening to talks by @diaryofscrum at @ScrumUK and @stevejpitchford at @bcsbrum about management and ‘Agile’ software development, which brought some of my own concerns into sharper focus, particularly about the Scrum framework. In many discussions with practitioners over the last couple of years, I’ve heard the following phrases:

“Agile is an adjective not a verb”
“Agile isn’t something you do, it’s something you are”
“Agile is a philosophy not a method”
“Agile isn’t a process”

Someone who ISN’T agile has to start somewhere. They typically need to DO something, to write software. Would we claim,”Scientific” is an adjective not a method? We wouldn’t, because it is both. The scientific method is a function which delivers what we call “scientific knowledge” as its value. If it didn’t, it would be pointless.

Managers are generally trying to get things done. Each team must agree its own Agile Operating Model (thanks to BCS’s ‘Agile Foundations’ book for that useful phrase.) What came out of the last couple of evenings was pragmatic application of philosophy. Many organisations take Scrum as a starting point, without realizing that “framework” is to be taken very literally. Scrum doesn’t paint the complete picture. It is (part of) a process to organize work. It says almost nothing about how to do that work. It is an alternative to writing a project plan “up-front”, when you know least.

An Agile Operating Model is a process which delivers a value, so it is a function. My scientific hypothesis is that it delivers valuable business function change, sometimes in the form of software. It is itself a business function. Agility has business functions as first class citizens. It doesn’t meet general expectations of a process because it can recursively self-modify. That doesn’t mean it isn’t one. As the kids say, “get you an agile function that can do both”.

Practising your Process

My very sincere thanks to Simon Powers for posting the ‘onion diagram’ in his ‘What is Agile?’ post on LinkedIn and for answering my question. The post is also available on his own blog
It shows ‘tools & processes’ separate from ‘practices’. I’ve been thinking for a long time about whether there is any real difference between process (what) and procedure (how) or if they are simply different levels of detail. I think I’ve just been convinced that the equation I’ve been searching for is:

  • process + practises = procedure

Simon actually listed in his answer to me, ‘roles, interactions and artifacts’ as the difference between the set of Agile practices and the set of Agile processes, so I’ve corrupted his definition for my own purposes but I haven’t broken his diagram so I hope he’ll forgive me. (Or maybe I don’t understand whether the layers of an onion diagram are inclusive or exclusive.)

I think making the process one of the practises would make the function recursive and this is supposed to be one of my Lisp rest-days. If my process diagram shows roles or artifacts then I’m sure I’ve moved into the realm of specifying practice. Interactions may be input-output that is part of the definition of the process, so it is probably necessary to split them down more, into message type & format.