[bsaunder]

Complexity can sometimes be a perspective thing. I recall a discussion at one point with a co-worker were we were each arguing that the other persons approach to a particular problem was more complex. After much contemplation I was able to see both perspectives.

Also with some problems there seems to be a conservation of complexity notion. It's inherent in the system and depends on where you push it.

For the book, you might want to check out Large-Scale C++ Software Design. Unfortunately it's at home so I can't crack it open and double check, but it seemed full of suggestions on structuring code and layout a large software project.

[sorbits]

Yes, I agree that a lot about how to structure code is subjective, which is also why I am very interested in having better terms to describe this — thanks for the book suggestion!

Giving it some more thought, I think it boils down to realizing when one is solving more than one problem, and then being able to write the code so that each problem is solved in isolation, yet without introducing complex APIs between the different pieces of code.

Often though the sub-problems are subtle and hard to predict, plus realizing that two problems are being solved is not in itself enough to figure out how to actually split it up (sometimes splitting things up contributes to the perceived complexity)…

[arakyd]

My favorite book of this type is Thinking Forth, available online at http://thinking-forth.sourceforge.net/. You will get a large dose of the Forth mindset, but it's mostly higher level design tips and not as specific to Forth as, for example, How to Design Programs (read: Functional Algorithms in Scheme). It's a fun read, and a great way to get a perspective on design that is different than what you get from the usual object-oriented or functional language centric sources.