The Physics of Software Development

An Educational Conundrum

When I first started university I was conflicted as to my choice of major. I knew I enjoyed tinkering with computers and was enticed with the idea of having what I wrote interpreted by a solid logic machine, rather than solely by soft messy biological ones. But I also loved physics, and the way we could see such order in such a seemingly uncontrolled system as the universe to the extent we could not only interpret the laws which control it, but rely on them so heavily as to propel ourselves across it, fascinated me. So I hedged. I took a mixture of both Computer Science and Physics papers, and although I eventually dropped the Physics and stuck with coding, I couldn't help but notice the similarities between the two disciplines, and how readily physical laws (with a generous amount of satirical manipulation) could be applied to all aspects of the SDLC.

Schrödinger's Thought Experiment

Erwin Schrödinger was a Austrian physicist with an apparent penchant for animal cruelty. He devised a famous thought experiment where an innocent member of the feline persuasion was locked in a steel box. Also in this box was a radioactive atom which would, should it decay, trigger the release of a poison and the cat would meet its unfortunate and unwarranted demise. At any given time, the chance of the atom having decayed, the poison being released, and the unfortunate puss passing over to the great scratching post in the sky is odds even to this undesirable event not having occurred. Schrödinger devised this experiment to highlight the absurdity of the existing view of quantum mechanics, which stated that while the condition of the cat remained unknown, it existed simultaneously in both the alive and dead states (a quantum zombie cat) until it was observed to be definitely deceased or still healthy.

This whole macabre experiment would have been a lot less disturbing if the box containing the cat had a observation window built into it. This way, although the cats ultimate demise remains unchanged, it can be fully observed at all stages, thus dramatically reducing the likelihood of an un-dead tabby developing a taste for kitty brains. A similar principle applies to production systems. The cat represents our running code that we very much want to stay alive. The radioactive atom is a defect, a network glitch, or an environmental instability which threats to pop at any-time taking down the running system. We could leave this as a black box, with no idea as to whether the code is alive or dead, until an end user rings to complain that their connecting applications are no longer working. End users notifying you of your code not working is a Bad Thing. It would be much better to build observability into the platform, to provide automated and proactive system monitoring, to generate alerts when the atom looks like it's getting unstable so the cat can be pre-emptively provided with a gas mask until funds exist to relocate it to a safer environment.

The Second Law of Thermodynamics

The second law of thermodynamics states that in an isolated system the total entropy (disorder) cannot decrease, it can only irreversibly increase, or in an ideal system remain at equilibrium. A software system is not immune to entropy. Think of a project or a feature which is just beginning its testing phase. As bugs are discovered, developers will go in and fix the bugs. Without strict discipline, eventually compromises will be made, workarounds taken and band-aids applied. The program, which once revelled in its beautiful simplicity, starts to resemble a game of Kerplunk nearing its final phase where one more turn threatens to bring the whole thing crashing down.

This time, though, these are not the ravings of a madman. Or at least, they are not only the ravings of a madman, because software entropy is a Real Thing. This is a brilliant article I have read, which very intelligently explains not only what software entropy is, using illustrations and analogies, but also provides practical advise on how to prevent it. As such I will bring a halt to my ranting on the topic here, because someone else has said it already, and said it much more lucidly than I could ever manage.

E = mc²

Undoubtedly the most famous and recognisable equation there is, the boffin that was Albert Einstein showed that mass and energy were so closely bound that they could be expressed in terms of each other with the speed of light as a related constant. It also shows the phenomenal amount of energy required to create even the smallest amount of matter. Say we wanted to magic up just a single gram of cheese, we plug that into the equation as m = 0.001. Somewhat less intuitively c represents the speed of light, which is a constant. This means that c² is also a constant, namely 89,875,517,873,681,764(m/s)². Running that through the calculator indicates that our miserly piece of cheese, which wouldn't satisfy a mouse who had just enjoyed the leftovers from a vegan party at a farmers market, would require just a fraction below 90 TJ of energy. To put that in perspective, less energy was released by either of the nuclear warheads dropped by the US at the end of WWII. All for your pathetic piece of curdled milk.

It occurred to me that a similar formula could be used for estimating effort. It is well documented that developers are bad at estimating the time required to develop a feature, fix a defect or finish a project, usually coming up with a drastically optimistic date which will then inevitably causes tension with management and clients when deadlines start slipping faster than a greased pig down a water slide. Various equations based on prime numbers or the Fibonacci sequence have been proposed, but until today I haven't seen any that use the theory of mass-energy equivalence. There may be a reason for this, but I'm going to dive in regardless. The signature of the equation will remain the same, E = mc². However, E now represents the estimation of effort (in seconds, remember this is based on physics - all time is measured in seconds), m is the mass of the printed requirements/defects (in kgs) and c remains the constant speed of light. You don't mess around with c.

I can apply this to a project I worked on a while ago. The total requirements managed to fit onto three lines of an A4 document, which when printed and cropped weighed 0.5 grams, or 0.0005 kgs. We plug this into our new and improved time estimation formula and solve for E. Doing so, we arrive at an estimate of 1.5 million years to complete this project. This may seem a touch on the high side, even for the most cautious of delivery leads with a history of being burned by overly idealistic developers. However, having such a seemingly pessimistic approach to project estimates ensures that angry emails regarding missed deadlines will become a thing of the past (or at the very worst a thing of the very distant future), and only the most long term clients will agree to your time-lines. This means you avoid the tyre-kickers and time wasters all together, and will be free to focus on producing quality results rather than being forced into blisteringly fast sprints where the focus is on quantity rather than quality.