Applying the Science Process to Process Change (see Recursion)

Now that we’ve established that very few people who work in “IT” have anything to do with technology, except as a tool, and that “computer science” isn’t about computers, we’re back at the original reason I began to write a book. I was once an ‘Information Systems Engineer’ and wasn’t very sure what any of those words meant, particularly “information”.

Software development teams often see their role as solving their customer’s problems. Software package providers say they are “solution providers”. What does the ‘unspeakable profession’ actually do? We got some clues from Hal Abelson in the video I linked to in my last post, that new areas of intellectual endeavour often confuse the ‘essence’ of their subject with their tools; so do we really engineer software?

Hal said that writing software is the process (or function) of formalising our intuitions about process (function.) Our software is a speculative formal abstraction of our intuitive understanding of a process we may not entirely understand. No wonder software projects so often fail. Like the rest of science, software is built on ideas that haven’t been proved wrong yet.

Software developers are presented with, or attempt to discover, experts’ (declarative) knowledge of the business process in the ‘domain’ we are about to change. This is ‘the abstract requirements’. Some of this may have to be implied from imperative knowledge embedded in existing software. It may be presented as imperative solutions. It may be incomplete.

We then follow our own process (function) for: ‘the way we do software’, in order to design a new process, some of which is also likely to be have to be embedded in software. Applying functions to change functions? That’s what functional programming does, isn’t it?

I believe that the ‘stuff’ of ‘computer science’, is state-change of systems of process and data. Who remembers ‘Data Processing’? Functional programming points out that the processes themselves are data and dynamic state-change is unpredictable and therefore dangerous.

Engineering would apply ‘project thinking’ to this unstable, poorly defined change. I may once have tried to be an information systems engineer but I saw that it didn’t work and took a 20 year break from software development.

Agile frameworks recognise such changes as risky experiments and carefully apply the scientific method, incrementally with feedback loops, to check assumptions.

We may need to return another time to see what functional programming has to say about 2 projects making concurrent changes from the same initial state. Until then, good luck with those.

Advertisement

Software Life-cycle. Part 2 – From Craftsmanship to Computational Science

I decided to learn the programming language Python. I was steered towards the MIT OpenCourseware ‘Introduction to Computer Science and Programming’ 6.00 course, taught by Prof. Eric Grimson and Prof. John Guttag (they say it is a course about computational thinking.)

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00-introduction-to-computer-science-and-programming-fall-2008/video-lectures/

As the first lecture felt a bit basic, at great personal risk of uncovering ‘a spoiler’, I skipped on to the course summary in the last lecture to see if it was worth sticking around. I found it inspirational. Prof. John Guttag explains computation in the context of ‘The Scientific Method’. I’ve since realised that his explanation maps with great accurately onto Agile iterative methods. Agilists aren’t engineers, we’re scientists again. Engineering Project Management uses experience of similar previous projects. Why would you ever write similar software twice? Most of the work is already done. Every change to a computational system should be R&D.

Every Scrum Sprint is a suite of computational experiments. The Product Owner is our test subject. This feels right. I never felt like a computer scientist. In James Gleich’s ‘The Information’, he explains that Alan Turing introduced Babbage’s mechanical Difference Engine when talking to non-specialist, to emphasise that computing is an abstract concept, independent from computers and electricity. I’ve always had a computational scientist trying to get out <Woo asplodes>.