(goading the universe here a little, I love it when things turn out to be solvable)

The fact that AllAbstractionsLie leads to the common software development problems. The problems have no definitive solutions, only an assortment of techniques for handling them.

Symptoms of the problem : Naming collisions, mental model breakdowns, unstable layered abstractions, anti-patterns, wiki fights, HolyWar''''''s, intellectual property rights abuse.
----
'''The Context Problem''' - PatternContext, HiddenContextProblem, PatternDictionaryGame & PatternDictionaryGamePlusPlus, PatternHaltingProblem, TriteSayingsComeInPairs, BeyondPatterns, PatternInEverything

ExtremeProgramming is wonderful for certain problem contexts (AgileSoftwareDevelopment), not so good for others (requirements driven/heavy thud factor development). It's not that the patterns here are wrong, it's that they only make sense once the developer has already seen the context in real life. Currently, context is described in the canonical pattern form. 

Unsolved:
* What is the canonical context form?
* How can patterns automatically reference other pattern choices for a similar problem context?
* If there is a PatternInEverything, what is the point of patterns at all? Shouldn't they emerge or be inferred?
----
'''The Language Problem''' - LaynesLaw, TripleMeta, MeaningfulName''''''s, ProfessionalConsensus

There are naming collisions between english word and computer science terms. Words like "model" can mean beautiful person, mental model, 3d model, development model, architectural model. We use words from language because they are similar to a pattern in code, but that can cause problems when the words differ slightly and we waste energy describing the differences. It's like we need a way to invent new words, or a larger vocabulary that isn't limited to words that were meant to describe other (non-computer) things. This problem was previously a minor one, but computers are nowe so integrated in our lives that most words in english have computer-specific meaning.

Unsolved:
* How do we prevent naming collisions with the common spoken language? 
* How can we get past mutating common spoken words into programming terms? Should we invent new words or steal old ones?
* Do I know a thing if I can name it in one spoken language, or recognize it without hearing the name - but can't name it in someone else's spoken language?
* Differing definitions for terms advocated by different members of the community (different vendors, promoters of different methodologies/tools; see DefinitionsForOo for one such collection).

Potential solutions:
* Qualify common terms with adjectives - i.e. user interface, not just interface.
* ShouldComputerScienceUseLatin
* Arrive at a ProfessionalConsensus for definitions for terms, abritrated/decided/imposed by some authority (legal or otherwise) if necessary.

Tainted words - used in too many different contexts:
* Model
* Vector
----
'''The Abstraction Problem'''  - AllAbstractionsLie, AbstractionDevelopment ManagingProjectComplexity

Software development is one of the few crafts where intangible models are built on other intangible models. Mapping between our mental space and what becomes raw assembly code causes collisions (LaynesLaw applied to development).

Unsolved:
* If AllAbstractionsLie, how are layers of abstractions properly built?
----
'''The Orthogonality|Entanglement Problem''' - Non-orthgonality pops up everywhere as a big software development problem and wiki problem. ChasingTheDragon often results.

This Wiki is cyclically coupled with software development. Humans lust over innovation, and the desire for new vectors in software development would be(because of entanglement) expressed here as this page. That is, this page may be ambiguous - authors may desire innovation in software development or innovation in this wiki - I don't think the wiki itself needs innovation at this point though. Many of the difficulties we face are due to the nebulous nature of software development. Wikipedia has excellent computer science pages(which are hard fact), and terrible software development pages(which is always relative). Software development in general is having a hard time progressing forward right now, and I think the C2 difficulties reflect that. I don't know the solution, I only know the problem. Are the problems of indisputable truth in society & law the same as in software development design? Is it really all relative and arbitrary?

Unsolved:
* How are non-orthogonal & entangled features dealt with coherently and visualizably?
* Where is the documentation for how non-orthogonal issues are organized and resolved?
----
Software is built by turning abstractions into code, then layering abstractions on top of each other.

Is there a weak point here? If abstractions must become literal code, then they aren't abstract - they are code. There are three aspects here:
the code, the abstraction, and the offspring of the two (code that is treated as an abstraction). Perhaps this is susceptible to the entanglement problem.
----
Small quantities of exceptions ruin clean abstractions. Sometimes a real simple abstraction handles 95 percent of the cases, but handling the last 5 percent requires messy tweaks, conditions, etc.
----
See: InterestingProblems (for computer-science related problems) 
----
Contributors: LayneThomas