Showing posts with label Programming. Show all posts
Showing posts with label Programming. Show all posts

Tuesday, 3 May 2016

Agile is dead

This is an excellent post, though some might consider it a rant, about how Agile wasn't really nor became what Agile should it should have...

Agile is Dead

"Are you an IT consultant or contractor? Agile Software Development work is dead. If you practice that, you are a doorstop. If you manage that way, you are a boat-anchor. The wave has ended, it is over, and if you went for the head-fake and bought certifications, you wasted some money. Soon recruiters will be putting your resume in the circular storage container. I have been warning you for some time, and the day is here. Hah, you should have listened. Move along."

But here's the best quote:

The moral of this part of the story is that if you produce some compact politicised ideology (manifesto) consisting of principles and rules there will be unintended consequences.  Success creates a religion or cult, and defeat is being ignored.  No such doctrine is perfect.  Thinking you will change the world with a manifesto is naive, and if you succeed you may not have improved the world.

To me, given the problems that Privacy by Design has caused with privacy officers believing in some mythical "compliance" without any consideration of the software engineering or cultural aspects of developing information systems, this sums it up quite nicely!

Tuesday, 9 February 2016

A long time ago...

When computers were real, and I mean the ZX Spectrum, the BBC Model B, the VIC-20 and all manner of 8-bit machines that booting straight into a BASIC interpreter (with a nod of the hat to the Jupiter ACE of course!), there was a little publishing company called Usborne who produced the most amazing books on computing. Now many of those books from the 1980s have been released free via their website.

One book in particular will always stand out for me:



On pages 24 and 25 is a listing for a game called Space Mines - a very simple simulation game based on selling ore for food and mines. That particular game got typed in, played with, modified, reimplemented and I guess in no small way started my love of simulation games which more than likely led to me writing a language for implementing simulations ( BSc degree final year project ) and later trying to simulate the behaviour of systems from their formally specified models ( PhD thesis ).

So to Usborne, the writers, editors and everyone involved in those books, especially the person or persons who wrote "Space Mines" my deepest, heartfelt thanks!


Tuesday, 28 April 2015

Modelling Privacy

Here's a teaser from the next book on privacy. ETA late 2015, December - just in time for Christmas - if I work really hard!


It will compliment the existing book Privacy Engineering and build upon more of the data flow modelling, use of taxonomies and techniques for analysing models such as those from safety critical engineering, eg: FMEA, RCA etc.

In the meantime, Privacy Engineering is available from Amazon.com, Amazon.co.uk, CreateSpace as well as Barnes and Noble and even book stores such as CDON.fi here in Finland.

Wednesday, 20 August 2014

Design by Contract and Security

I've worked with design-by-contract for a long while; in fact its use as an essential programming concept was brought to my attention by one of my professors who didn't just teach it but demanded it as a fundamental part of any design or program. It remains today an integral technique in my toolbox of programming and design techniques. As an aside, Eiffel supports DbC as part of its programming model; it makes it one of the most elegant and easy languages not just to program in but to develop in.

DbC of course is related to the validation that one should make on web page forms and various concepts in strong typing of functions etc. Generalising DbC into other areas such as security, privacy should be an obvious step, but one seemingly not taken.

Via Schneier's brilliant security blog is a link to an article entitled Security As A Class Of Interface Guarantee. It is a long read but one more than worthwhile for software developers certainly; and maybe for any security and privacy engineers too. Actually if there's one article on security and development you read today it must be this one! Here's small sample:
Security Is Part Of Every Interface 
I prefer to think of security as a class of interface guarantee. In particular, security guarantees are a kind of correctness guarantee. At every interface of every kind — user interface, programming language syntax and semantics, in-process APIs, kernel APIs, RPC and network protocols, ceremonies — explicit and implicit design guarantees(promises, contracts) are in place, and determine the degree of “security” (however defined) the system can possibly achieve. 
Design guarantees might or might not actually hold in the implementation — software tends to have bugs, after all. Callers and callees can sometimes (but not always) defend themselves against untrustworthy callees and callers (respectively) in various ways that depend on the circumstances and on the nature of caller and callee. In this sense an interface is an attack surface — but properly constructed, it can also be a defense surface.

At the end of the article is a suprise link to a tweet :-)

Obvious isn't it...?!

Monday, 19 May 2014

Foundations of Privacy - Another Idea

This got triggered by a post on LinkedIn about what a degree in privacy might contain. I've certainly thought about this before, at least in terms of software engineering, and even have a whole course that could be taken over a semester ready to go.

Aside: CMU has the "World's First Privacy Engineering Course": a Master of Science in Information Technology—Privacy Engineering (MSIT-PE) degree. So, close, but a major university here in Finland turned down the chance to create something similar a few years back...

That aside, I've been wondering about how to present they various levels of things we need to consider to properly define privacy and put it on strong foundations. Though in the guise of information theory we already have this, though admittedly Shannon's seminal work from the 1930's is maybe a little too deep. On the other hand understanding concepts such as channels, entropy are fundamental building blocks, so maybe they should be there along with privacy law - now that would make some course!

Even just sketching out areas to present and what might be contained therein...how about this, even if a linear map from morality to mathematics is too constraining?



There are missing bits - we still have a  semantic gap between the "legal world" and the "engineering world"; parts that I'm hoping that things such as the many conferences, academic works and books such as the excellent Privacy Engineer's Manifesto and Privacy Engineering will play a role in defining. Maybe the semantic gap goes away once we start looking at this...is there even a semantic gap? 

However, imagine for a moment starting anywhere in this stack and working up and down and keeping everything linked together in the context of privacy and information security. Imagine seeing the link between EU privacy laws and type theory, or between the construction of policies and entropy, the algebra of HIPAA, a side course in homotopy type theory and privacy...maybe with that last one I'm getting carried away, but, this is exactly what we need to have in place.

Each layer provides the semantics to the layer above - what do our morals and ethics means in terms of formalised laws, what do laws mean in terms of policies, what do policies mean in terms of software engineering structures, and down to the core mathematics and algebras of information.

Privacy and privacy engineering in particular almost has everything: law, algebra, morals, ethics, semantics, policy, software, entropy, information, data, BigData, Semantic Web etc etc etc. Furthermore, we have links to areas such as security, cryptography, economic theory etc!

Aren't these the very things any practitioner of privacy (engineering) should know, or at least have knowledge of? Imagine if lawyers understood information theory and semantics, and, software engineers understood law? 

OK, so there might be various ways of putting this stack together, competing theories of privacy etc, but that would be the real beauty here - a complete theory of privacy from the core mathematics through physics, computation, type theory, software engineering, policies, law and even ethics and morals.

But again, no more naivety, no more terminological or ontological confusions, policies and laws being traceable right down to the computation structures and code. Quite a tall order, but such a course bringing all these together really would be wonderful...

And wouldn't that be something!

Thursday, 8 May 2014

Checklists and Design by Contract

One of the problems I am having with checklists is that they are often, or nearly always, confused with processes: "this is the list of steps we have to do and then you tick them off and all is well" mentality. This is probably why in some cases checklists have been renamed "aide memoirs" [1] and why their use and implementation is so misunderstood.

In the case of aviation or the surgical checklists these do not signify whether it is "safe" to take-off or start whatever procedure but as a reminder to the practitioner and supporting team that they have reached a place where they need to check on their status and progress. The decision to go or no-go is not the remit of the checklist. For example, once a checklist is complete a pilot is free to choose whether to take-off or not irrespective of the answers given to the items on the checklist (cf: [2]).

This got me thinking in that there are some similarities to design-by-contract and this could be used to explain checklists better possibly. For example consider the function to take-off (written in pseudo Eiffel fragments [3]):

     take-off
         -- get the throttle position, brake status etc and spool-up engines
     do
        ....
     end
...

can be called whenever, there is no restriction and this is how it was, until an aircraft crash in the 1930's triggered the development of checklists in aviation. So now we have:

     take-off
         -- get the throttle position, brake status etc and spool-up engines
     require
          checklist_complete = True
     do
        ....
     end
...

and in more modern aircraft this is supplemented by features to specifically check on the aircraft status

     take-off
         -- get the throttle position, brake status etc and spool-up engines
     require
          checklist_complete = True
     do
        if flaps < 10 then 
            soundAlarm 
       end
        ....
     end
...

or even:

     take-off
         -- get the throttle position, brake status etc and spool-up engines
     require
          checklist_complete = True
          flaps > 10
          mode = GroundMode
     do       
        ....
     ensure
          mode = FlightMode
     end
...

What you actually see are specific checks from the checklists being incorporated into the basic protection mechanisms of the aircraft functionality. This is analogous to what we might see in a process, for example below we can see the implementation of functionality to encode a project approval checklist into some approval function:

    approveProject
      require
         securityReview.status = Completed
         privacyReview.statuse= Completed
         continuityReview.status = Completed
         performanceReview.status = Completed
         architecturalReview.status = Completed
      do
         ...

Now we have said nothing about how the particular reviews were actually made or whether the quality of their results were sufficient. This brings us to the next question of the qualitative part of a checklist and deciding what to expose. Here we have three options:

  1. completion
  2. warnings
  3. show stopping preconditions

The first is as explained above, the second and third offer us a choice about how we expose and act upon the information gained through the checklist. Consider a privacy or information content review of system, we would hope that specific aspects are specifically required, while others are just warnings:

    approveProject
      require
         ...
         privacyReviewStatus = Completed
         privacyReview.pciData = False
         privacyReview.healthData = False
         ...
      do
         if privacyReview.dataFlowModelComplete = False then warn("Incomplete DFDs!") end
         ...

And we can get even more complex and expose more of the checklist contents as necessary.

The main point here is that if we draw an analogy with programming, some aspects of checklists can be more easily explained. Firstly the basic checklist maxim is:

All the items on a checklist MUST be checked.

then we should be in a place to make a decision based on the following "procedure"

  1. Are all individual items in their respective parameter boundaries?
  2. Are all the parameters taken as a whole indicating that we are in a state that is considered to be within our definition of "safe" to proceed to the next state?
  3. Final question: Go or No-Go based on what we know from the two questions above?
Of course, we have glossed over some of the practical implementations and cultural aspects such as team work, decision making and cross-referencing, but what we have described is some of the philosophy and implementation of checklists in a more familiar to some programming context.


References

[1] Great Ormond Street Hospital did this according to one BBC (I think) documentary.
[2] Spanair Flight 5022 

Thursday, 23 January 2014

On being formal, and possibly agile too...

Way back in my past I used to research formal methods for software engineering. Actually I still do, though now most of my time is actually using formal methods to make better software.

Formal methods are nothing more than a collection of languages and techniques for modifying and reasoning about things (models) written in those languages. Some of these techniques encompass how the process of building a system is made. Herein lies one of the first problems encountered by formal methods practitioners and that is the almost constant challenge from some, such as many in the agile community, that seem to be religiously against any form of modelling.

To those who believe that code is the only deliverable and the only thing that matters, well, C++, C, Fortran, Clojure etc are all formal languages, and you're probably using many of the techniques from formal methods right now as your write your code.

Language such as B, Alloy, Z, VDM etc do is provide a method of expressing a model without worrying about certain, awkward details of their implementation or execution.

Indeed what is happening here is that we have languages and techniques that allow you to concentrate on reasoning and thinking about the problem you are trying to solve without getting bogged down in the details of the final implementation.

If your first worry is the implementation language, or the operating system, or which libraries to use, etc, then you're most certainly not solving the problem.

At Nokia we had some very great successes using formal methods in an agile manner for the development of a semantic web infrastructure for the "Internet of Things". Concentrating on what the system had to do and then later worrying about how it was implemented meant that when it did come to the time we needed to architect the components and decide on specific implementation issues we already knew how the system was going to work, what tests we would need to run and what the expected answers were going to be.
Indeed, many of the tests were little more than checking that the code behaved the same as our earlier models - regression testing if you like.

This resulted in a huge decrease in the time spent in coding and the effective removal of nearly all (logic) bugs before even the beta releases. In fact most of the bugs turned out to by typos.

Furthermore, when it came to updating the software with additional features, instead of blindly bolting on a new use case we could reduce most of the new feature requests down to library or convenience functions over the core functionality rather than complicating the design with those "new" features.

This latter point is very important in that even though there is pressure to constantly add new features  (and the Pareto Principle applies here), most new features are really just convenience functions that already exist in the software.

I even remember one system where management demanded so many new features (all specified as their own use cases) that the system actually ended up implementing not only the same feature many times but features to disable the requested feature...

Ultimately formal methods is a discipline of thinking, rather than any technique to develop software. Just as much as Agile is a discipline of development.

To use formal methods does not mean any form of top-down or Waterfall development, it does not mean that one has to use refinement or a language like B or Z or VDM or Alloy etc. Just the simple act of writing a precondition to a function in C, or expressing a simple class diagram in UML, or ER diagram to explain a database schema (SQL or NoSQL) to demonstrate the workings of a system, or to clarify what something mean IS being formal.

The best agile developers I have seen all have formal methods backgrounds. The reasoning is that they already have the discipline and education and the tools to think and reason about their system, even if applied implicitly. Agile depends upon great communication between the developers and the customers and giving those customers exactly what they need in a manner that avoids technical debt (viz. situational awareness).

Whether we like it or not, great software engineering comes from understanding how our craft works at its most fundamental levels - imagine civil engineering without the mathematics of physics (a classic example), or even ballet without an understanding of human movement?

References:

[1] Ian Oliver Experiences of Formal Methods in 'Conventional' Software and Systems Design. FACS 2007 Christmas Workshop: Formal Methods in Industry. BCS London, UK, 17 December 2007 

[2]  Ian Oliver Experiences of Formal Methods in 'Conventional' Software and Systems Design





Wednesday, 15 January 2014

Getting Started with Clojure

I'm starting to enjoy using Clojure - the Lisp built on top of Java if you like. Great set of libraries, available and relevant documentation, a good base of users and plenty of examples.

I admit I'm already familiar with the functional programming style and have been for many years since discovering ML, Hope and Gofer many, many years ago, so I guess moving back to the one true language - Lisp - isn't so difficult, and anyway I don't want to talk about functional programming.

As everything seems to be about web based services, it tends to always be an quick experiment for me to build a simple web based service to get to grips with a language and its support. I must admit I loved Opa, but was let down by the support; Ruby on Rails I never really liked and let's not discuss Java and all its frameworks. Anyway, Clojure has been getting a lot of attention and a couple of colleagues of mine have had some very favourable things to say about it (one is a Lisp-fanatic however...) So here goes.

First go get Leiningen, the rather cool Clojure project automator. Dump that in a place where everyone can see it. I'm using Debian 7, so it goes in /usr/local/bin for me. I assume you're already familiar with things like this. Create a new Clojure project, which creates a whole bunch of directories under ./test
ian@deb1:~$ lein new test
Generating a project called test based on the 'default' template.
To see other templates (app, lein plugin, etc), try `lein help new`.
ian@
ian@deb1:~$ ls -l test
total 36
drwxr-xr-x 2 ian ian  4096 Jan 15 10:52 doc
-rw-r--r-- 1 ian ian 11220 Jan 15 10:52 LICENSE
-rw-r--r-- 1 ian ian   264 Jan 15 10:52 project.clj
-rw-r--r-- 1 ian ian   230 Jan 15 10:52 README.md
drwxr-xr-x 2 ian ian  4096 Jan 15 10:52 resources
drwxr-xr-x 3 ian ian  4096 Jan 15 10:52 src
drwxr-xr-x 3 ian ian  4096 Jan 15 10:52 test
So what we're going to do is write a small service that queries a database from a call over HTTP or via a browser.

First however, we need to make sure we've a database somewhere. I'm using MariaDB, you could use MySQL or any other RBMS system, but you'll need to check some specifics on how to connect. I've created a database called testdb, a single table and populated it with some data. You'll need to use whatever tools your database provides to do this, but for MariaDB (and MySQL I guess) it is the following:
ian@ian@deb1:~/dbtest$ mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 28
Server version: 5.5.34-MariaDB-1~wheezy-log mariadb.org binary distribution
Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> create database fred;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> use "fred";
Database changed
MariaDB [fred]> create table ids (id integer, name varchar(50) );
Query OK, 0 rows affected (0.17 sec)
MariaDB [fred]> insert into ids values (1,"Alice");
Query OK, 1 row affected (0.02 sec)
MariaDB [fred]> insert into ids values (2,"Bob");
Query OK, 1 row affected (0.01 sec)
MariaDB [fred]> insert into ids values (3,"Eve");
Query OK, 1 row affected (0.01 sec)
MariaDB [fred]> commit;
Query OK, 0 rows affected (0.00 sec)
Aside: yes, I should be shot for using the database root user and not bothering about security...agreed! Don't do it and go read up on such things.

Now the two important files are project.clj and core.clj ... use your favourite text editor to open these:
ian@ian@deb1:~$ cd dbtest
ian@
ian@deb1:~/dbtest$ gedit project.clj src/dbtest/core.clj &
Edit the file project.clj so it looks like this:
(defproject dbtest "v0.1 DBTest"
  :description "Simple Test Application"
  :url "http://http://ijosblog.blogspot.fi/"
  :license {:name "Eclipse Public License"
            :url "http://www.eclipse.org/legal/epl-v10.html"}
  :dependencies [[org.clojure/clojure "1.5.1"]
                 [org.clojure/java.jdbc "0.2.3"]
                 [compojure "1.1.6"]
                 [mysql/mysql-connector-java "5.1.18"]]
  :plugins [[lein-ring "0.8.10"]]
  :ring {:handler dbtest.core/app }
  :profiles {:dev {:dependencies [[javax.servlet/servlet-api "2.5"]
                        [ring-mock "0.1.5"]]}}
)
Don't worry about the description, url and license properties or the name of the project. The important things here are the dependencies, plugins, profiles and ring.

These describe the packages that we'll be including in our project, think of them as #includes in C/C++. What we're stating here is that we require Clojure version 1.5.1, Java JDBC , the MySQL connector (works with MariaDB) and a package called Compojure which will handle requests. Additionally we have a plugin ca lled lein-ring which handles the low-level details of HTTP calls plus provides a server to receive the calls. The line stating with :ring states the function that will be called on the start up of the application. The specifics aren't too important at the moment, we can learn about that later.

The actual code that we will run is held in the core.clj file by default. There are clues to Clojure's structuring and packaging mechanisms in the above code and in the directory structure. Firstly the we define the namespace and the packages we wish to include:
(ns dbtest.core  (:use [compojure.core]        [clojure.test] )      (:require [compojure.handler :as handler]            [compojure.route :as route] ))(use 'clojure.java.jdbc)
Then we define the function helloworld:
(defn helloworld []
  "Hello World")
and the functions that handle requests from the client
(defroutes app-routes
  (GET "/" [] ( helloworld ))
  (route/resources "/")
  (route/not-found "Not Found"))
(def app
  (handler/site app-routes))
And that is effectively everything we need to do to get something running. But before you do run, it is necessary to make sure we have all the libraries installed and lein does this for us by consulting the project.clj file, so run:
ian@ian@deb1:~/dbtestlein deps
and let it download everything you need. You generally only have to do ths when you add libraries to the system. Once that has completed (there'll be lots of messages about downloads, or nothing if you've already got everything) start the server:
ian@ian@deb1:~/dbtest$ lein ring server
2014-01-15 11:12:17.221:INFO:oejs.Server:jetty-7.6.8.v20121106
2014-01-15 11:12:17.345:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:3000
Started server on port 3000
A browser window should pop up, but if not start your favourity browser, eg: firefox and point it at http://127.0.0.1:3000 and you should get a page starting Hello World. NB: 127.0.0.1 always resolves to the local machine, so if you have the browser running on a seperate machine (virtual or not) then make sure you use the correct IP address. For the brave you can always use curl to get the body and headers by running the following in a seperate terminal window:
ian@ian@deb1:~/dbtest$ curl http://127.0.0.1:3000
Hello World
ian@
ian@deb1:~/dbtest$ curl -I  http://127.0.0.1:3000
HTTP/1.1 200 OK
Date: Wed, 15 Jan 2014 09:19:09 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 0
Server: Jetty(7.6.8.v20121106)
After you're happy, kill the server with ctrl-c.

Let's now connect to the database by adding the following code between the (ns...) and (use...) and our hello world function:
(let [db-host "localhost"
      db-port 3306
      db-name "testdb"]

  (def db {:classname "com.mysql.jdbc.Driver" ; must be in classpath
           :subprotocol "mysql"
           :subname (str "//" db-host ":" db-port "/" db-name)
           ; Any additional keys are passed to the driver
           ; as driver-specific properties.
           :user "root"
           :password "badpassword"}))
Firstly localhost is the local machine again. I'm running everything on a single machine, but if the database were elsewhere then obviously I'd need to the use the IP address of that machine. And if I were being clever then I'd pull all this in from some configuration file...again, later...

The user and password are used to log in to that specific database (testdb), which if you remember I created using the MariaDB root user (bad!) and also note the horrificly insecure password I was using. Oh and it is an even worse idea to hard code it in plain text in your source file. Don't say you weren't warned. DO NOT DO THIS IN ANYTHNG OTHER THAN A TRIVIAL EXAMPLE, and even then it is probably a bad idea.

After the above code which connects to our database, we add a simple function:
(defn list-all []  (with-connection db    (with-query-results rs ["select * from ids"]      (doall rs))))
This states to use the connection details stored in the db variable and make a query on the database and store the results in as a list called rs and then process it. In this case we're forcing the list to be evaluated using the doall function over the list rs. Clojure is a lazy functional programming language like Haskell, or at least has lazy features.

Now modify the app-routes function so:
(defroutes app-routes
  (GET "/" [] ( helloworld ))
  (GET "/listall" [] ( list-all ))
  (route/resources "/")
  (route/not-found "Not Found"))
Don't forget to restart the server:
ian@ian@deb1:~/dbtest$ lein ring server
2014-01-15 11:12:17.221:INFO:oejs.Server:jetty-7.6.8.v20121106
2014-01-15 11:12:17.345:INFO:oejs.AbstractConnector:Started SelectChannelConnector@0.0.0.0:3000
Started server on port 3000
and in a seperate terminal (or put the URL below into your browser)
ian@ian@deb1:~/dbtest$ curl http://127.0.0.1:3000/listall
{:name "Alice", :id 1}{:name "Bob", :id 2}{:name "Eve", :id 3}
And there you have Clojure returning the contents of the database. After this, kill the server again (note: there is a way to get lein to automatically rebuild and restart the server...exercise left to reader ;-)

Now add the function:
(defn get-by-id [the_id]
  (with-connection db
   (with-query-results rs ["select * from ids where id=?" the_id ]
     (doall rs))))
Aside: the above probably could do with some validation to protect against SQL injection and other bad data (cf: obxkcd)

and modify app-routes so it contains an additional line:
  (GET "/id/:the_id" [the_id] ( get-by-id the_id )) 
and restart the server as before and test with curl (or your browser):
ian@ian@deb1:~/dbtest$ curl http://127.0.0.1:3000/id/1
{:name "Alice", :id 1}
ian@
ian@deb1:~/dbtest$ curl http://127.0.0.1:3000/id/2
{:name "Bob", :id 2}
ian@
ian@deb1:~/dbtest$ curl http://127.0.0.1:3000/id/3
{:name "Eve", :id 3}
ian@
ian@deb1:~/dbtest$ curl http://127.0.0.1:3000/id/4
Not Found
And that's it, a "fully" functioning web service of sorts. 0/10 probably for style and -100000s for security but quite cool for so few lines of code.

--

Here's the final code for the core.clj file:

(ns dbtest.core  (:use [compojure.core]        [clojure.test])      (:require [compojure.handler :as handler]            [compojure.route :as route]          ))
(use 'clojure.java.jdbc) (let [db-host "localhost"    ;; change this as necessary      db-port 3306           ;; change this as necessary      db-name "testdb"]      ;; change this as necessary   (def db {:classname "com.mysql.jdbc.Driver" ; must be in classpath           :subprotocol "mysql"           :subname (str "//" db-host ":" db-port "/" db-name)           ; Any additional keys are passed to the driver           ; as driver-specific properties.           :user "root"           :password "badpassword"}))     ;; change this as necessary!

(defn list-all []  (with-connection db    (with-query-results rs ["select * from ids"]      (doall rs))))

(defn get-by-id [the_id]  (with-connection db    (with-query-results rs ["select * from ids where id=?" the_id ]      (doall rs))))
(defn helloworld []  "Hello World")
(defroutes app-routes  (GET "/" [] ( helloworld ))  (GET "/listall" [] ( list-all ))  (GET "/id/:the_id" [the_id] ( get-by-id the_id ))   (route/resources "/")  (route/not-found "Not Found"))
(def app  (handler/site app-routes))









Wednesday, 30 October 2013

Diagrams Research

For a number of years I and some colleagues have worked closely with the University of Brighton's Visual Modelling Group using their work on diagrammatic methods of modelling and reasoning. One of the areas where we've had quite a nice success is in modelling aspects of information privacy [1] with some particularly useful and beautiful and natural representations of complex ideas and concepts.

Another area has been in the development of ontologies and classification systems - something quite critical in the area of information management and privacy. Some of this dates back to work we made with the M3 project and the whole idea of SmartSpaces incorporating the best of the Semantic Web, Big Data etc.



We've gained quite a considerable amount of value out of this relatively, simple industrial-academic partnership. A small amount of funding, no major dictatorial project plans but just letting the project and work develop naturally, or even if you like, in an agile manner, produces some excellent, useful and mutually beneficial results.

Indeed not having a project plan but just a clearly defined set of things that we need addresses and solved (or just tackled - many minds with differing points of view really does help!) means that both partners: the industrial and the academic, can get on with the work rather than battling an artificial project plan which becomes increasingly irrelevant and industrial focus and academic ideas change over time. Work continues with more ontology engineering in the OntoED project.

References:
  1. I. Oliver, J. Howse, G. Stapleton. Protecting Privacy: Towards a Visual Framework for Handling End-User Data. IEEE Symposium on Visual Languages and Human-Centric Computing, San Jose, USA, IEEE, September, to appear, 2013.
  2. I. Oliver, J. Howse, G. Stapleton, E. Nuutila, S. Torma. Visualising and Specifying Ontologies using Diagrammatic Logics. In proceedings of 5th Australasian Ontologies Workshop, Melboune, Australia, CRPIT vol. 112, December, pages 37-47, 2009. Awarded Best Paper
  3. J. Howse, S. Schuman, G. Stapleton, I. Oliver. Diagrammatic Formal Specification of a Configuration Control Platform. 2009 Refinement Workshop, pages 87-104, ENTCS, November, 2009.
  4. I. Oliver, J. Howse, G. Stapleton, E. Nuutila, S. Torma. A Proposed Diagrammatic Logic for Ontology Specification and Visualization. 8th International Semantic Web Conference (Posters and Demos), October, 2009.
  5. J. Howse, G. Stapleton, I. Oliver. Visual Reasoning about Ontologies.International Semantic Web Conference, China, November, CEUR volume 658, pages 5-8, 2010.
  6. P. Chapman, G. Stapleton, J. Howse, I. Oliver. Deriving Sound Inference Rules for Concept Diagrams. IEEE Symposium on Visual Languages and Human-Centric Computing, Pittsburgh, USA, IEEE, September, pages 87-94, 2011.
  7. G. Stapleton, J. Howse, P. Chapman, I. Oliver, A. Delaney. What can Concept Diagrams Say? Accepted for 7th International Conference on the Theory and Application of Diagrams 2012, Springer, pages 291-293, 2012.
  8. G. Stapleton, J. Howse, P. Chapman, A. Delaney, J. Burton, I. Oliver.Formalizing Concept Diagrams. 19th International Conference on Distributed Multimedia Systems, International Workshop on Visual Languages and Computing, Knowledge Systems Institute, to appear 2013.

Sunday, 13 October 2013

Classifying Information and Data Flows

In the previous articles on data flow patterns and basic analysis of a data flow model we introduced a number of classifications and annotations to our model. Here we will explain two of these briefly:
  1. Data Flow Annotations
  2. Information Classification
Let's examine this particular data flow from our earlier example:


The first thing to notice is the data-flow annotation in angled brackets (mimicking the UML's stereotype notation) denoting the protocol or implementation used. It is fairly easy to come up with a comprehensive list of these, for example as a useful minimum set might be:
  • internal - meaning some API call over a system bus of some kind
  • http - using the HTTP protocol, eg: a REST call or similar 
  • https - using the HTTPS protocol
  • email - using email
and if necessary these can be combined to denote multiple protocols or possible future design decisions. Here I've written http/s as a shorthand.

Knowing this sets the bounds on the security of the connection, what logging might be taking place at the receiving end and also what kinds of data might be provided by the infrastructure, eg: IP addresses.

* * *

The second classification system we use is to denote what kinds of information are being carried over each data-flow. Again a simple classification structure can be constructed, for example, a minimal set might be:
  • Personal - information such as  home addresses, names, email, demographic data
  • Identifier - user identifiers, device identifiers, app IDs, session identifiers, IP or MAC addresses
  • Time - time points
  • Location - location information of any granularity, typically lat, long as supplied by GPS
  • Content - 'opaque' data such as text, pictures etc
Other classes such as Financial and Health might also be relevant in some systems.

Each of the above should be subclassed as necessary to represent specific kinds of data, for example, we have used the class Picture. The Personal and Identifier categories are quite rich in this respect.

Using high-level categories such as these affords us simplicity and avoids arguments about certain kinds of edge cases as might be seen with some kinds of identifiers. For example, using a hashed or so-called 'anonymous' identifier is still something within the Identifier class, just as much as an IMEI or IP address is. 

Note that we do no explicitly define what PII (personally identifiable information) is, but leave this as something to be inferred from the combination of information being carried both over and by the data flow in question.

* * *

Now that we have the information content and transport mechanisms made we can reason against constraints, risks and threats on our system, such as whether an unencrypted transport such as HTTP is suitable for carrying, in this case, location, time and the picture content; or would a secure connection be better? Then there is also the question of whether encrypting the contents and using HTTP?

We might have the specific requirements:
  • Data-flows containing Location must be over secured connection
  • Secured connections use either encrypted content or a secure protocol such as HTTPS of SFTP.
and translate these into requirements on our above system such as
  • The flow to any social media system must be over HTTPS
Some requirements and constraints might be very general, for example
  • Information of the Identifier class must be sent over secured connection
While the actual identifier itself might be a short-lived, randomly generated number with very little 'identifiability' (to a unique person), the above constraint might be too strong. Each retrenchment such as this can then be specifically evaluated for the additional introduced risk.

* * *

We have shown here is that by simple annotation of the data flow model according to a number of categories we can reason about what information the system is sending, to whom and how. This is the bare minimum for a reasonable privacy evaluation of any system.

Indeed even with the two above categories we can already construct a reasonably sophisticated and rigorous mapping and reasoning against our requirements and general system constraints. We can even as we briefly touched upon start some deeper analysis of specific risks introduced through retrenchments to these rules.

* * * 

The order in which things are classified is not necessarily important - we leave that to the development processes already in place. Having a model provides us with unambiguous information about the decisions made over various parts of the system - applying the inferences from these is the critical lesson to be taken into consideration.

We have other classifications still to discuss, such as security classifications (secret, confidential, public etc), provenance, usage, purpose, authentication mechanisms - these will be presented in forthcoming articles in more detail.

Constructing these classification systems might appear to be hard word; certainly it takes some effort to implement and ensure that they are active employed, but security standards such as ISO27000 do require this.


Sunday, 6 October 2013

What I look for in a software engineer

When called to assess or interview someone for a software engineering position there are a few things I look for: the core set of knowledge on which we can build upon to support the more specialist or esoteric skills such as security, privacy and the rest. I discussed ideas for what would be required for a grounding in concepts for privacy earlier.

Programming Skill
  • This is obviously the first question - "can you program?" and then in what languages. The usual candidates will always be there, ie: Java, Python, C, C++ etc, but I'd like to see things such as SQL, Prolog, Lisp and maybe things like Haskell, ML, Ada, Eiffel etc. Depending upon the position PHP, Perl, Unix shell script etc.
  • Ideally the candidate should understand and appreciate the differences and respective advantages of the various programming paradigms: structured, object-oriented, functional etc
  • "Programming" in markup languages is not acceptable: HTML IS NOT A PROGRAMMING LANGUAGE.

Design Skill
  • The ability to use design languages such as UML, SDL etc, must always be a prerequisite. Correct use of these come with and comprehension of abstraction and refinement of designs.
  • Abstraction is a very underappreciated and rarely seen skill. The ability to concentrate on what is required without mixing abstraction levels unnecessarily is one of the marks of an engineer.

Discipline and Formality
  • Despite agile being the saviour of everything a true appreciation of what agile actually is, is necessary. The understanding that designs follow a natural flow from concept through design to implementation is invariant - good software can not be hacked.
  • Communication is obviously part of this and clear coding, design and concepts is fundamental.
  • Experience with formal methods is always a clear advantages. Now whether someone actually uses Alloy, B, Z, VDM etc in another matter altogether; the skills and discipline that comes with these is what we're looking for. Some of the best "coders and architects I have come across are formal methods people at heart; indeed I know of on agile guru who attributes his success to applying formal methods within an agile framework (see communication, abstraction and refinement above).
  • This also extends to areas such as testing of code, simulation of design and defensive programming though ideas such as design by contract - all of which contribute to a better quality of development and code.
Fundamentals
  • Does the software engineer have a grounding in computer science and/or mathematics? Having this allows the engineer to concentrate on the underlying principles of things without being distracted by arguments over whether something should be represented in XML vs RDF vs JSON, or SQL vs NoSQL etc.
Obviously this just touches the surface of what is required but I hope it gives some idea of what is required. Not all skills are needed, so if someone doesn't have 3 years experience of category theory and programming with monads (the minimum to write "hello world" in Haskell I'm told), but an appreciation and understanding is required.

Ultimately engineering is about solving problem with discipline, rigour and use of the appropriate techniques.

Wednesday, 4 September 2013

The Art of Writing Good Documentation: Teach, Don't Tell

Just come across this posting on how to write documentation, or more specifically, how to write GOOD documentation. It is by Steve Losh and called Teach, Don't Tell.

For example:

If you use many open source libraries you’ve undoubtedly encountered some whose README says something like “read the source”. Every time I see one, I die a little bit inside.

Source code is not documentation. Can you learn to be a guitarist by simply listening to a piece of music intently? Can you become a painter by visiting a lot of museums? Of course not!

This is one of the main reasons why we gave up on brilliant languages, frameworks etc- for example, this is the main reason why we had to give up on Opa sadly.

This is always the case when the experts in a language, framework, library etc are those who are developing the langauge, framework or library. They are so consumed by developing they forget the people who want to develop with their creation.

Teach the developers how to do something, don't fob the developer off with function signatures, obscure examples etc. If a developer is asking naive and "stupid" questions then there's probably a damned good reason why.

Maybe reading Zen and the Art of Motorcycle Maintenance should be compulsory for all?


Monday, 22 July 2013

Children of the Magenta

Children of the Magenta is a term used to describe pilots overly reliant on automation rather than trusting their own skills in flying an aircraft. This video from an American Airlines training session, where the term "children of the magenta" was coined - due to the colour of the flight director bug or icon - is essential viewing not just for pilots but for anyone involved in driving, managing or building systems of any kind:

In particular I want to present the bullet points from one slide and then address another aspect regarding levels of automation:

Automation Dependency
  • The pilot flying should remain as 'one' with the aircraft in any low altitude maneuvering environment with the autopilot engaged
  • To maintain situational awareness of both aircraft performance and flight path.
  • The autopilot and autothrottles have limitations which affect performance
  • Crews are returning to the autopilot in an attempt to resolve a deteriorating situation
  • Autopilot and Autothrottles, however good, cannot recover the aircraft from a critical flight attitude

If we consider what we do in software engineering, and especially in areas where there are strong privacy and security aspects such as any form of web and database development, do we end up relying upon our skills and technique or do we blindly follow process and procedure? Do we blindly follow waterfall or agile processes to their logical conclusion and attempt to beat that deadline and deliver something knowing that the quality of the delivered product is deteriorating. Do we allow our processes to become our overly trusted autopilots?

Finally three levels of automation were presented: low, medium, high. The lowest corresponds to hand flying, the medium to using the autopilot to guide the plane and the highest using the flight management computer to run everything.

I want to discuss these in a later post, but for now I'll leave it as an exercise to map these level to how we act in a given software engineer project.

Probably the biggest takeaway from this lesson in aviation when applied to any aspect of software engineering is:
If you are losing control of any aspect of project then the process won't correct it; only you as a software engineer will - if you take control.
And that applies to any aspect of the system: functionality, performance, security, privacy etc etc etc...


Thursday, 18 July 2013

Asiana Flight 214 and Lessons for Software Engineering


Tony Kern's book Flight Discipline [1] discusses the notion of discipline related to flight safety through his experience flying, training and by example - almost invariably by way of a crash.

It is testament to the aviation industry overall how safe flying has become through the application of safety procedures and techniques, and also the very real need for pilots to be extremely disciplined in their work. The same concepts are also being applied in industrial and medical environments too as described earlier in this blog.

This week however has seen an accident at San Francisco airport involving Asiana Flight 214. The causes (note: plural!) are being investigated by the NTSB and I'm not in any position to appropriate blame, but I do think this will become quite a seminal accident in terms of what is found.

At the time of writing it is known that the aircraft was believe to be in a thrust managed mode which should have kept its speed and that the crew somehow allowed its speed to decay and mismanaged the final stage of landing. There are another set of possibly contributing factors such as CRM, crew fatigue, experience, the ILS being out of operation, a visual approach etc. This of course is compounded by the fact that hundreds of other aircraft have landed successfully at SFO in recent weeks under similar conditions.

Whether or not this is the fault of the pilots, a fault of the automatics on the aircraft or a combination of a host of those and other factors is to be ascertained. One thing that seems to be sure is that the pilots failed to monitor a critical aspect of the aircraft's situation. In Kern's terms the discipline of the pilots to maintain proper checks has failed. This will be an interesting case to follow, possible a seminal case with respect to discipline.

In terms of software engineering or specifically some aspects of developing with security in mind, I've been discussing with a colleague about SQL injection attacks and that these are remarkably easy to detect and defend against - though also remarkably easy to write. Given this, we still seem to be detecting vulnerable code remarkably often.

So this leads to the question why are we still writing code vulnerable to SQL injection if it is so easy to detect?

King puts forward four reasons for breakdown in discipline, which we can put into our context:

1.    Programmers don’t know the procedures for developing and testing code that is susceptible to SQL injection.
2.    Programmers don’t know the techniques to avoid writing code vunerable to SQL injection.
3.    Programmers forget either of points 1 and 2.
4.    Programmers willfully decide to ignore points 1 and 2.

Most programmers do know about the errors and pitfalls of particular implementation technologies, so the failure in discipline does not necessary lie mainly there. Even if it does, this is corrected simply by training.

Regrettably one of the excuses is always that the programmers are being “agile”: up against deadlines, constantly and inconsistently changing requirements, no or poor specifications, lack of emphasis on design and thought, and poor organisational communication. Errors can be fixed in a later sprint (if remembered and the if the fix is implemented). This then ends up with vulnerabilities such as SQL injection being forgotten by the programmers.

Willful ignorance of vulnerabilities follows from the previous point. As vulnerabilities are luckily not often exploited at run-time and if in place detection methods will probably catch these errors, then the programmers can often get away with vulnerable code. Furthermore, responsibility for the code nor the maintenance does not fall often with the original programmers or software engineering team.

Could it be that in software engineering we still have the hero mentality? Ironically it was many of the early 'hero' pilots who actively developed the procedures and techniques for safe flying.

Unlike software engineering the economics of bad flying proved to be a powerful incentive for actively pursuing good flying techniques and ultimately very sophisticated safety programmes. Maybe the only way of solving the discipline problem in software engineering is to radically alter the economic argument.

The economics of flying badly tends to end up with deaths and often the pilot’s own life (it is probably even worse if he/she survives) – the direct and collateral costs here are easily calculable. The economics of security errors in programming aren’t well understood nor calculated.

If a SQL injection releases one million records of personally identifiable information, why should the programmer care especially when there are little or no consequences for the programmer, the software engineering team, the managers and the business overall?

I don't suggest that we start killing programmers for errors, but maybe alter the way we prize teams for getting software into production. The fewer changes and bug fixes over the first year of a product's life = bigger bonus; inverting the bonus for bug fixing? Should we be more like hardware engineers and increase the costs of compilation of code such that a software engineering team gets only 1 chance per day to compile their code with penalties for compilation errors?

To finalise, maybe Tony Kern talking about discipline and what makes a great pilot - now apply this to software engineering, privacy, security etc etc:




References:

[1] Tony Kern (1998) Flight Discipline. McGraw Hill 0-07-034371-3


Tuesday, 16 April 2013

Programming Language Frustration

I've been writing a lot of Opa recently - for those of you who don't know, Opa is a framework for writing web software without the hassle of worrying about database connections, distribution of code between front and back-end systems, asynchronous vs synchronous calls etc. It also cleverly integrates code, HTML and CSS holistically into the language. It is basically a mix of cool functional programming ideas with Javascript and a compiler that generates Javascript to run on Node.js; along with MongoDB (and soon Postgres) integration.

What Opa is brilliant at is abstracting away from all the awkward stuff that web (and thus distributed and network) programming. To make life simpler and programs more robust it is also strongly typed but does support polymorphism, variant (or sum) records etc. It can be a bit of a pain when settling down on your data schemata BUT you should be thinking hard about this stuff anyway. For you agile people go read about technical debt, for the privacy people who also worry about data, go read about the slow data movement.

It has its fair share issues too; some features are missing, eg: monads, but that's curable, but the main problem with Opa, and this is shared amongst many cool things in the software engineering community, and that is documentation.

Opa has a book and basic tutorials, a twitter feed, API documentation and forums (locally and StackExchange), plus you can actually get hold of the guys developing Opa. All very good but the experts on Opa are the people who developed Opa and not the people developing in Opa.

Opa's programming community is very, very small and this seriously holds back the acceptance of use of the language.

In Pirsig's book Zen and the Art of Motorcycle Maintenance, Pirsig talks about the quality of components - specifically how threading the head of a screw can render the greatest motorbike useless. The quality of the whole is dependent upon even the smallest, singular part.

And so it is sometimes with Opa: the lack of a specific example, a relevant explanation for a particular function in a library, how to compose specific kinds of database query etc, can bring a project to a screeching halt with no way forward. Getting past this is critical to any larger scale acceptance and use of the framework/language.

For Opa to succeed it needs better integration between the Opa developers and the developers of Opa. It needs a constant stream of questions, bad code, good code, homemade tutorials etc to develop that external body of knowledge, a set of patterns, case studies from industrial environments, cool solutions to common problems, etc.

I'm constantly amazed at how quickly I can get things done with Opa (apart from CSS which really is the language of evil and frustration) and would recommend it to anyone who needs to develop quick web applications. But to those who do use it, please give something back to the community in expressing what went right and what went wrong, patterns for common problems (eg: OAuth, social network integration, database usage etc)

OK, enough venting of frustration...back to honest coding now...pity that so little time is spent with Opa, most of it seems to be fiddling with the user interface (html and css)...sigh :-)

Links


Friday, 25 January 2013

On The Naivety of Privacy

Recent events regarding privacy and the internet have left me wondering if we are being somewhat naïve. We are starting to see a slew of new laws, strategies and technologies for protecting our privacy in what is effectively a public space. The end-user however is not, as far as I can tell, really getting the benefit of this - indeed if anyone is it is the emerging privacy-industrial complex [1] as some have written.

It is utterly naïve to believe that laws, strategies, intentions, grand speeches, certifications, automatic filtering, classification iconography and so on make for better end-user privacy. The more we do this the more confused we become, and simultaneously we lose sight of what we're really trying to achieve. Spare a thought for the poor end-users.

There is a great deal that is misunderstood or not known by privacy advocates about how the internet, computers and information systems work - I fear in a lot of cases either some don't want to understand because it takes them outside of their comfort zone, or the semantic gap between the engineers and the legal/advocacy side is too great and that bridging this gap is extraordinarily difficult for both parties.

I worry about our lack of formality and discipline, possibly in equal quantities. We – the privacy community – lack these aspects to really understand and accept the fundamentals of our area and how to apply this to the information systems we are trying to protect. In some cases we are actively fighting against the need to scientifically ground our chosen area.

We must take a moment to think and understand what problem we are really trying to solve. The more philosophical works by Solove and Nissenbaum address the overall concept of privacy. I'm not sure that the implications of these are really understood. Part of the problem is that general theories of information [2] are very abstract and obtuse when compared with the legal views of the above authors, and we've done very little to tie these areas together to produce the necessary scientific formalisation of privacy we need.

As an example, the Privacy by Design (PbD) manifesto is being waived by many to be the commandments of privacy and following these magically solves everything. This only leads to “technical debt” and greater problems in the future. Often we find the engineers, R&D teams and the scientists excluded from, and outside of, this discussion.

I think we're missing the point what privacy really is and certainly we have little idea at this time how to effectively build information systems with inherent privacy [3] as a property of those systems. I have one initial conclusion:


WE HAVE NO UNDERLYING THEORY OF PRIVACY


We have no common definitions, common language, common semantics nor mappings between our individual worlds: legal, advocacy and engineering. Worse, in each of these worlds terminology and semantics are not always so well internally defined.

When an [software] engineer says “data collection”, "log" or "architecture", these do not mean the same to a lawyer or a consumer advocate. Indeed I don't think these terms semantically map even remotely cleanly – if at all - between these groups.

A set of PowerPoint slides with a strategy, a vision, a manifesto, good intentions, project plan or a classifications scheme mean very little and without some form of semantics are wasted, token efforts that only add to the complexity and confusion of a rapidly changing field.

We desperately need to address the problem that we must create a way of communicating amongst ourselves through which all of the internal factions within the privacy community can effectively understand each other's point of view. Only then might we even have a chance of realistically and effectively addressing the moving target of privacy issues facing end- users and businesses that rely so much on the interchange and analysis of information.

The problem with formally (or rigorously) defining anything is that it has the nasty tendency to expose holes and weaknesses in our thinking. Said holes and weaknesses are not entirely appreciated, especially when it challenges an established school of thought or a political or dogmatic balance [4].

The privacy community is constantly developing new laws and legal arguments, new sets of guidelines, manifestos and doom scenarios while the engineers are trying to address these often inconsistent and complex ideas through technical means. From the engineering perspective not only we are internally exposing flaws in database design, information system architecture and user experience but also the mismatch between engineering, legal, the world of the consumer advocate and ultimately a company's information strategy.

An information strategy needs to address everything from how the engineers develop software to how you want your company to be perceived by the consumer. How many information strategies actually address the role that information plays in a modern, global consumer ecosystem where the central concept is the collection and processing of user information? Of those, how many address the engineering and scientific levels of information?

We must take a serious retrenchment [5] step and look back at what we have created. Then we need ruthlessly carve away anything that does not either solve the communication issue within the privacy community or does not immediately serve the end-user. Reemphasizing the latter point, this explicitly means the end-user values, not what we as a privacy community might perceive to be valued by the end-user.

We must fully appreciate the close link between privacy and information, and that privacy is one of the most crosscutting of disciplines. Privacy is going to expose every single flaw in the way we collect, manage, process and use information from the user experience, as well as the application and services eco-system, and even the manner in which we conduct our system and software engineering processes and information governance. The need to get privacy right is critical not just for the existence of privacy as a technical discipline in its own right (alongside security, architecture, etc) but also for the consumer and the business.

The emphasis must be placed on the deep technical knowledge of experts in information systems – these must be the drivers and unifiers between the engineers, the lawyers, the advocates and ultimately the users. Without this deep, holistic, scientific and mathematical foundation we will not be able to sufficiently nor consistency address or govern any issues that arise in the construction of our information systems at any level of abstraction.

If the work we do in privacy does not have a scientific, consistent and formal underpinning [6] that brings together the engineers, lawyers and advocates then privacy is waste of time at best and deeply destructive to the information systems at worst.

Without this we are a disjointed community caring for ourselves and not the business or consumer and privacy becomes just a bureaucratic exercise to fulfill the notions of performing a process and metrics rendered as meaningful as random numbers.

* * *

PostScript:

Via Twitter I came across a talk given by Jean Bezivin entitled "Should we Resurrect Software Engineering?" presented at the Choose Forum in December 2012. Many of the things he presented are analogous to what is happening in privacy. He makes the point a number of times that we have never addressed the missing underlying theory of software engineering and how to really unify the various communities, fields and techniques in this area. Two points I particularly liked was that we concentrated on the solution (MDE) but never thought about the problem; the other point is the use Albert Camus' quote

<< Mal nommer les choses, c'est ajouterau malheur du monde >>
[To misname things is to add misery to the world]
A subtle hint to getting the fundamentals right: terminology and semantics!


Notes

[1] #pii2012: The Emergent Privacy-Industrial Complex

[2] Jerry Seligmann, Jon Barwise (1997) Information Flow. Cambridge University Press.

[3] I like the idea of privacy being an inherent construct in system design in much the same way that inherent safety emerged from chemical/industrial plant design

[4] A blog article discussing “mathematical catastrophes” – two that come to mind are Russel and Frege and also Russel and Gödel. Both related but the latter’s challenge to the mathematical school of thought was dramatic to say the least.

[5] A formal retrenchment step in that we not just start again but actively record what we’re backtracking on. Poppleton et.al. constructed a theory of retrenchment for software design using formal methods; the same principles apply here.

[6] If you’re still in doubt just remember that whatever decisions are made with respect to privacy, there’s a programmer writing formal, mathematical statements encoding this. Lessig’s Code is Law principle.