Common sense says to keep things simple and this is one of the rules good application architects live by. However, as noted in fields from biology to software code modularity, complex problems require complex solutions. Sometimes there is an obvious need to have complicated code, and sometimes it is beneficial to make enterprise application code structure more complicated than it may seem to need on the surface. This is usually to make existing applications more flexible so they can grow to meet ever changing business challenges. The code base must be developed with the knowledge that a successful system will have to support growth within the application in order to meet the business needs without.
For example, imagine two development teams with easy Web development tasks. For the purpose of this example, make them really easy – "Hello World" easy. But keep similar real-world situations in mind. The first task is to develop a webpage that displays the plain text "Hello, world!". Team A keeps it just as simple as can be: No Java on the back end, just "Hello, world!" in the body of an html doc. Team B does a little more work than they strictly have to and build a simple Java program to write "Hello, world!" in HTML.
A little later down the line, requirements change. Now the client needs Web links to outside content built into the page. This is a fairly simple update for either team. Team A has no problem adding in a link with their simple HTML model. Team B, again showing their superior know-how, modify their simple Java application to use a plain old Java object to insert a Web link. So far Team A is in the lead. Their code is simpler and it's taken less time to build.
But the requirements haven't stopped coming in yet. Next the client needs to have their Web page readable in several different countries. They've got the original copy in the three major languages used in their geographical area of operation and they need to supply the correct version for each end-user based on the default language of the Web browser. Here's where Team B starts taking the lead. While Team A is still trying to figure out how to redirect users to separate language pages based on Web browser defaults with the HTML they are used to, Team B is converting the new translated copy into object relational mappings of the original.
Object-orientation makes the complex task of internationalizing a server application much simpler. Team B just creates one simple server-side script that checks the browsers default language and serves up an appropriate version of the copy based on what it finds. The script is written in ten minutes, the translations are processed in a short while, and in only a few hours, Team B has saved the day. (Yay team B).
So, perhaps when an architect is making some simple tasks way more involved than they need to be the architect is just being a jerk – OR – maybe he has a good idea of what requirements are still coming down the pike, and he just wants to be prepared. Of course, in this example the complicated fix is still pretty simple, and Team A probably could have switched course right at the end and still come up with the same solution. However, in real life the simple code is usually more complex than the complex part of our example, and I don't even want to consider what the complex case really entails.
Allowing the team to always take the simplest approach to meeting the letter of the requirements is tempting, but it's probably not the right way to go. It takes great foresight to introduce the right style of solution now for the types of problems you'll see later down the line. Unfortunately, there's no simple rule to know exactly what's best. Object orientation and modularity introduce certain complications to some of the simpler aspects of writing code. Sometimes, you might not need that elegant of a solution. But more often than not in today's application development environment flexibility and scalability are the keys to maintaining successful application architectures.