Rashid: If you’re using a personal framework or library, then yes, you’ve probably built it once, hopefully optimized it, and it works pretty well. I guess my issue is with developers using frameworks without thinking about whether it’s the best option.

Rashid: If you’re using a personal framework or library, then yes, you’ve probably built it once, hopefully optimized it, and it works pretty well. I guess my issue is with developers using frameworks without thinking about whether it’s the best option.

I’m of the thinking that the logical progression of development in any shop that maintains more than one application is to build or implement a framework. It only makes sense, one of the biggest axioms of software engineering is to “do it once” and that’s pretty much the purpose of a framework.

How the framework is implemented goes a long way to deal with the answers to your questions on dev time vs. speed (and I would add flexibility). I’ve found that you don’t necessarily have to compromise if your framework is driven by process instead of excessive abstraction – some people just want to configure applications into existence instead of writing them, and if that’s the case they need to change professions.

I use my framework to handle the central plumbing of my applications. If I’m writing multiple applications for my organization, it makes no sense to reimplement the logging, data access, authentication and authorization for each one. The framework allows me to concentrate on the things that make the application unique and not worry about the drudge work over and over. Most importantly, having that core logic implemented once means that you only have to modify it in one place when it needs to be fixed.

I’m of the thinking that the logical progression of development in any shop that maintains more than one application is to build or implement a framework. It only makes sense, one of the biggest axioms of software engineering is to “do it once” and that’s pretty much the purpose of a framework.

How the framework is implemented goes a long way to deal with the answers to your questions on dev time vs. speed (and I would add flexibility). I’ve found that you don’t necessarily have to compromise if your framework is driven by process instead of excessive abstraction – some people just want to configure applications into existence instead of writing them, and if that’s the case they need to change professions.

I use my framework to handle the central plumbing of my applications. If I’m writing multiple applications for my organization, it makes no sense to reimplement the logging, data access, authentication and authorization for each one. The framework allows me to concentrate on the things that make the application unique and not worry about the drudge work over and over. Most importantly, having that core logic implemented once means that you only have to modify it in one place when it needs to be fixed.

That’s not to say we wouldn’t accept it if it could but I think most developers do go the framework route because they don’t really have the time to build exactly what they need for the job and frameworks make it easier to get something that will work quickly.

That’s not to say we wouldn’t accept it if it could but I think most developers do go the framework route because they don’t really have the time to build exactly what they need for the job and frameworks make it easier to get something that will work quickly.