text: Q:
  
  Is there really anything to gain with complex design?
  
  I've been working for a consulting firm for some time, with clients of various sizes, and I've seen web applications ranging in complexity from really simple:
  
  MVC
  Service Layer
  EF
  DB
  
  To really complex:
  
  MVC
  UoW
  DI / IoC
  Repository
  Service
  UI Tests
  Unit Tests
  Integration Tests
  
  But on both ends of the spectrum, the quality requirements are about the same.  In simple projects, new devs / consultants can hop on, make changes, and contribute immediately, without having to wade through 6 layers of abstraction to understand what's going on, or risking misunderstanding some complex abstraction and costing down the line.  
  In all cases, there was never a need to actually make code swappable or reusable - and the tests were never actually maintained past the first iteration because requirements changed, it was too time-consuming, deadlines, business pressure, etc etc.  
  So if - in the end - 
  
  testing and interfaces aren't used
  rapid development (read: cost-savings) is a priority
  the project's requirements will be changing a lot while in development
  
  ...would it be wrong to recommend a super-simple architecture, even to solve a complex problem, for an enterprise client?  Is it complexity that defines enterprise solutions, or is it the reliability, # concurrent users, ease-of-maintenance, or all of the above? 
  I know this is a very vague question, and any answer wouldn't apply to all cases, but I'm interested in hearing from devs / consultants that have been in the business for a while and that have worked with these varying degrees of complexity, to hear if the cool-but-expensive abstractions are worth the overall cost, at least while the project is in development.
  
  A:
  
  ...would it be wrong to recommend a super-simple architecture, even to solve a complex problem, for an enterprise client?
  
  It depends on the client. Many will be fine with a more straightforward approach. Some will think that you're incompetent because that simple approach will not solve their problems - the whole "that thing must be super cheap for a reason..." thing that causes some stuff to be way more expensive than it costs to make.
  
  testing and interfaces aren't used
  
  I would argue that there is no way in hell that you can cost effectively make non-trivial software without either of these. As a company, if you tried to sell me something without them, I would fear that you will saddle me with a completely inflexible, unmaintainable pile of steaming dog poo. (edit: to be clear I'm talking about interfaces here, not interfaces. Procedural and functional programs are not all piles of crap, even though they lack Java-style interfaces.)
  
  if the cool-but-expensive abstractions are worth the overall cost
  
  As program designers, we need to make educated guesses about where things will change, and draw lines there so that things that change can do so quickly, easily, and correctly. Good abstractions will save you money over time because inevitable change becomes cheap. 
  But make no mistake, the term "architecture astronaut" exists for a reason. You are not always building the space shuttle. Adding bad abstractions that either exist in the middle of things that need to change, or exist to support change that does not exist... they can cost you.
  But in my experience, I've heard people complain about over abstracted code, but I've only seen projects fail due to under-abstracted code.
  
  A:
  
  To Architect, Or Not To Architect
  To rephrase Einstein, "things should be as simple as possible - but no simpler." It's important to understand the true use of some architectures - and they aren't necessarily for individual performance, and often not  for job satisfaction either.
  Sometimes architectures are so complicated because an enterprise project is just so large, with so many people at work, that the architecture is largely to allow so many people to work towards something without everyone tripping over everyone else. They are, at times, little more than complexity added that reduces individual productivity and makes work harder - but permits large numbers of people to work. This works when the added effort outweighs the individually decreased will to live, err, I mean "productivity".
  Is this your client's situation? Well, if their budget isn't in the millions for this project, maybe not. If it's under a 100k, then almost certainly not. You build a concrete bunker for a nuclear reactor, not a wood burning stove :)
  It is not necessarily wrong to suggest "the simplest thing that could possibly work" for your client, if that's what the situation calls for. It might be the best possible way to handle it. The easiest way to see is compare it to commercially available/open source projects that are designed to accomplish a similar task (this is your due diligence market research, anyway), and see what it took them to do what they did. 
  Of course, when you are working with millions of dollars you should be aware of some perverse incentives in play. In short, "ass covering": if you recommend a super complex architecture system that requires a PhD to understand properly, when it goes to hell who's fault was it? Not yours, of course - you suggested only the finest in sophisticated technologies that everyone says is the best - but they are "complicated" and "difficult", so the blame is with the people who tried to implement it. They must have just not been smart enough or skilled enough...in other words, lots of advice is given to ensure you don't look bad when projects fail, which they inevitably must as not all projects are successful. It's bad juju, but it is a fact of our reality.
  Failure To Follow Through
  I would suggest that failure to continually update tests and follow-through on architecture decisions (tossing plans when they change instead of updating them, etc) is why so many systems end up being thrown out and rewritten from scratch or wholesale replaced with a new 'solution' a few years down the road. 
  When things that enforce clarity and consistency are thrown out for expedience, it is easy to sometimes think you were very sly and are really "Getting Things Done" when in fact you made future changes harder and more complicated; it is very common to steal from future productivity for immediate gains. Its bad specifically when no one realizes that's what's happening.
  Testing, for instance, is specifically best suited to when things change. You change the tests to reflect what the new direction is, and then go about fixing all the stuff that is now "broken" because people changed their minds or came to a realization that they missed something last time. This is like giving up sleeping because you have a lot to get done this week - its going to make things harder.
  In Conclusion, "It Depends" (Helpful, Isn't It?)
  Architectural complexity is an overhead cost, like renting a larger space for a brick-n-mortar business; it only makes sense when there is real complexity that needs to be managed. If it's a team of 3 working on a solution that is relatively conventional, simple MVC and minimal tooling is probably entirely sufficient. 
  If it's a complex, multi-subsystem, enterprise software solution, with millions on budget and at least a half-dozen teams of 3-5? You're going to be begging for the sweet, sweet love that only round-trip engineering on object oriented program analysis and all its charts and diagrams and models can give. Anything to help you keep the dozens or hundreds of sets of eyes from unblinkingly staring at you, wondering what they are supposed to do today and how they are supposed to get anything done at all.
  
  