共用方式為

Cause and Defect

  • 發行項

As far as I know, nobody has yet been able to answer the long-standing question of what will happen if you spread butter on the back of a cat. Will it exhibit the buttered-toast effect, or will it still land on its feet? We know from the established principles described by Murphy's Law that toast always lands butter side down; but at least there is a thread of scientific explanation for this, which says it's because the buttered side is smoother and more "slippery" - thus offering less air resistance and causing that side to fall faster and hit the ground first.

Associated with Murphy's Law is the far more interesting Law of Unintended Consequences. I was reminded of this just last week while reading an article by a school teacher who was discussing the worrying trend in the increasing number of school children categorized as having Special Educational Needs (SEN). Of course, many people are applying the political football approach to this; citing the usual factors of poor housing, lack of parenting skills, broken families, and Government interference in the school syllabus.

However, the author of the article took a different approach. See if you can spot any factors that may contribute to the increasing trend in the following:

  • Children that have SEN get extra time to complete exams, and special allowances in exam marking schemes.
  • Children that have SEN get prizes such as laptop computers and MP3 players for completing educational milestones.
  • Teachers who have SEN children in their class get extra teaching assistance in lessons to reduce their workload.
  • The exam results of SEN children are not included in the overall exam success league tables for a school.
  • Both teachers and parents can apply to have a child registered as having SEN.

Of course, unintended consequences due to Government intervention are obvious all over the place. These days the police have to meet targets for the number of crimes they solve, so a constable who sees somebody running away from an illegally parked car they've broken into has to instantly decide whether to give chase on the off chance that he can catch the runner and find some case for arresting them, or instead fill out a ticket and slap it on the illegally parked vehicle.

Likewise, family doctors have to provide an appointment on request within two working days. So, if you decide to book ahead for a routine visit next week, you can't because that would reduce their "patient charter" average score. Meanwhile, as our local council strives to reduce incidences of fly-tipping, the local council-run waste reclamation facility only allows you to use it if you arrive in a car. If you decide to hire a van or truck when you finally get round to clearing out all the rubbish in your grandparent's garage, you need to apply a week ahead by filling in a four page form to apply for a "waste reclamation site access certificate".

But unintended consequences have a far wider area of incidence, especially in our own industry. For example, I decided to green up my server cabinet by virtualizing all of my servers (see blog entries passim). However, now the domain controller is a virtual machine that doesn't start up until the base O/S is running. As it's a member of the domain, it does lots of grumbling and sometimes has a complete hissy fit when it reboots because it can't find its domain controller. And my NAS can't authenticate with my servers because I upgraded them to Windows Server 2008 and the NAS has never heard of that.

However, when it comes to software, I guess the law really comes into its own. I've recently been working on a project that combines Windows Phone 7 with Azure cloud services. But the phone is not exactly a hugely powerful platform for applications. It would be nice to think you could buy one with a quad core Xeon processor and four gig of memory on board, but until they invent mobile power stations that seems unlikely. So I have to minimize my application's memory footprint, reduce power consumption when possible, be aware that garbage collection will interrupt execution, and limit the number of requests I send to remote services to minimize communication costs.

Yet my desires to follow best practice and implement well known design patterns suggest I should use data transfer objects and view models to store intermediate data, use dependency injection to decouple my components, and apply configuration-based composition of interfaces to maximize upgradability and minimize maintenance costs. But I'm not supposed to create lots of objects in memory in order to minimize memory footprint and garbage collection intervention; yet I'm also required to hang onto objects rather than recreating them repeatedly, and use less of them. Maybe I should take up tight-rope walking as a hobby to get some practice in phone application development?

And don't get me started on writing documentation. If I slavishly follow guidelines for minimizing content to only that which is directly applicable to a scenario, users will be left wondering how they accomplish something more real-life than my simple examples. But if I dive deep and cover every aspect, there's too much to read and it becomes overwhelming. And if I simply present the basic facts, it's hard to see how you could describe this as guidance. Yet, if I litter it with links to other resources, users just get lost in the plethora of semi-redundant and partially related information.

It's a good thing that my blog posts are concise and focused, and don't just wander aimlessly from one vague topic to another...