I\'ve been working for a consulting firm for some time, with clients of various

Question

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.

Explanation / Answer

...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.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.