Cost of framework is not an issue these days, since most popular frameworks are open source and free, but hidden costs are a different matter that deserve careful consideration. An approach that favors traditional solutions, or trendy ones, may end with a very labor-intensive production system, which is costly.
Many people that use the highly popular J2EE frameworks are writing unnecessary code, because these frameworks mandate so, and this code will require maintenance, and that represents costs too. Also adds to the hidden costs the fact that the programmer is writing code that could have been avoided with a different approach.
Beyond the [hidden] cost factor, I would also note these ones:
* Stability, performance.
* Easy of use, which affects productivity. A QuickStart path is also highly desirable, it leads to rapid achievement, which facilitates framework adoption. People like to achieve results quickly, framework and library developers use to forget that fact too often.
* Good and abundant documentation. This is crucial to sustain adoption by new comers with minimal costs. How fast can you put a new programmer into the production line, with the expected quality? that affects productivity, and keeps away or closer to the diminishing returns area.
* Availability of high quality sample code. You need templates to start producing quickly
* A commercial-friendly license, like LGPL.
* Beware of framework dependencies on 3rd party components with unfriendly licences.
Best regards,
Martin Cordova
www.martincordova.com
Slashdot Mirror
Cost of framework is not an issue these days, since most popular frameworks are open source and free, but hidden costs are a different matter that deserve careful consideration. An approach that favors traditional solutions, or trendy ones, may end with a very labor-intensive production system, which is costly. Many people that use the highly popular J2EE frameworks are writing unnecessary code, because these frameworks mandate so, and this code will require maintenance, and that represents costs too. Also adds to the hidden costs the fact that the programmer is writing code that could have been avoided with a different approach. Beyond the [hidden] cost factor, I would also note these ones: * Stability, performance. * Easy of use, which affects productivity. A QuickStart path is also highly desirable, it leads to rapid achievement, which facilitates framework adoption. People like to achieve results quickly, framework and library developers use to forget that fact too often. * Good and abundant documentation. This is crucial to sustain adoption by new comers with minimal costs. How fast can you put a new programmer into the production line, with the expected quality? that affects productivity, and keeps away or closer to the diminishing returns area. * Availability of high quality sample code. You need templates to start producing quickly * A commercial-friendly license, like LGPL. * Beware of framework dependencies on 3rd party components with unfriendly licences. Best regards, Martin Cordova www.martincordova.com