PhD research student. Start date 2008-12-01
My supervisors are Dr John Bullinaria and Dr Rami Bahsoon
I had a lot of poor jobs when I young, then went back to education. I worked hard in the IT industry after getting my BSc in computer science. Then I tried my hand at self-employment. I know I am lucky to be doing a PhD and intend to enjoy it. I am fairly healthy, have a diverse range of interests, and a fantastic wife. Life has dealt me a good hand so far.
I am interested the classic problem of 'too complex system retirement'. It emerges as follows: A small change to a complex system is deemed too risky, expensive, and disruptive, so it is put-off. Many of these small changes accumulate and the system becomes less 'fit for purpose'. At some point an accumulation of required changes passes a critical level where they are too risky, expensive, and disruptive to ever implement. Enough of those and the system becomes 'unfit for purpose', then it is time for a new system, but that too is risky, expensive, and disruptive. Eventually the old system is so problematic that it becomes clear that a new system would be better.
This scenario demonstrates a problem with the usually successful human strategy of iterative improvement. It may not work well when the improvement is increased sophistication, because that is accompanied by increased complexity. The alternative strategy is to 'start over', but that gets less efficient more quickly than iterative improvement as systems become more complex. The question naturally arises: How do we manage continuously extending complexity so we can better use iterative improvement? A complexity hiding strategy is one possibility. Another is to minimise the complexity for a given level of sophistication. Complexity is partly a function of the number and strength of dependencies, so it would be good to reduce both. I am conjecturing that may in part be achieved with a change of focus from a behaviour centric view of systems to a data centric view. I propose to make data independent and reduce dependencies between behaviour and data. Consequently, I am looking at techniques that weaken dependencies between data and software, allowing each to evolve according to independently changing requirements, but that treat data as the principal.