Some thoughts from a LOB Dev on Frameworks and Samples...

BrustBlog - Can Frameworks and Samples Mash Up?

"In the development of line-of-business (LOB) applications, there has long been a certain tug-of-war between tools that automate development, or frameworks that accelerate it, on the one hand; and the notion of coding from scratch, perhaps with the aid of code libraries developed in-house (or by the sole developer), on the other.

This is typically put under the rubric of a zero-sum game before the debate even starts. Downstream project managers, analysts and users don’t want to pay the tax of having the same old LOB plumbing code reinvented repeatedly. Developers don’t want to use someone else’s code or be boxed in by the application paradigm on which a commercial framework may rest. Honestly, both sides have fair points to make here. And because only one-side can prevail, the other party typically ends up unhappy. Regardless of the winner, this is bad for the project because developer morale, user buy-in, and/or requirements analysis quality will almost certainly suffer.

At first blush, this seems intractable, especially since there’s legitimacy on both sides. The PM/analyst/user argument is pretty clear: re-inventing the wheel of data access, UI production, security and any number of other LOB infrastructure code areas is wasteful and error prone. From the developer point of view, though, things aren’t so simple. The glib reaction to the developer interest goes something like this “I pay you to write software that helps my business. I don’t pay you to engage in your ‘craft’.” And while there is validity to that position, I think it’s also a bit naïve.

...

Developers love to research techniques and learn from sample code. So maybe it’s best not to look upon frameworks as imposed mandates, but rather as well-engineered samples, with actual support, that come with a license for embedded redistribution in an application. Might this diffuse the tension between developers and stakeholders? The latter want things to be cost-efficient and well-engineered; the former want to learn, and verify underlying code instead of leaving it in a black box. Using frameworks as resources, and not as regulations, would seem to get us both, and it can help framework developers. They get to share their solutions with other developers, and have an app store-like revenue incentive to do so.

..."

Being a LOB Dev myself I thought this post interesting... Having had "frameworks" inflicted on my in the past (and which I've inflicted on others... :0 ) as well as provided "samples" and so this post made me think a bit... (ouch!)