Model Software

Today, I had to stop myself writing “solving the problem” about developing software. Why do we say that? Why do software people call any bounded area of reality “the problem domain”?

My change of mind has been fermenting for a while, due to modelling business processes, learning about incremental, agile software development and more recently writing and learning functional programming. In the shower this morning, I finally concluded that I think software is primarily a modelling medium. We solve problems using the models we build.

Wanting to create another first-person shooter game or to model the fluids in a thermo-nuclear reactor are challenges, not problems. We build models of systems we have defined and the systems don’t even have to be real. I read a couple of days ago that a famous modern philosopher said our world is made of both reality and our ideas. Assuming the computer hardware is real, the software can model either reality or our imagination; our chosen narrative.

‘Digital’ gets everyone working with software models instead of reality. Once everyone lives inside the shared model, when does it become our reality?

Or when did it?

Advertisement

Finding Order

I was all of a Twitter this morning about my discovery of not one but 5 specimens of a plant known variously as ‘Lords and Ladies’ or ‘Cuckoos Pint’ in 3 different locations around Llangollen yesterday. I now know that it is a fairly common plant and poisonous, but a day earlier I wouldn’t have known anything about it. Would I have noticed this brightly coloured plant at all, if @BrownhillsBob hadn’t told me about it?

…and again in the wooded grove created by The 'Ladies of Llangollen' at Plas Newydd. Later, 3 together by canal. pic.twitter.com/1fI4XbBCZp

— Andy Wootton (@WooTube) August 9, 2016

The reason this occurrence struck a chord with me was that it wasn’t my first ‘not really very strange’ coincidence of the day. At university, my systems analysis lecturer was a guy called David Avison. A few years ago when I moved into my first analysis job, my team leader loaned me his copy of a book called ‘Information Systems Development’ by David Avison & Guy Fitzgerald. I skimmed through it but it seemed stuck in the the ancient ways. I wanted to rush forward to Agile development. I put it aside.

Yesterday, having stopped for coffee in Llangollen, I went upstairs to ‘powder my nose’ *. The upstairs of the shop is a second-hand book shop. On the stairs was a bookcase labelled ‘Computers’. Well, you have to have a look, don’t you? There was a near pristine copy of Avison & Fitzgerald, 2003 marked at £10 and there was a half-price sale on. I flicked through and found “5. Modelling Themes”. I had spent my last couple of days work modelling what I called “Programming Paradigms”, a sub-component of a model I’d called “Themes” and my plan for today was to write about modelling. Dear Reader, I bought it.

I am not a Fatalist. I believe we can’t see things until our minds are in a state to accept them. Our total knowledge is not the sum of everything we have experienced but of the order in which we were ready to take on board new information. Learn something too soon  and the other end of the connections I think cause creativity may not be in place, ready.

• I learned at Plas Newydd that the phrase “power your nose” came from the dual-use of powder closets, where fine ladies powdered their hair to provide a private toilet space and an opportunity for ambiguity, as ideas about personal privacy changed.

As simple as possible, but no simpler

The title of this post is a phrase that is often ascribed to Albert Einstein. Indeed I have ascribed it, doubly-wrongly, myself in relation to modelling, without checking. I am a Bad Physicist. One of the many things I’ve learned since yesterday is that he didn’t say it. Ironically, it is probably an over-simplification of something he actually said: “It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience.” OK, maybe one-and-a-halfly wrong but let’s not get into the equivalence of modelling and theory right now.

There have been a few times in my life when I have known for a long time that there was something inherently wrong in my understanding of a subject. Yesterday, at the age of 55, I set a new record for Wrongness longevity. Despite having passed ‘O’ Level, ‘A’ Level and half a degree in physics, I confirmed my suspicion that I didn’t really understand Alternating Current electricity AC.) I’m not keen to discuss the details of how I proved this but I was relieved there was a circuit breaker.

I still wouldn’t say I really understand AC still but I have reached the point of knowing my unknown. Enlightenment may have to wait but in getting where I am, I’ve discovered there are lots of other people who don’t understand either and some of them are qualified electricians, making it very lucky for all of us that we in the UK are protected by a very well designed electrical system and ‘The Regs’ which allow people who don’t understand to navigate adequately with their one good eye, by following an explicit set of rules.

I also came across students struggling with the same misunderstandings as me, being advised by the kind of over-academic idiots that I thought were legally restricted to computing forums. If a kid is asking what “electron flow” means in an AC-circuit, s/he is probably not looking for an answer that involves quantum mechanics. But there is the problem: one of my secondary-school physics teachers, by trying to keep things as simple as possible, used an over-simplistic analogy between DC and AC current that has confused me for 40 years. Or he didn’t understand either.

To check if things had improved, I looked at current school science revision notes. If anything, they were worse. In summary: +ve and -ve don’t mean much in AC but “Live” and “Neutral” do. Current doesn’t so much “flow” as “oscilate”. Zero load is BAD. All the current! The advice not to mess with mains voltage unless you really know what you are doing also applies to me, and I was only trying to change a ceiling fan.

What I’ve learned may eventually find its way into my ‘Finds & Thinks’ book.

Programming Paradigm Objectification

I  learned to program according to the principles of

• structured programming (rather than spaghetti code)
• modular code (rather than monolithic)
• top-down design/functional decomposition (rather than JFDI)

The Idea was:

• you had a big problem that you completely understood and the problem could be decomposed into smaller and smaller pieces of function until you could see how to write them as code (producing a functional hierarchy – a concept similar to dissecting a body, with no significant understanding of anatomy until you had finished)
• your organisation’s data could be analysed and abstractly modelled without any knowledge of how it would be used (producing a data model)
• you could trace the route of all information in the system as it was input from a data source, processed within the system into a different form and output to a data sink (producing data flows & data processing)

Sadly, none of those assumptions were completely true and the systems produced were liable to be hugely disrupted by minor changes if they had not been anticipated – or not – it was fairly random.

I worked in that culture for a few years. I could see what was wrong but didn’t know how to fix it, so I got out of programming and ran systems for people who didn’t seem to have  existential issues with their programming paradigm.

I don’t like being beaten by a problem, so I kept a weather-eye on what was going on in software development. I started to hear about Object-Oriented Programming and decided to investigate. It took about three talks for me to begin to understand tiny bits of ‘what the hell They were talking about’, because each time I was told that O-O languages had some of the following features:

• Encapsulation and information hiding
• Objects (with attributes and methods)
• Dynamic dispatch
• Abstraction
• Polymorphism
• Inheritance (or delegation)

Oddly, I didn’t find that knowledge helped me much to understand WHY. I’ve started reading about O-O again this week and I realised in the shower this morning that the object paradigm isn’t just a list of jargon words.

Instead of splattering representations of the things your program is dealing with throughout the functions, with references to many elements of the data structure and data flows,  O-O models any of ‘the business objects’ of your organisation that your program needs to deal with. The objects encapsulate their local functions and  data. Objects don’t change as often as functions so changes are localised.

The connections between the objects are represented by message-passing. If things have to be taken apart later, as relationships between real objects change or are replaced, the connections can be re-made to represent the new reality.

The O-O model represents “small systems, loosely joined”, like Unix. If someone had just pointed that out, it would have helped me to understand. So I’m saying it here, now, in case it helps you.

Without O-O, I don’t think the Agile software development revolution could have happened, because the early uncertainties and ‘sketched solutions’ of Agile would have had too great a cost of change, later.