The counterexample to the this line of reasoning comes in the form of nightmarish home-grown frameworks that have emerged slowly from years of piecemeal additions to that original small problem. These accidental frameworks often wind up replicating many features of prefab frameworks, without any of the tests, documentation or architectural forethought that would have come with a pre built one.

I don't always see the need for a framework, but once you've gone through the process of learning the ins and outs of one, which does indeed take extra time the first time around, it's a familiar tool and can really speed things up when you re-use it in the future. Now if you try out a new framework on every new project, that's a different story...

I think the crux of the original point is: Don't use a framework when you need a library.

For example, I ripped NHibernate out of a project because the SQLite database only had 6 tables. (Later reduced to 3 tables.) In this case:

- The original author used NHibernate incorrectly, making the product 10,000x slower then it should be

- There's a high learning curve to NHibernate that all newcomers to the project must go through

- There's a risk of having to work around an NHibernate bug

- We have to ship NHibernate and adapt to new versions or potential security holes

- The lawyers have to approve of the NHibernate license

- A small, infrequently updated xml file using built-in serializers is much easier to work with then SQLite + NHibernate.

Sure, we probably have about 1000 lines of DAL code instead of 200 lines of hbm files; but it's DAL code that's bug-free and has no external dependency risk.

Would I use NHibernate, or a different DAL framework, in a different context? Sure! If we had many more tables, and changed our schema frequently, it would be the correct thing to use. It's all about understanding when to use a framework versus a library.

Frameworks are anti-modular because they expect to be the world into which you plug your program. They’re prefab software architecture, which is great if it happens to be suited to your application, but painful if you later discover you have different needs.

To me, the defining feature of a framework (as opposed to an ordinary library) is that it’s explicitly not compositional, not replaceable, and not a “good citizen” for interoperation. Doesn’t sound great.

But there is a valid reason to incur these costs: prefab solutions let you ship something basically good now. The same thing happens in game development: do you just write a game, reinventing a lot of architecture now, or do you choose an engine, working around its limitations later? It’s more of a business decision than a technical one.

Your totally right about this, in most occasions. People look for short-cuts and fall in love with novelty shiny magic that appears nice on the surface. but, they don't evaluate the long term costs - that's what kills productivity in the long term: the cost of not understanding what a framework does in certain situations, or how to debug it when it's not working right. with code, you can always step into it and figure out what's going on, not necessarily the case with frameworks.

This works for small projects that only you touch. However, if you are building a product for a company and plan on having teams make changes to the code base, frameworks are the way to go.

It's even easier when hiring because a big portion of your training is already done before the person is hired and they are knowledgeable in said framework.

I've found that the bigger problems are:

- Confusing design patterns with frameworks

- Using frameworks incorrectly

- Using a framework when a library is more appropriate

For example, Dependency Injection should start as a design pattern, and then a framework brought in based on the project's requirements. A couple of screens of "new" statements have very little learning overhead. No framework can define the way an application's modules relate with each other.

That a person is familiar with a framework doesn't guarantee they'll require significantly less learning for a company's particular project. In fact I'd argue that if one's use of a framework makes the learning curve so small, the project is probably not that complicated in the first place.

Agreed! Frameworks, libraries, and APIs are all about tradeoffs. Because they will never make sense for some programmers and use cases, the last line of code will probably never be written... but there's an undeniable trend heading that direction for so many. Thanks for reading.