Very true: Software is knowledge first of all, and only then style, syntax, languages, services, whatnot. And thus software development is getting knowledge and "storing" it as code and data.

There are two additions though. While confusion may be normal, but for experienced guys it only concerns specific missing knowledge. The methodology to be "unconfused" should not be the area of confusion.

Also all those user stories and other requirements explanations can be noisy, adding to confusion. Sometimes the noise comes from good- and simple-looking UI sketches, which later turn out to be logically flawed. One example can be a search criteria widget, where UI designer allows arbitrary AND and OR between several criteria, which is looking nice, but does not work in practice as priority of operations is hard for end user, eg in A or B and C and D or E the user does not necessarily apply priorities correctly, which can result in ((((A or B) and C) and D) or E) instead of math logic's convention of (A or (B and C and D) or E)

The cure to that is what I call conceptual design, which should be performed before UX design. (I do not remember any more where I read about the term... maybe some book on DDD - Domain-Driven Design). Conceptual design (in my version at least) includes laying down the ontology (backbone of knowledge on how things are), identifying domain's main concepts (entities, relations, interactions) from domain experts, understanding how those link with the existing software. In a sense, it's quite high-level view, which gives place for more detailed knowledge.

It is not uncommon also that during analysis phase (which conceptual design is), a better solution can be found than just implementing user stories one by one, because it's a place to recognize patterns.