How do I avoid the complexity concerns of frameworks while keeping my team marketable?

Question

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?

Answer 1

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"?

Answer 2

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

No.

or is it something much more simple?

Yes.

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?

Yes.

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.

Answer 3

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.