Bottom 10 Software Engineering Challenges
My account of the Top 10 Software Engineering Challenges has elicited an enthusiastic response. Strictly, a lot of pageviews, which may not be the same thing, of course. This has tempted me to do what I know you (secretly) really want: assemble the bottom 10 software engineering challenges. These are sinks of research effort that are undeserving of the attention devoted to them, because either the problems they address are unworthy, or are so overworked that the incremental advances possible do not merit the work put in. Or actually, in some cases, both. Perhaps there is some personal prejudice here too. This sort of work does not fit my 'style', runs counter to my aesthetic. Lets be clear however, this is not a criticism of individual pieces of work so if you recognise your work in a particular 'challenge' please do not hold it against me, I intended to provoke, but not to offend.
The Search for Meaning (another semantics for UML). UML notations have a weak semantics. The notations do not provide for a precise interpretation. It is, of course, possible to give a precise meaning to some of these notations, that is to choose among the possible interpretations. This makes sense, providing you believe that the notations are not purposely weak. Given however, that the syntax of the notation is inadequate to carry the meaning you are then no longer able to rely upon it as a communication tool. In short, this is a fairly forlorn occupation and it would be better to spend the effort on developing better notations that carry their semantics.
Never-ending Quest (model transformation languages & model-driven architecture). The idea that the development of software systems should proceed by way of orderly refinement, ideally semantics-preserving from a high-level specification, has constituted a research strand in software engineering for a lengthy period. It has manifested itself in different forms, most recently in model transformation languages and the MDA, but the core idea remains constant. This despite the fact that the process of development is one of learning and revision rather than linear progress. The idea that changes could be made in a high-level specification and then somehow 'replayed' is appealing but ignores the ways in which such learning arises, in the context of specific representations and through verification or testing tied to that representation.
Looking Under the Lamppost (empirical studies of this and that - mostly that). I have argued that we need an evidence-based discipline of software engineering. This necessarily means thorough, well controlled, empirical studies. The end is however, not the study itself but the question it addresses. It is all too easy to study areas where the data is readily available or where the object of study lends itself to analysis. Thus studies of inspections, pair programming, bug fixing and so on. Why? Because there is plenty of data and the subjects are easy to control. Now, do not get me wrong, these are not insignificant areas but the challenge lies in gathering empirical evidence relating to the messy, difficult areas, particularly requirements and architecture.
When You Have a Hammer Everything Looks Like a Nail (machine learning for dummies). Open source software development has provided a broad range of research opportunities; hitherto, only a few researchers had access to large repositories of software engineering artefacts. Now everybody has this research asset. Machine learning was a specialist discipline requiring considerable mathematical and technical skill to use, it has now been routinised and packaged: "there must be something in all that data ... if only I knew what it was ... perhaps this box of magic tricks will help ...". The problem here is that, if you don't know what you are looking for, how will you know what you have found?
These Are Not the Droids You are Looking For (service discovery). So let us hypothesise that you have many different fragmentary services from different providers each with different properties and you want to determine, on-the-fly, which one you should select so that you can compose them at run time into your application or business service. Well, in that case you need a sophisticated service discovery system. Otherwise, you probably do not. So there we are, you probably do not.
Look at my Pretty Picture (unprincipled visualisation). Software engineering has been pretty poorly served by work on visualisation. Given the need to understand complex codebases and domains as well as the results of large scale analyses you would have thought that it would be an excellent target. Looking around however the work seems very thin. The point here is not to produce a graphic but to produce a visualisation that yields insight. 3d, surfaces, kinect sensing, integration with 2nd life and the like, are all very well but in the absence of some meaningful target they simply produce pretty pictures. What is needed here is a change in direction where visualisation proceeds from a principled understanding of objectives.
And Again with Feeling (another demonstration of formal methods). The benefits of formal specification associated with formal reasoning have been amply shown in numerous small examples and a very few more sizeable cases. Nothing is served by a further demonstration with a slight different notation or another neat twist in refinement or proof. The reasons these techniques have not been adopted lie outside the techniques themselves, in the tools, the users and the way the software development process is organised. Unless you are going to tackle these problems, no further technical improvements will give additional purchase.
Playing Lego (component models). I appreciate that the exact semantics of different component models may differ and that the relationships between components can be difficult to understand but I am not sure the world needs another account of the complexities associated with existing middleware systems.
Configuration Management Rediscovered (product families). Very few organisations set out to develop a complex product family with multiple variants of essentially the same product. It is usually the case that it just ends up like that. Where however, organisations do have to develop product families they work hard to keep that variation as small and as well bounded as possible. Anything else just buys complexity to little gain. This is a problem that configuration management is pretty good at handling. Do we need to develop a separate research discipline around product families to deal with something we have adequate tools to handle already?
Requirements Management Redux (another requirements model). The idea of requirements management systems in which requirements statements can be organised in hierarchies, tagged and cross-linked is now well established. There have been commercial tools doing this for 20 years to the best of my knowledge. Another slightly different schema or set of tags, a different sort of database, adds very little to the picture and there is no need to keep reinventing essentially the same functionality.