Impulse response programming

In signal processing and filter design there is the notion of a linear system. The nice thing about linear systems is that they can be safely analyzed by just poking and prodding them with an impulse. You push a certain form of signal through the system and observe the output and if for signal s you get output o then by linearity you can conclude that 2s will lead to 2o. Basically, linear systems are nice because you can add and scale inputs and expect the outputs to also add and scale appropriately. The trouble is that the world is not linear and all our intuitions fail us when dealing with non-linear systems. This is especially problematic in software because the scale of the complexity makes the systems we deal with essentially black boxes and the only view we have into them is by poking and prodding them with impulses that we understand and then assuming some kind of linearity. An anecdote from work about Docker and LXC follows. Continue reading

Agile is pigeons dancing on one leg

There are some things that people don’t like to think about. There is no particular reason they don’t like to think about those things. It’s simply because their parents didn’t think those things and through luck and chance that bias was propagated to the next generation. This happens in nature all the time. Just because something is passed on to the next generation doesn’t mean it was useful or adaptive in any way, it could just have been some random structural property that resulted from a confluence of other things. This is very vague but the point I’m trying to get across is that people have a propensity to see patterns where there are none and sometimes they will carry on believing something completely random because random good things happened to them when they believed those things. So through the power of associations those random beliefs were associated with good things even though if you could zoom out and do the proper statistical analysis it would all look like noise. Now couple this with under-constrained systems like we see in software all the time and it is a recipe for a pretty hilarious disaster. Continue reading

Software hostility pt. 2

So today I had an idea about figuring out what is what on my laptop and immediately I hit a brick wall: nothing on my computer has provenance. What do I mean by that? I mean there is no way to trace anything on the filesystem in a way that has semantic meaning. Linux can’t tell me where each file came from, why it is there, what other programs rely on that file, in what way they rely on that file, is the file a meaningful component in some other collection of files, and basically a million other questions that have no sensible answers. Continue reading

Software hostility

All the tools I use are actively user hostile but I’ve gotten used to all the hostility and have basically developed Stockholm syndrome. Every so often I have moments of clarity and I wonder if we are insane for having gotten to this state of affairs without wondering if there was a better way. Consider the following example. Continue reading

Cybernetics of software

Recently I was thinking about how to properly structure software systems to reduce the cognitive burden on the people using and managing those systems as much as possible. The more I dug into the idea the more it became obvious that this is already a solved problem but there isn’t enough mindshare around the solution. The proper solution already exists under the heading of hierarchical planning and process control. An example from a domain I’m familiar with to demonstrate: build systems, release engineering, and in general, infrastructure software. Continue reading