S. P. Havens Consulting

Software and information systems specialists

The Extended Mind Thesis, or EMT, is the proposal that the human mind isn’t limited to “stuff happening in your brain”, but includes parts of the external world, including tools that assist in cognitive processing. Andy Clark and David Chalmers famously[1] argued that, as far as the definition of ‘the mind’ is concerned in the following scenarios, there’s no qualitative difference between:

  • counting on one’s fingers versus counting in one’s head,
  • multiplying with a hand-held calculator versus a calculator jacked directly to the brain, or
  • memorizing a set of directions versus an amnesiac writing it down in a notebook.

Let’s assume you’ve read the paper, put some thought into it, and are convinced — you buy that your mind isn’t 100% contained within your skull. Should you accept that your mind extends out even as far as, say, the Internet? Clark and Chalmers anticipated this question. In 1998, they found it implausible, because the Internet wasn’t ubiquitous and it would be unusual for someone to rely on it to the same extent as the amnesiac’s notebook. Fifteen years later, though, we’re in the age of Google, of the cloud, of a smartphone in every pocket. It’s hard to argue that Internet-based tools wouldn’t be subsumed in the EMT nowadays.

At this point, if you’ve kept up with current events at all, you already realize where I’m going with my titular claim of psychics in the employ of the state. But let’s take a minute to run a thought experiment.

Imagine a government agency that secretly has developed the ability to telepathically listen to and record your mental processes. If you, for example:

  1. Realize you’re pregnant
  2. Calculate the due date for your pregnancy
  3. Decide your budget for next several months
  4. Make a mental note to pick up something from the store
  5. Think about all the other errands you need to run
  6. Figure out the most efficient way to get to all the stores today
  7. Wonder if you’ll have time to see a movie tonight
  8. Try to remember the name of a movie you saw last year
  9. Fantasize about a celebrity from that movie

Then this agency, with its mind reading capability, would have recorded all of it. Presumably such an agency does not exist, so let’s just call it No Such Agency, or NSA for short. If this NSA’s activities ever came to light, I suspect most people would find it morally repugnant, no matter how noble an excuse government officials offered.

Here’s the rub: If you’ve been following current events about the government’s surveillance activities, and you accept the EMT, then this isn’t just a thought experiment to you. Our cognitive processes, our thoughts, our minds are literally being read when we do a web search, set a calendar reminder for ourselves, or create a todo list saved in the cloud.

Michael P. Lynch wrote recently about how government invasions of privacy can be dehumanizing and strip people of their autonomy. For those who accept the EMT, you don’t have to settle for abstract concerns about ‘autonomy’. You arrive straight at a concrete, “crazy-but-true” conclusion: government psychics are reading our minds.

[1] Famous is relative when we’re talking cognitive philosophy.

2011.09 smoothie
Photo of fruit in blender by Sigurdas [CC-BY-SA-3.0], via Wikimedia Commons

Many years ago, there was a wealthy family in poor health. The local doctor examined them and discovered to his surprise that the entire family showed symptoms of scurvy.  The family had no fruit in their diets.  The doctor’s prescription was simple:  eat more fruit.  As the wealthy family didn’t prepare their own meals, this order was passed to the family’s household staff.

The family’s butler was in charge of both the pantry and all the male staff.  The butler instructed the errand boy that, from now on, he would need to procure fresh fruit on his trips to the market.  Further, the errand boy should check with the cook every morning before leaving for the market to learn what fruits would be needed that day.

Image by Sigurdas via WikiCommons

The errand boy tracked down the family cook and asked her for a list of what fruit would be needed for upcoming recipes.  The cook was unaccustomed to using fruit in dishes for the family, and did not have a list prepared.   Then, she recalled hearing about a new fad: the “fruit smoothie” consisting solely of blended fruit.   The cook told the errand boy not to worry about locating her and asking for a new list every day; instead, he could just pick up whatever fruit looked the freshest.  In return for that saved time, upon returning to the household, the errand boy would just need to put the fruit in a blender and then transfer the blended fruit to jugs in the cooler.

This arrangement was agreeable to all. Fruit was selected every day, blended into smoothies, stored in the cooler, and served to the family with their meals.  The family’s health improved and they enjoyed smoothies for many years.

Image via Wikipedia

After a while, though, the oldest daughter, Mary, developed a chronic rash.  The doctor ran some tests and declared that Mary was allergic to melons in the smoothie.  A kitchen maid was assigned to taste Mary’s smoothies for any hint of melon flavor before serving them, and Mary’s health was rapidly restored.

Image from http://freefoto.com

One night, the middle daughter, Edith, became deathly ill; she could barely breathe, her heart was pounding, and she was too dizzy to stand.  The family, scared they might lose their daughter, immediately contacted the doctor. The doctor was able to treat Edith and warned the family that this was another allergic reaction. Tests showed that the cause, in this case, was pineapple in the smoothie, and another exposure could kill Edith.  Even though pineapple was exceedingly rare, just having a kitchen maid taste the smoothies for pineapple wouldn’t be enough to guarantee the daughter’s safety.  Trace amounts could go undetected by a maid but prove fatal to poor Edith.

Luckily, the doctor knew of an easy-to-use test for even small amounts of pineapple.  Just mix a bit of the smoothie with a drop of this chemical, and the resulting color would warn of any danger.  It was easy to ask another kitchen maid to run the test before serving the smoothies.  Once again, the family was assured of their good health.

Apple pie

Image via Dan Parsons

A few months later, the family was hosting guests, who expressed a sudden desire for apple pie.  The cook was notified and nearly panicked at the request — the pantry was devoid of apples, and the market was closed for the day.  However, the cooler was full of smoothies, which had apple pieces in them.  All the kitchen staff jumped in to help, pouring the smoothies through strainers and picking through the chunks for pieces of apple.  Finally, enough suitable apple chunks were collected, the pie was successfully baked, and the entire family and their guests praised the kitchen’s quick thinking, hard work, and delicious results.

The apple pie was such a smash that the family soon began requesting all sorts of fruit-based desserts.  The kitchen staff already had their own duties, but the varying fruit desserts were so popular that the cook easily convinced the head of the household to hire more staff to handle the daily work of straining and separating the smoothies.  A whole room was set aside for just this activity, but it was worth it for the exquisite dishes the cook had learned to prepare for the family.

Even so, the family’s increasing demands made it hard to keep up.  Guests attended nearly every meal; banquets were held honoring war heroes and raising funds for charities.  Fruits were the main ingredients in novel dishes of all shapes, sizes, and flavors.  The cook pleaded with the family on behalf of the entire kitchen staff, and the family in turn acknowledged the overwhelming workload.  They hired a team of scientists and engineers to design and build a machine that could strain the smoothies, separate the juices, and in some cases even reconstitute the entire original fruit.

Electron microscope

Photo by dpape, 2009. Creative Commons Licence. http://www.flickr.com/photos/dpape/4057926815/

So, yet more rooms were set aside for this new team. They worked side by side with all the kitchen staff to duplicate the straining techniques perfected through years of training and practice.  Centrifuges were brought to separate the juice components. Microscopes analyzed how bits of peel could fit together. Meticulously detailed catalogs were written describing how pulps, cores, peels, and pits differ among farms just so that all the rebuilt fruit could exactly match the original.

It was difficult, painstaking work, requiring the intense focus of dozens of people for many years, but every day the team came a little bit closer to their holy grail: unblending the smoothie.

And for all those years, the errand boy did the same chore every day.  He returned from the market, dutifully dumped the entire basket of fresh fruit into a blender for half a minute, poured the resulting smoothie into jugs, and placed them in the cooler.

Blueberry smoothie

Image licensed under Creative Commons

If it’s so fragile that you can’t change it, then you must change it.

A graph of developer output vs the ability of a manual tester to test it

Graph of automated testing and manual testing

Cormac Herley of Microsoft Research recently published a paper titled, “So Long, and No Thanks for all the Externalities,” in which he argues that the common situation of users ignoring or bypassing computer security measures is economically rational, and that many of these security measures may hurt more than they help. He also suggests a calculus that can be used to find, if not a precise balance between policies that help and hurt’ at least the bounds for what options should be considered.

Herley makes several excellent points about how the economic cost of security policies is frequently ignored, and I believe that, within certain constraints, his suggested calculus is helpful for evaluating the benefits and costs of these policies. Further, I strongly suspect his broader conclusion is correct, and many security policies produce a net harm. Note, however, I said that the applicability of his calculus has constraints — Herley does not explicitly identify these constraints, and thus misapplies his own calculus. The examples Herley provides are faulty and cannot be used in support of his conclusion.

A quick summary of Herley’s calculus

Herley suggests all potential security policies be evaluated in terms of their cost compared to the maximum potential benefit they could possibly provide. He makes clear that the upper bound for this benefit is the total direct losses due to the particular type of attack that the security policy is supposed to mitigate. For example, the total losses a company suffers due to dictionary attacks on passwords may be $50 million. If this is the case, then a potential security policy intended to mitigate password attacks should have a total cost of no more than $50 million — even if you assume the policy is 100% effective, it would still be costing more than it saves.

The calculus works here. It assumes that implementing a proposed security policy will lower the total direct loss — in other words, if you are losing $50 million now to dictionary attacks, after putting the policy in place you will be losing somewhere between $0 and $50 million due to those attacks. $50 million is, thus, an effective upper bound for what a proposed policy could help.

Where Herley goes wrong

Herley makes his big mistake when he tries to work the other way, and discusses policies that are already in place. He claims that the economic cost of the extant policies should be less than the current losses in order to make sense. However, what was an upper bound when considering hypothetical policies becomes a lower bound for existing policies. Consider: If you are losing $50 million on dictionary attacks with your current password policies, making those policies more lax will increase your losses. It could be $100 million, or $1 billion, or more. $50 million is the minimum you lose when you loosen your security policies.

This is a critical mistake to make, and unfortunately Herley’s examples rely on it heavily. For example:

“However, the Paypal CISO [5] states that “Forty-one basis points is the total fraud number” on Paypal’s system. Thus 0.49% of Paypal’s Transaction Volume, or $290 million, would appear to upper bound all of the password related attacks. Given that Paypal had 70 million active users in 2008, all of the annual security advice should consume no more than $290/70 = $4.14
or about seventeen minutes of twice minimum wage time per year. But even this loose bound assumes that users are liable for the loss and can address it by following security advice.”

Ignore the transcription error here (it should be 0.41%, not 0.49%), as it’s beside the point. Herley argues that, since $290 million is the current amount of fraud, the current security measures should cost no more than that. However, that’s simply wrong. $290 million is the minimum PayPal loses despite all the security measures. Take away, say, the password complexity rules, and fraud may balloon into the billions. Herley’s calculus can only apply to new rules that PayPal is considering implementing but hasn’t yet.

How to salvage this

What I’ve said here doesn’t negate the usefulness of Herley’s calculus for proposed security policies. That still would work as Herley proposes. Evaluating extant security policies requires more work, however, and is fraught with its own difficulties. I’ll discuss those in a future post.

A few months ago I was debating with a friend over IM about how far one should take unit testing. He was of the opinion that one should only bother with unit tests on complex methods, and that unit testing the simple stuff was a waste of time. I pressed him on just how simple an app or a method had to be before it was too simple to bother unit testing, and he responded with the simplest example he could think of: “After all, you don’t really need to test ‘Hello, Worl!’” [sic].

That was the end of that argument.

Last week a colleague was taking the opportunity to revisit his development environment. In light of the availability of Windows Server 2008 R2, Win7, and Beta 1 of Visual Studio 2010, Eric was interested in pursuing a heavily virtualized setup. As he knew I am a proponent of doing all development (including the IDEs) in virtuals and that I had converted to a Hyper-V-based development environment, we started discussing what approach he might take. Eric travels a lot, so he’s opted to work entirely on mobile devices. His primary notebook is a beast: Core 2 Quad, 8GB RAM, 17″ 1920×1200 display, 1GB nVidia Quadro FX 3700m, all in a svelte 11 pound package (including power supply). You’d think it’d be great for the developer who wants to virtualize, or the conference presenter who wants to demonstrate the latest and greatest to a crowd.

Unfortunately, Microsoft’s professional-level offerings for virtualization on notebooks are nonexistent.

At first, Eric wanted to go the Hyper-V R2 route. He installed Server 2K8 R2, installed VS2010 in the host partition, and TFS2010/SQL2K8/MOSS2007 in virtuals. He had heard me complain about the graphics performance problems with Hyper-V in the past, but wanted to see for himself. Sure enough, Visual Studio ran quite slowly. However, as it was his first time using the beta, he didn’t know if the lack of speed was just because it was a beta, or if Hyper-V was the cause. Temporarily disabling the Hyper-V role caused a severalfold speedup in the application, going from painful to pleasant. Permanently fixing this would require running XP-level (or, ugh, VGA) drivers for his top-end video card. On top of this, Hyper-V completely disables all forms of sleep in Windows. This was not an acceptable solution to a mobile user.

Frustrated, he decided to resort to Virtual PC. It’s free and easy to use, but that idea was shot down when he realized that not only does Virtual PC not support multiprocessor guests (annoying, but something he could cope with), but it won’t run 64-bit guests either. Given that many of the latest Microsoft server releases (including Windows Server 2008 R2 itself) are 64-bit only, this was a dealbreaker.

What’s left? I suggested VMware Workstation 6.5. It supports multicore guests, 64bit guests, and letting the host computer sleep, all without painful graphics performance. It’s not free, but if you’re looking to get the job done, it’s the best solution. If you want free, VirtualBox is a good option, although not quite as polished as VMWare Workstation. If you want Microsoft, you’re out of luck.

Eric went with VMware Workstation.

Finally, I should note that Intel is releasing the next round of mobile cpus in 1Q2010. As they’ll be Nehalem chips, many of them should have improved hardware virtualization support that matches what we can get on the desktop today. While it won’t fix the Hyper-V sleep mode problem, it will at least alleviate the Hyper-V graphics performance problem.

Part I and Part II are also available.

As I mentioned in part I, flagging a method as static in C# isn’t sufficient to eliminate all side effects.  It eliminates a single (albeit common) class of side effects, mutation of instance variables, but other classes of side effects (mutation of static variables, any sort of IO like database access or graphics updates) are still completely possible.  Effects are not a first-class concern in C#, and so the language as it stands today has no way to guarantee purity.  Thus, while it’s helpful to indicate intent and minimize your potential effect “surface area” by flagging a method as static, it’s not a guarantee that your function is pure.  Certainly, one can code in a functional style in C#, deriving many of the benefits just by indicating intent and minimizing potential effect “surface area” via flagging methods as static, but it’s still not the same as having a compiler guarantee that every method you think is pure actually is.  It’s easy for someone who doesn’t understand that a particular method was intended to be a pure function to change your static method to make a database call, and the compiler will be happy to comply.

Should C# be changed to raise effects to first-class concerns?  I don’t think most developers are used to differentiating between effects-laden code and code without effects, and may balk at any changes to the language that force them to.  Further, I fear backwards-compatibility concerns may limit what one could change about C#; instead of flagging a method as having effects (think the IO flag seen in some functional languages), it may be easier to invert the idea and flag methods as strictly pure.  Methods with this flag would be unable to access variables not passed in as input parameters and restricted in what kinds of calls they could make.

I don’t know yet what the right way to take is, and I don’t think anyone else does either.  I do know people like Joe Duffy and Anders Hejlsberg are contemplating it on a daily basis.  Something will need to be done; as developers will deal more and more with massively parallel hardware, segregating or eliminating effects will go from being a “nice to have” aspect of one’s programming style into an explicitly controlled “must have” just to get software that works.

Part I of this series can be found here.

My code didn’t improve just because I was giving up on OOP principles. I was simultaneously adopting functional principles in their place, whether I realized it at first or not. I found several benefits in doing so:

Testability

Consider a unit test for a pure function. You determine the appropriate range of input values, you pass the values in to the function, you check that the return values match what you expect. Nothing could be simpler.

Now consider testing a method that does the same job, but as an instance method. You’re not just considering the input and output values of a function with a simple unit test anymore. You either have to go through every step of the method and make sure you’re not touching any variables you’re not supposed to, or change the unit test to check every variable that is in scope (i.e. at least every method on that object), if you’re being comprehensive. And if you take a shortcut and don’t test every in-scope variable, anyone can add a line to your method that updates another variable, and your tests will never complain. Methods that perform external IO, such as reading values from a database to get their relevant state, are even worse — you have to insert and compare the appropriate values in the database out of band of the actual test, not to mention making sure the database is available in the same environment as the unit tests in the first place.

When software is designed in such a way that side effects are minimized, test suites are easy to write and maintain. When side effects occur everywhere in code, automated testing is impractical at best and impossible at worst.

Limited coupling of systems

When I take the idea of eliminating side effects to their logical conclusion, I end up with a lot of data objects that don’t do anything except hold state, a lot of pure functions that produce output values from input parameters, and a mere handful of methods that set state on the data objects based on the aggregate results from the pure functions. This, not coincidentally, works extremely well with loosely coupled and distributed systems architectures. With modern web services communicating between systems that were often developed independently, it’s usually not even possible to send instance methods along with the data. It just doesn’t make sense to transfer anything except state. So why bundle methods and state together internally if you will have to split them up again when dealing with the outside world? Simplify it and keep it decoupled everywhere.

Decoupling internally means that the line between ‘internal’ code and ‘external’ code is malleable, as well. This leads me to another benefit of eliminating side effects:

Scalability (scaling out)

If all you’re doing is passing state from one internal pure function to another internal pure function, what’s stopping you from moving one of those functions to another computer altogether? Maybe your software has a huge bottleneck in the processing that occurs in just one function that gets repeatedly applied to different inputs. In this case, it may be reasonable to farm that function out to a dedicated server, or a whole load balanced/distributed server farm, by simply dropping in a service boundary.

Concurrency (scaling up)

One of the keys to maximizing how well your software scales up on multi-CPU systems is minimizing shared state. When methods have side effects, the developer must perform rigorous manual analysis to ensure that all the state touched by those methods is threadsafe. Further, just because it’s threadsafe doesn’t mean it will perform well; as the number of threads increases, lock contention for that state can increase dramatically.

When a method is totally pure, on the other hand, you have a guarantee that that method, at least, will scale linearly with your hardware and the number of threads. In other words, as long as your hardware is up to snuff, running 8 threads of your method should be 8 times faster; you simply don’t have to worry about it. On top of that, pure methods are inherently threadsafe; no side effects means no shared state in the method, so threads won’t interfere with each other. While you probably won’t be able to avoid shared state completely, keeping as many functions pure as possible means that the few places that you do maintain shared state will be well-known, well-understood, and much easier to analyze for thread safety and performance.

For all these reasons, I found adopting a functional style to be a huge win. However, not all is wine and roses for C# developers who have learned to love functional programming…

(to be continued in part III)