Using a framework will harm the maintenance of your software

> The definitions of "framework" are always a sticky issue.

Hence why the article defines what it means by framework, and by the definition in the article, software rarely has any implied frameworks within as one of the definition points is that there is code in the framework the user is not free to change.

There certainly can be frameworks emerging within large projects, but by the definition in the article they're not problematic because they don't lock you in: You can change those pieces. You in particular ultimately remain in charge of the flow of control in the code. Those "frameworks" don't take away control and put you in a straightjacket.

The article could perhaps have been framed better as "how to write a framework or framework-like thing which doesn't become a problem". Some thoughts might be:

* Structure it as decoupled components where you can opt in and opt of different elements, including of control flow. E.g. Padrino - a Ruby web framework fits well here. You can pick and choose which ORM to use; you can opt in to a router, controller, admin interface, mailers, logging, caching, and view libraries, or not use them at all. You can start with plain Sinatra and add in bits of Padrino as and when you choose, or supply your own.

* In particular, if possible, externalise the control of flow into replaceable components. Doing this alone can often be enough to get you out of the straight-jacket of "frameworks as defined by the article"

* Allow users to override/replace all components rather by defining clear interfaces and not assuming you can call hard-code calls between the different components. Padrino again fits well there. So did e.g. Qmail treated as a "framework for building a mail server" ("nobody" used pure Qmail, but Qmail defined the interfaces between each individual program which made up the full system, so you could replace every single bit step by step). In particular there should be no "magic" glue which there isn't a well defined way of tearing out.

A library is not a framework. You can write framework-free apps while using libraries (in fact, most do - not wanting to be burdened with a framework doesn't mean you have to write all functionality yourself).

A framework is either about inversion of control (it calls your code, e.g. you write web request controller logic, and it sets up the infrastructure for calling your controllers), and/or a set of ways to structure your code, like classes to extend, folder structure, a set of patterns you must follow to work with it, like a specific MVC-like organization of code, and so on.

1. "If you don't use a framework, you will end up creating one" -- And that's exactly how successful frameworks were born. If everyone uses an existing framework, who is to create better frameworks for the future?

2. Framework vs. Library -- Framework calls your code; Library is called by your code. There is clear inversion of control. The article touched on this, but I think it's a very important distinction to call out.

3. Framework makes me think inheritance. Library makes me think composition.

4. Framework is like CPUs. A more powerful CPU is a more powerful CPU, no doubt; but you need more power to bring out the performance. If your company don't have the resource to deal with the maintenance, Framework becomes a liability rather than asset. But if you can sustain it, it should still be a net positive.

5. In addition to the mixing of domain and non-domain concerns, poor Framework bring incomplete abstraction that expands the surface area for reasoning/debugging/maintaining. A good framework should provide the perfect abstraction that frees the developer from having to descend the stacks. I consider programming languages as good "frameworks". So are the layered networking architecture.

6. Watch out for self-fulfilling prophecies. e.g. in the web frontend framework space, a framework might claim it helps solve problem X, but it might also be very cause problem X. Accessibility, Routing, State Management... a lot of these can be solved by using the platform. Before you reach out for a framework, be sure to assess platform capabilities and single purpose libraries first.

7. Reliance on framework can be caused by lack of knowledge. If you are a manager, give your team the time, money, and endorsement they need to learn things, attend conferences, and provide ample budget for training and technical book purchase. They might pay more dividends than a framework does.

“When designing a system, the goal should be to defer major decisions for a long as possible.”

I noticed that I tend to do this, but never knew it was a legit strategy.

But that is also (or can be) an anti-pattern. Don't just blindly add dependencies - there are so many risks involved with that. Of course that is not unique to just frameworks like Django and Rails, but any piece of growing software.