When deciding upon how to design a software project with my colleagues, most suggestions tend to be for using specific frameworks "because it's popular in the job market" or "that's the framework that gets recruiters on the phone," and never what I'm looking for which is, "because it's a good fit for the project as it makes the system more adaptive to future changes and makes life easier for developers."

I didn't start looking at projects in this way until I started reading up on domain-driven design. I've found that the actual domain is hidden deep under the frameworks used and it's hard to learn the business processes that have been implemented by the software product.

Is there a way to marry the two competing goals: getting exposure as a development team while still being able to avoid complexity? Are frameworks that compromise, or are there other solutions out there?

  • I agree with you. For example, Hibernate makes you write tons of ugly XML files. Nov 6, 2012 at 16:44

3 Answers 3


I don't think frameworks are a cause of over-engineering. More often than not, frameworks remove boilerplate code and simplify the codebase that you are left to maintain.

I also agree with Thorbjorn's comment that it's a bad idea to expect an API for everything. Much better to have the runtime environment focus on the things that appear in almost every application and be flexible enough to allow frameworks to be added where other common problems are solved.

However, I have seen instances (outside the Java world) where frameworks are used for the sake of using a framework. I see why you think this is bad, and if it overcomplicates the product then it is. But it should be kept in mind that if a developer is given room to improve his CV, they're going to see more reason to stick around and learn even more.

As long as a developer is likely to back down if he finds that a framework is not helping, there are good reasons to let them have a go.

But in reading your story, I see a bigger problem -- not understanding the business domain. Too many products are written without any regard to actual business problems, just attempting to produce something that developers think should help. This is not the fault of frameworks in any sense, it's the fault of developers, but it needs fixing somehow.

How you do that depends very much on the structure of the team. But make lots of comments along the lines of "Do you not think we would be more satisfied in our jobs if we thought we were writing software that would make people's lives better?"

Or arrange for developers to sit in with the people who will use the software and see the problems that they face every day and offer solutions.

Or, if it comes to it, play to the career angle. I mean who wants to go to their next interview and say "yeah, we did our best, but it was never the product the customer wanted," rather than "so I went out into the business and investigated the model and used DDD techniques to turn that into a software model"?

  • I like what you'd said. In general, I see developers rattle off tons of frameworks and it becomes a test of "Who knows the most frameworks out there?", and whoever wins that argument, beats the other developers into submission, but they seem to overlook that knowing all the frameworks out there doesn't make you a good software developer, it's knowing the right tool for the right job and understanding the domain correctly is a per-requisite for that. Sep 28, 2011 at 20:43
  • The answer to that phenomena is simple. Let them win. Walk away. Google "FrameworkName" and "FrameworkName problems" and see what you can find out. When, and only when, you're more informed than they, reopen the conversation.
    – pdr
    Sep 28, 2011 at 20:58
  • pdr, by that time the project has moved on and people are too apathetic to reheat the question until the problem surfaces with another volley of frameworks listed. The point being that the whole thing drowns in academic discussion. Sep 28, 2011 at 21:13
  • Well, no. I would expect to have enough information to have the conversation within a couple of days. I wouldn't expect a framework decision to be irreversibly entrenched, even within a couple of weeks. If it is, you have a different problem.
    – pdr
    Sep 28, 2011 at 21:41

Are frameworks the catalyst of many of the over engineered projects out there


or is it something much more simple?


If you'd encountered these issues in a software project, how have you dealt with it?

Ignore it.

Are there any good key indicators to look out for when a project is being over engineered?


Would you like some suggestions?

Or was the question merely rhetorical?

One leading indicator of over-engineering is people complaining about over- engineering. Seriously. Other people complaining.

Over-engineering means this:

Extra features are thrown in for which there are no requirements.

Flexibility, Scalability, Availability and all the other non-functional requirements are often thrown into a project because users (or product owners) only care about functional requirements.

Some folks really like to discuss non-functional requirements in a great deal of depth. Adding all kinds of things.

Some folks like to deprecate the non-functional requirements. Removing essential features to make the software "lighter-weight" or "more transparent" or some such.

One person's essential is another person's optional.

Since everyone's wrong, everyone's also right, too. There's a middle ground somewhere.

What's important is that frameworks provide a standard suite of non-functional requirements at essentially zero cost. Clearly, that's no fun. Who wants to focus on the user's confusing requirements?

Avoiding a framework means all the standard suite of non-functional requirements must be built from scratch. Clearly, that's more fun. Avoiding the user's actual requirements to focus on non-functional requirements is more like real programming.

  • 2
    S.Lott. No, the question was not rhetorical, I'm genuinely interested in other peoples views given that this place is supposed to be a "Q&A site" for programmers and not a clique of regulars that quickly attack people for asking questions they don't like. I think you need to appreciate that many of the people who come here are from different backgrounds, thus, you'll get different types of questions. Sep 28, 2011 at 20:20
  • @DesolatePlanet: I thought the question was clear enough to answer. Please don't complain. "Are there any good key indicators to look out for when a project is being over engineered?" is a trivial Yes-No question. Often trivial yes-no questions are merely rhetorical. Writing trivial yes-no questions is merely a question of editing. The answer would be "Yes". Not helpful, is it? So I did two things. (1) I pointed out that it appeared rhetorical in form. (2) I expanded anyway. Please don't complain. Please Update the question or Ask for clarification.
    – S.Lott
    Sep 28, 2011 at 20:31
  • Well, your reply is good to where I can restructure the question, so thanks for that. if you'd given me that in the beginning, I wouldn't written the first reply. I have every right to complain if I feel I'm being attacked on a question I've put forward. I'm not interested in wasting other people's time. Sep 28, 2011 at 20:34
  • 3
    @DesolatePlanet: "I have every right to complain if I feel I'm being attacked". Actually. You don't. First, your emotional responses are your personal problem. Don't read things into an answer that aren't there. Second, complaining doesn't improve anything. Either Fix the question or ask for clarification. That's how you get information. Complaining gets you nothing.
    – S.Lott
    Sep 28, 2011 at 20:46
  • Very rude answer. Nov 6, 2012 at 16:46

When choosing frameworks, consider this stuff:

  1. How many dependencies there are in the framework. What other libs, programs, environments, computers or systems it requires. How much effort it takes to maintain all the dependencies? Less effort is better.
  2. Once the original developer of the framework disappears, what will happen? Is maintaining the framework impossible, difficult, requires 1000 people team
  3. Is it popular enough that there will always be people who care about the framework, and volunteer their time and money to maintain it, even if it is boring and/or annoying work while the whole world thinks there are better frameworks (already) available
  4. what is the time before the framework is going to disappear and considered obsolete
  5. what is the size of the interface you're going to use. Small is better.
  6. Does the framework conventions try to divide your code to 22 differently shaped pieces? Does it enforce any conventions on your code? Beware of callbacks that need to be implemented. Beware also naming/memory management/api conventions that spread all around your code.
  7. Did the framework move annoying or burdensome part of the development work to your responsibility, or does it try to handle and simplify it
  8. Can you use the whole framework's functionality, or is what you're planning only using small part of the framework. If you're using small part only, then the framework might be too burdensome to maintain for you.
  9. Which programming languages or environments the framework relies on? Is that environment going to be available in the future? Several vendors providing the environment?
  10. Is there easy way to isolate the framework to a box which can be changed?
  11. How many of your source files need to use the framework? Smaller number is better.
  12. How much effort you save when you decide to use the framework? What problem it solves? How much extra effort you need to do to take it into use, and maintain it forever.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.