Tag Archives: Hal Abelson

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.

Advertisements

Like magic, the laws of physics do not apply to software

For a few months I’ve been arguing that Agile product/service development only works for classes of systems that are not subject to gravity, like software and business processes. After attending a talk on the functional language Clojure by Paul Williams of @birminghamfp at Agile Staffordshire, I discovered this MITOpenCourseWare 6-001 introductory video.

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/1a-overview-and-introduction-to-lisp/

I particularly recommend about the first 10 minutes. After that you may accidentally learn Lisp and I’ll deny all responsibility for subsequent brain damage if that happens. Hal Abelson argues that ‘computer science’ is not bound by the rules of physics. Like me, he sees the design of business processes and procedures being within its boundaries. Business procedures are just an attempt to implement processes on people rather than in software, sacrificing reliability for flexibility.

I agree that ‘computer science’ isn’t about computers but I think Lean & Agile methods re-take computation for science, rather than magic or engineering. I’m sticking with ‘computational science’ for now.

Many software people are frustrated by their managers’ attempts at business change. Why do organisations allow general managers with no training in the re-factorisation of complex processes to run business change programmes when they wouldn’t trust them to run a small software project? It’s the same thing, but much harder.