Is software development interesting? Most people would say no, I suspect. Certainly most eyes glaze over when I start talking about it with non-developers (which I rarely do).
In fact, it's a very strange and interesting meeting point of diverse ideas, some better suited to literature, others to magic.
In the industry itself, we haven't got a clue what we're doing — we call it software development, software engineering, an art, a craft — what it actually is remains a constant topic of debate. And each term is freighted with meaning, implications and history.
Long before I began as a developer, it interested me in quite abstract terms. Schooled in both historicist and philological, as well as Marxian and post-structuralist literary traditions, I was naturally curious what the word 'language' even meant in programming. It seemed to have much in common with the magical languages — inscriptions which effected change in the 'real world', in reality itself. And not just on human behaviour and thought, but on the actual machineries of our lives.
At that point I didn't realise that 'programming' was only part of the puzzle, and that software development is a literary activity, probably most close to drama among the traditional forms. But it's also an interpretive literary critical activity.
What do I mean? When we design a modern software solution, we usually follow the 'object oriented' approach.
You might imagine we write big pieces of management-style code which coordinate the loading and and manipulation of data in a chronological fashion (i.e. load data, do this then that to it, save the changes, etc.). Historically a lot of development has taken this approach, and it is generally known as 'functional' programming, for reasons you don't need to know.
Under the 'object oriented' approach, we actually try to model the 'problem domain' and create an imitation of reality in software. That means we examine the language of the business problem we're solving, isolate the various actors and their responsibilities, and create software versions of them.
These are software 'objects' – defined as the data required by each and the associated actions, known as 'methods', to operate on that data – and the only way to do anything in a system like this is to ask them to perform the action for us. Common examples are user, account, institution, invoice, or payment objects.
There are different types of relationships that can exist between these objects — a customer object can contain, or have a link to, its credit card and account objects (this is known as 'composition'). There can also be sub-types – perhaps personalAccount and businessAccount types which share, but customise or add to, the common Account behaviour (this is known as 'inheritance').
So the activity of designing a complex software solution begins with the identification and organisation of all the objects involved. The simplest way to understand it is to think of all the nouns and verbs involved in a business situation — the nouns will be objects, the verbs will be methods. "Purchase a product, pay with a credit card payment" reveals the nouns product, payment, creditcard and the verbs purchase and pay.
We have special languages and visual styles for representing this analysis. The most common is UML (the Unified Modelling Language), which provides a range of diagram types for representing the various actors, relationships, and activities.
Now this is clearly an interpretative activity like literary criticism. But I want to think about the process of mimesis at the core of the activity.
Mimesis is ancient Greek for imitation, representation. For the broader meaning, I'm happy with the definition Erich Auerbach provided in his magisterial Mimesis: The Representation of Reality in Western Literature: "a lifelike illusion of some 'real' world outside the text by processes of selection, exclusion, description, and manners of addressing the reader." As well as the techniques used to create this literary representation, the conventions required to understand it — the drama and the audience.
Not a small topic. Representation, imitation, similarity, difference — these are core issues in our relationship with the world, our selves, and language, which is why they have preoccupied philosophers from Plato and Aristotle to your favourite (post-)modern thinker.
And this is the proper subject of object-oriented software development. And when we're done modelling reality, we implement it in a magical language that can operate on the real world and creates real, actual representations of these things.
A hidden electronic drama, every time you browse the web — a reflection of your actions, yet paradoxically, possibly the more 'real'. After all, if they don't work, neither can you.Powered by Sidelines