By Sarbjit Bakhshi, Lead Technologist ICT, Technology Strategy Board.
This is a shortened version of the full post from Sarbjit's blog.
Following my last post, I've been meeting companies and academics to discuss the role of culture in software programming. On the 24 May 2012, I held a mini-Workshop on the subject at the Mixed Reality Labs (MRL) at Nottingham University. The Mixed Reality Labs are doing some very interesting, cutting-edge work on interaction and design and collaborate with the theatrical group Blast Theory and ethnographers in the University.
At the workshop we mulled over the fact that software has its origins in defence, accountancy and machine control and that software design reflects this mindset. When applied to social situations instead of machine control, software design is often reductionist, managerialist, and has been described by some as employing a decomposition methodology. It boils down human problems to something a computer can solve, and this is frequently not the same thing the original problem, because it ignores all externalities that might have a bearing on the problem. Jack M. Carroll, now from Penn University, is quoted saying that this approach was akin to losing your keys and searching under a lamp post, not because you lost your keys there, but because the light was stronger.
Non-specialists in computer science need to interact with big data, and program computers without a particular process in mind. They need environments in which they can play with data to achieve their outcomes. They also need software programming environments that allow collaboration and bring in non-users - all within an environment that reflects rather than imposes their own culture.
From my discussions with computer programmers, I've found that they often confess to having difficulty understanding what the client wants. In the workshop, we discussed alternatives to traditional software design approaches. In particular, we looked at the use of narrative in capturing the culture of the client and using it as a medium to communicate this to the programmer. From the narrative, the programmer could develop prototyping tools that the client could configure, and these would then serve as the design brief.
The narrative approach represents a break from existing culture and avoids the "If you want to get to there, I wouldn’t start from here" trap. It brings in externalities, culture, emotions and all those things that would have been traditionally excluded from software design. It also allows the use of Internet of Things (IoT) devices to replace the keyboard-screen-mouse paradigm.
For this new approach to design, the benefits must be made absolutely clear to everyone involvedL software engineers, the clients and the owners of software design companies. This is always the most difficult part to introducing a new approach. This may be borne from the way that software is commissioned, or the way that it is still regarded in some quarters as a dark art that cannot be understood by lay people!
In order to continue this discussion, the TSB will probably run a series of workshops around the country (Edinburgh, Brighton and London seem to be the best locations to start with). Let Sarbjit know if you would like to be involved.