Is this inclination a part of our nature or is it a part of our culture?
closed as not constructive by Walter, user8 Oct 1 '11 at 11:28
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.
Alex Papadimoulis of thedailywtf has written a very interesting article that touches on this subject: http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx
Basically he says that many of the work we do is under-challenging or boring, which leads smart programmers like yourself to overcomplicate in design in order to keep enjoying the work. Is that familiar to you? I certainly have been guilty of this.
The conclusion would be that it is in our nature to look for challenges, but that we want to generate a culture in which writing challenging code and building software are basically two different things.
I myself find that work needs at least some challenge and enjoyment, because without these it's very hard to keep focused and do the work right. So I would say that we want to create a culture in which challenging code is a part of software development, as long as it is well tested and actually gets the job done without overcomplication. And I can thoroughly enjoy software that is concise and to the point way more than software that is over engineered.
We consider things to be simple when we have fully understood them. This is supported by the elaborateness of cargo cults, which are very complex systems because they are ill-understood.
Most programming happens in the "not yet understood" zone, because most fully understood projects have already been programmed earlier. (As a notable counterexample, consider compilers and compiler theory.) So, it is in the nature of software engineering to produce complicated things because we have not yet grokked the problem fully, to understand them in the process and then refactor the code. KISS and YAGNI try to suppress our tendencies to build too much code too early.
Conclusion: It is part of our nature.
I think a considerable contributing factor is the expectation that requirements will change. That's clearest with YAGNI: it's explicitly attacking the idea "I don't need it yet, but I might in the future".
the answer has two parts. the first one is the perspective of developer and the other one as user perspective.
the user intents to do want everything as easy as possible. the user does not know anything of the background, of daemons, of process, processors etc.. the user doesn't want to know anything of that. and this shouldn't be a condition to use a program.
the developer part is quite complicated since the developement process is quite complicated. as developer you should be a good designer, a good coder, a good tester and many more. a lot code is build during understanding like thiton said. and in my opion: the most code seems to be build in a hurry. time schedules and competition lead to urgency. so many problems with ugly code could be avoided if you could take more time for coding. not the money driven hastiness.
my conclusion: bad process management and rare time.