I thought that "Out of the Tar Pit" (Moseley & Marks, 2006) classified complexity excellently: > Essential Complexity is inherent in, and the essence of, the p

I thought that "Out of the Tar Pit" (Moseley & Marks, 2006) classified complexity excellently: > Essential Complexity is inherent in, and the essence of, the problem (as seen by the users). > Accidental Complexity is all the rest — complexity with which the development team would not have to deal in the ideal world (e.g. complexity arising from performance issues and from suboptimal language and infrastructure). > ... > For example — according to the terminology we shall use in this paper — bits, bytes, transistors, electricity and computers themselves are not in any way essential (because they have nothing to do with the users’ problem). --- You can't reduce essential complexity without sacrificing your ability to solve the problem. (Of course, this isn't to say it's never a valid way to meet a deadline.) Reducing accidental complexity is a noble cause though, but as an engineer, it can be difficult. It sometimes precludes using shiny new technology, or even making it yourself. Maybe the user's problem can be solved with an off-the-shelf solution. Or maybe you don't need a full website and database because a spreadsheet will suffice.