Unsolved problems in software engineering
There is not a canonical list of unsolved problems in software engineering; however, there are the following issues:
- Is it possible to simulate a human mind?
- Is computer consciousness possible?
- Is it possible to solve any NP-complete problem quickly (in polynomial time)?
- Will software complexity continue to match or exceed Moores Law?
- Is it possible to have computers solve their own problems, in particular configuration problems or problems involving improper setup, integration or programming?
- Is it possible to write software that users can themselves extend and interact with to solve the actual problem they want to solve, as opposed to the software that was written by the developer in a general way?
- List of antipatterns, which might be thought of as statements of poor practice, in contradistinction to the list of design patterns
- Poorly predictable relationship of project duration to program functionality
- Systematic detection of software defects
- Statistical tendency of project to run behind schedule and over-budget
- Adding additional manpower to a lagging software project (especially in later parts of the project) may actually cause further schedule slippage due to overhead experienced during the integration of new employees. See w:The Mythical Man-Month.
- Current complexity of most programming languages, in general
- Current complexity of most applications, to the extent that companies fail when programmers leave, if those companies have no one else who understands what the programmers have done.
- Non-standard implementation of standards or specifications by multiple organizations result in a requirement for implementation specific code and special case exceptions as a necessity for cross-platform interoperability. Notable modern examples include web browser compatibility and web-services interoperability. Companies create competing standards to solve their own problems and use their political clout to market the standard and themselves. Although competing standards sometimes improve upon existing problems, rarely do they replace or even provide an improvement upon current standards. That is to say that while a portion of the competing standard may outperform the other current standards in one area, a portion of the competing standard will suffer.
- Differential implementations of standards by one specification. One explanation is that the early-adopters program according to an older, outdated version of the spec. Another possible explanation is that the companies' different implementations revealed after-the-fact that the specification had unclearly-defined or ambiguous rules. Eg: different blog software companies have implemented the metaweblog api based on the metaweblog api specification, although they did so differently since there was confusion about the methodNames of those methods shared with the blogger api (blogger.methodname vs metaweblog.methodname).
- Arbitrariness of most software concepts, which is related to historical hardware and software implementation, lack of common standards worldwide, and economic pressures.