You might sometimes find them prickly people to deal with, maybe they can seem unhelpfully dogmatic in their views on how things should work, but they do have your best interests at heart. Programmers are like that because they have an acute awareness of how the superfast, powerful, massively scalable, and deceptively easy to access capabilities of modern computers and networks may amplify mistakes that quite quickly become hard to unravel. In one of the most influential articles of the 20th Century “No Silver Bullet” (1986), the software engineer Fred Brooks explored this dilemma – the simplicity of computers at the basic level (data and algorithms) rapidly builds up into layers of “accidental complexity” making software that can be impossible to understand fully and fix when dysfunctional. To prevent this, he argued, we need to think clearly and rationally about the high level structures we put in place, and then allow detail to grow in a disciplined and systematic way. That’s what programmers want from you! Practice these approaches and you will find them applicable to managing the complexity of research, as well as any other aspect of life.
It is beyond the scope of this article to give a full account of modern programming, which has rapidly gained some very sophisticated and seemingly abstract approaches. But we can gain an insight through a brief exploration of what we call Object Oriented Programming (OOP) and the Model-View-Controller (MVC) pattern.
In OOP, everything is represented as objects defined by classes. Let’s see how this applies to dogs.
A Chihuahua is a type of Dog (it is a subclass of the class Dog, which defines the charactersistics that all dogs share). It has all the characteristics of a dog, with some variations that make it specifically a Chihuahua, as defined by the Kennel Club, who are like the programmers of the dog world, trying to keep things neatly constrained whilst also accomodating the diversity of doggy-kind. To be precise, let’s talk about the UK Kennel Club Standard Chihuahua. Refer to that standard to find out about the ranges in colour, shape, teeth, paws, tail, weight, dimensions etc. that define a Chihuahua. In programming terms, the class Chihuahua (note the capital C as it is a class) has the name of its breed set by default, as well as a bunch of other properties. It might also contain a certificate of authenticity. Every instance of the Chihuahua (an instance is an object of the class) should have the correct atttributes and an associated certificate of authenticity. It should be possible to access that certificate. There should be a method (the OOP name for an algorithm that can be run in any Object of the Class) for retrieving and inspecting the certificate.
But hang on a minute, have you ever come across a dog that is able to prove its own authenticity by showing you its certificate? I challenge you to ask Fido, an instance of Chihuahua, to prove its authenticity. That’s not going to work. Fido says “grrrrrrr”.
Of course we shouldn’t confuse the Class Chihuahua with the actual messy physical organic thing called Fido. It’s just an informational abstraction. What we call the Model (in the model-view-controller pattern). We are representing the real world. The certificate is an interface for viewing the data in the Model – part of what we call the View. The means through which the data is added to the certificate, and then retrieved for us when requested is the third part of the programme, the Controller. Always think: model-view-controller when you are working with software.
The model is getting quite complicated. It needs to to do justice to the reality of dogs. For example, Fido is dependent on humans to do some of its work – retreiving the certificate and proving Fido’s authenticity. We might include in our specification of the class Dog a property for “owner”, and then have a whole other class for DogOwner. There could be a method in Owner for retrieving a specific dog’s certificate, as well as a method in the Dog class for asking for the certificate from the owner. We now have a dependency between Dog and Owner (there are more, the dog needs a bone and a bowl of food). But a dog might have multiple owners, so it needs to be a list of owners. It might be owned by a company, or have multiple owners – we need to design to cope with those variations. But in this case Fido is a stray! He has no owner. So is there a subclass for stray dogs? Or just a marker to say “stray”? And as he is a stray, he doesn’t actually have a pedigree, so the whole certificate thing is irrelevant. Do we have a “Mongrel” class?
In the mind of the programmer this is all raising lots of exciting questions – even the case of the classification of dogs is interesting.
And do you know what I’m thinking now, as a programmer? What if we put all this data into an RFID readable microchip and inserted it under Fido’s skin? The relationship between the certificate and the owner would change. But then what if the chip gave Fido more informational and connective capabilities? New class: RoboDog!
Next time you are creating data and data structures of any kind, think of Fido – classes, subclasses, properties, methods, relationships, dependencies.
Leave a Reply