Monthly Archives: January 2011

ACM considered harmful

The Association of Computing Machinery is the premier US representative body for computer science and according to its own blurb:

“serves its members and the computing profession with leading-edge publications, conferences and career resources”

Well, yes and no.  The ACM may perhaps serve its members but for sure it does not serve the profession in general. It has copyright policies for publications which don’t respect the rights of members and it restricts information to those who are not members either explicitly or by excessive costs.

Firstly, the copyright issue. The ACM, in common with other organizers, requires those who have papers published in its journals and conferences to sign over the copyright to them. This means that you can’t republish a paper elsewhere and that the ACM can charge for your writing without paying you any fee. If you are not a member of the ACM’s Digital Library and you lose your own article, you have to pay to get a copy back from them.  Remember ACM don’t pay for articles but (as discussed below) don’t hesitate to charge – and as an author, you get no revenue.

Another area where the ACM’s policies are restrictive is in access to information. I tried today to access what I thought was rather a good idea – a tech pack in cloud computing, which is an annotated bibliography of articles in this area. But to access it, you need to login i.e. its not a resource for the profession but for members only.

Correction. I have been contacted by the ACM and it has been pointed out that you don’t have to be an ACM member to get a login to access the tech packs. I have included the full response from the ACM as a comment to this post.

I also tried to access the ACM Digital Library to get a copy of a paper that I had written in 1988.  This was interesting to me as a historical document but let’s be honest – it doesn’t have much to do with modern CS. Now, my university is an ACM subscriber so I could access it for free but the ACM actually ask for $15 for non-members for this (and all other) articles.

How can this outrageous sum be justified for articles, especially when only very limited information about that article is available. While I think that there is some rationale for charging a small fee (not $15) for very recent papers, all papers that are more than a few years old should be available to the profession for free.  I really can’t believe that this would have a significant effect on ACM’s revenue stream. The Computer Journal gets it right in making its articles available.

The ACM should realize that if they wish to be taken seriously, then they have to broaden their vision and truly serve the profession – this is how they can expand their membership.

Older readers will recognize that the title comes from Dijkstra’s famous letter published in the CACM in 1968 “Goto statement considered harmful”. You can buy this classic of CS literature for $15 from the ACM Digital Library. Fortunately, there are enough people who are willing to ignore ACM copyright rules – its available here for free.

37 Comments

Filed under CS education, Reading

Reductionism and Software Engineering

Reductionism is a philosophical position that a complex system is nothing but the sum of its parts, and that an account of it can be reduced to accounts of individual constituents (wikipedia).

This notion is the foundation for the engineering of large systems  – essentially, design a system so that it is composed of discrete parts which, because they are smaller, are easier to understand and construct, define interfaces that allow these parts to work together, build the parts of the system then integrate these to create the desired system.

Most researchers in software engineering have taken a reductionist perspective and their work has either been around finding better ways to decompose problems or systems (e.g. work in software architecture), better ways to create the parts of the system (object-oriented techniques) or better ways of system integration (e.g. test-first development).

At one level, this has been quite successful – for sure, the software systems that we can now build are much more reliable than the systems of the 1970s and 1980s. From another perspective, the approach has been less effective – there are no general interface standards that have allowed a software components industry to emerge, except perhaps in very specific domains.

Reductionism as a basis for software engineering is based on 3 fundamental assumptions:

1. That the creator of a system has control over all of the parts of the system and therefore can decide whether or not to do work to change a part or make it work with another part.

2. That the system is being developed in a rational world and the design decisions will be primarily based on technical criteria.

3. That the system is being developed to solve a definable problem and that system boundaries can be established.

Of course, we know these are optimistic assumptions in practice and the reality is that they are hardly every true. Consequently, there are difficulties and problems in constructing large software systems because they use unknown components, because decisions are driven by a political agenda and because the problem being addressed either hasn’t been properly defined or can’t be properly defined.

The majority of software engineering research is based on a reductionist perspective and new techniques are developed to decompose systems into their parts, construct and validate these parts and then assemble them into a system. A good example of this is model-driven architecture which raises the level of abstraction at which we design a system and provides some automated support for part implementation and assembly.

However, researchers are often disappointed at the slow take up of new methods in software engineering. The problem here is that they subscribe to the reductionist assumptions of rationality – because something is better from a rationalist analysis, they can’t really understand why it is not adopted. Of course, the reality is that we don’t live in a rational world and that most decisions are made on the basis of prejudice and evangelism, rather than rational analysis.

Nevertheless, reductionism has served as reasonably well. We can and do build large and complex software systems although these often take longer and cost more than originally estimated. But the larger and more complex the system, the less valid the reductionist assumptions and so reductionist approaches are less useful.

I now believe that we are facing a situation where the reductionist methods that have sort of worked for software have reached their limits and the type and complexity of systems that we are now building requires us to think differently about systems engineering.

But that will be the topic of a later post.

4 Comments

Filed under Uncategorized

Computer science education and the real world

Enrolments in computer science degrees (in the US and Western Europe) have fallen drastically over the past few years, although I believe there has now been an increase in applicants from the low point in 2008. Part of this was a reaction to the 2001 dot-com crash but I believe that another factor is that many if not most computer science degrees are increasingly irrelevant as far as real-world computing is concerned.

There are two major areas of real-world computing that, IMHO, don’t get enough attention in computer science degrees. One is embedded, real-time systems. We are surrounded by such systems – I counted 9 in my home office alone apart from the computers (router, scanner, printer, 3 phones, 1 ipod, 2 cameras) yet some CS degrees simply don’t cover them at all and the majority probably only offer a single optional module. The other area is my own interest of large-scale systems engineering. Current large-scale systems are not built from scratch using waterfall processes but are constructed by reusing software at different granularities from program libraries to entire systems.  Requirements are negotiated and issues such as throughput, dependability and security are critical. Most courses do include some software engineering – an essential starting point for considering large-scale systems engineering but then they stop. They don’t include courses on topics such as dependability and enterprise systems architectures.

Why have we got ourselves into this state where CS degrees are about programming rather than systems? The argument I hear from my colleagues is that programming is fundamental (true) and learning to program in Java (or perhaps a functional language) and to analyse programs for e.g. complexity is all you need. This, I think, simply is a weak justification of an untenable position – that systems are just scaled up programs.  We have arrived at this state because of two basic problems with our university system:

1. It’s very hard for people in universities to keep up with changes in the world. People who were appointed 20 years ago have spent their time scaling the academic career ladder and many of them have had little or no contact with industry since they were appointed. Essentially, they have no idea what real-world computing is like.

2. People’s career in universities depends on their research. As researchers are clever people, they have derived lots of ways to publish research and so support career development. The community itself assesses the value of the research and relevance to industry is rarely a factor in this assessment. In fact, its often harder to publish work done in industry, even in software engineering, because it doesn’t tick all the academic boxes of what constitutes a good paper. Therefore, people do ‘excellent’ research in irrelevant things. Often, they are committed teachers and the research informs their teaching – but they don’t want sordid reality to intrude and actually have to teach something useful.

Of course, both of the above reasons are  (slightly) exaggerated presentations of reality but the blunt reality is that the reason why universities don’t teach real-world computing is that many of the faculty just couldn’t do it.  There may be intellectual value in a programming-oriented CS degree (as there is in a degree in Classics or Philosophy) but I believe that we must also design our degrees so that students are better equipped to make a contribution to computing as it is, rather than computing as it was.

39 Comments

Filed under CS education

Coalitions of systems

Dave Cliff wrote a short piece on the ‘flash crash’ on 6th May 2010 when there were extreme and unexpected fluctuations in US stock prices (link here when its online). While there remains some uncertainty about the cause of this, a very significant factor was interactions between the high-frequency algorithmic trading systems used by brokers to trade stock, sometimes several hundreds of times per second. Some emergent behaviour in this collection of systems led to the dramatic price fluctuations.

This is an example of the kind of problems that arise from system complexity where there are dynamic relationships between the components in the system. Understanding and at least partially managing this type of complexity is, in my view, one of the major challenges that faces the systems engineering community. Work we can draw on comes from the ‘systems of systems‘ (SoS) community but I don’t think that the collection of systems that led to the flash crash should really be called a ‘system of systems’.

I always think of a system according to Peter Checkland‘s notion when he developed Soft Systems Methodology as something that is purposeful, with the implication that the system serves the purpose of some individual or organisation. Therefore, a system of systems is primarily an organisational notion – some organisation puts together systems (which may be inside or outside that organisation) to do something that’s useful to the organisation.

But the interacting algorithmic trading systems that led to the flash crash are owned by different organisations and they are probably systems of systems in their own right. They serve purposes of the different owners (and these may be different although in this case they probably have the common underlying purpose of enriching their owners) and they only cooperate because they have to. The owners are often competing and may be mutually hostile. Each system jealously guards its own information and may change without consultation with any other systems.

I don’t think it makes sense to call this collection of systems a ‘system of systems’. Rather what he have here is a ‘coalition of systems’ where systems work together, sometimes reluctantly, because it is in their mutual interest to do so. Coalitions of systems are not explicitly designed but come into existence when different systems interact according to some agreed protocols. Like political coalitions, there may be (but doesn’t have to be) hostility between the members and the coalitions may break down if one system changes so that it no longer fits.

For those of us working in complex systems engineering, we need to think about coalitions of systems as well as systems of systems. We can’t design dependability into the coalition as there is no overall design authority; nor can we control the behaviour of individual systems. Maybe we have to be thinking about dependable protocols where the protocols are not just concerned with defining how the systems can interact but also act as a regulator ensuring that interactions are within some acceptable bounds? Perhaps we should also be thinking about containment (analagous to the concrete around a nuclear reactor) to ensure that when things go wrong, the damage that can ensue is limited.

2 Comments

Filed under Uncategorized