There have been a number of discussions out there in the ether about frameworks vs. libraries, what they are, how they differ, which is better and why. Here’s my $0.02 on frameworks. I’ll do a compare and contrast piece in a follow-up post.
Frameworks evolve. They’re the by-product of refactoring. Libraries on the other hand are designed.
Libraries are tools which can be used over and over again to accomplish a specific task. They’re not sexy. They’re simple. They can be clever. They’re intuitive and easy to use. They’re little rays of sunshine through the haze of trying to figure out and build a product your clients will love.
Frameworks, on the other hand beget more frameworks. Someone builds something. Along the way they see a pattern and extract it. This is good software engineering practice. But it’s evidence that the problem wasn’t thought through completely.
Authentication and authorization frameworks are common. Template-based presentation frameworks are also common. Persistence frameworks are ubiquitous. The list goes on and on.
What makes frameworks so insidious is the fact that they’re symbiotic with specific applications. When you use frameworks to build an application you eventually find yourself at a point where the application can’t evolve because the frameworks have become too unwieldy and cumbersome to be useful. You end up chalking the whole thing up to a learning experience and begin the process of throwing code overboard in an effort to save the sinking application. More often than not it’s easier to just start from scratch.
This evolutionary process isn’t necessarily a bad thing. Where it really gets nasty though is after you’ve shipped the software and have to maintain your application through upgrades. If you were able to avoid starting over from scratch, the effort and complexity involved in keeping your application consistent while simultaneously refactoring the frameworks and trying to deliver new features and bug fixes will make you want to set your hair on fire.
Over time you will either realize that frameworks are not the answer, or your competitors will and build better software faster than you can fix yours. Eventually, the framework will die.
I've got a masters degree in computer science and over 10 years of experience building web-based systems using Java/J2EE, Ruby, Rails and PHP. I'm a strong believer in the effectiveness of Agile Methods. Read more »
Why Frameworks Die
There have been a number of discussions out there in the ether about frameworks vs. libraries, what they are, how they differ, which is better and why. Here’s my $0.02 on frameworks. I’ll do a compare and contrast piece in a follow-up post.
Frameworks evolve. They’re the by-product of refactoring. Libraries on the other hand are designed.
Libraries are tools which can be used over and over again to accomplish a specific task. They’re not sexy. They’re simple. They can be clever. They’re intuitive and easy to use. They’re little rays of sunshine through the haze of trying to figure out and build a product your clients will love.
Frameworks, on the other hand beget more frameworks. Someone builds something. Along the way they see a pattern and extract it. This is good software engineering practice. But it’s evidence that the problem wasn’t thought through completely.
Authentication and authorization frameworks are common. Template-based presentation frameworks are also common. Persistence frameworks are ubiquitous. The list goes on and on.
What makes frameworks so insidious is the fact that they’re symbiotic with specific applications. When you use frameworks to build an application you eventually find yourself at a point where the application can’t evolve because the frameworks have become too unwieldy and cumbersome to be useful. You end up chalking the whole thing up to a learning experience and begin the process of throwing code overboard in an effort to save the sinking application. More often than not it’s easier to just start from scratch.
This evolutionary process isn’t necessarily a bad thing. Where it really gets nasty though is after you’ve shipped the software and have to maintain your application through upgrades. If you were able to avoid starting over from scratch, the effort and complexity involved in keeping your application consistent while simultaneously refactoring the frameworks and trying to deliver new features and bug fixes will make you want to set your hair on fire.
Over time you will either realize that frameworks are not the answer, or your competitors will and build better software faster than you can fix yours. Eventually, the framework will die.