Clockwork to Complexity: scale in time and software
Software is completely clockwork at the scale of one function, and completely complex in production.
functional
What functional programming and secure code have in common
As a programmer, especially a strong-typing functional programmer, I love abstraction. Defining what the program does and expressing that cleanly in code. The code should express little else. Now I’m studying secure code, and it is the opposite. It’s all about what can happen, not what should. So many nitty-gritty details of network protocols, memory … Read moreWhat functional programming and secure code have in common
One Secret to Quality Software
They ask us for quality. What is “quality”? “Well, free of defects.” (Oh it’s a lot more than that.) What is a “defect”? “Well, when it doesn’t work like we expect it to. Like we agreed it should.” Trust me, you didn’t specify how it works. That’s my job, as a developer. To organize all … Read moreOne Secret to Quality Software
Complication for the win
I don’t want to make my programs simpler. I want to them make them complicated instead of complex.
In defense of rationality and dynamic programming
Karl Popper defines rationality as: basing beliefs on logical arguments and evidence. Irrationality is everything else. He also defines comprehensive rationality as: only logical arguments and evidence are valid basis for belief. But this belief itself can only be accepted by choice or faith, so comprehensive rationality is self-contradictory. It also excludes a lot of … Read moreIn defense of rationality and dynamic programming
Every action has two results (Erlang edition)
Every action has two results: a set of side effects on the world, and the next version of ourselves. I learned this from Erlang, a purely functional yet stateful programming language. Erlang uses actor-based concurrency. The language is fully immutable, yet the programs are not: every time an actor receives a message, it can send … Read moreEvery action has two results (Erlang edition)
Mostly we orient
Observe, Orient, Decide, Act. This is the OODA loop, first recognized in fighter pilots and then in the Toyota Production System. It represents every choice of action in humans and higher level systems: take in sensory data, form a model of the world, choose the next action, make a change in the world. At least … Read moreMostly we orient
For cleaner code, write ugly code
We want to write only clean code, right? Wrong. I want to write eventually-clean code. It starts exploring a space, and then I refine it to be cleaner and more suited to purpose. Usually, that purpose becomes clearer through writing, reading, and using the code. That process of refining or tidying up can feel tedious, … Read moreFor cleaner code, write ugly code
Provenance and causality in distributed systems
Can you take a piece of data in your system and say what version of code put it in there, based on what messages from other systems? and what information a human viewed before triggering an action? Me neither. Why is this acceptable? (because we’re used to it.)We could make this possible. We could trace … Read moreProvenance and causality in distributed systems
Harder and better (slides)
At Scenic City Summit in Chattanooga last week, I gave a closing keynote about 3 ways our jobs are harder than they used to be, and how each of these makes our jobs better. Annotated slides are on Dropbox.