Thursday, September 8, 2011

Application developers should not write frameworks and toolkits (much)

On occasion I'm a little disappointed when I see developers create frameworks and toolkits. I understand that it is enjoyable to do so, but we, as application developers, should be majorly focused on the business needs of developing applications.

Quite often we think that xyz widget doesn't do exactly what is "required" and therefore pursue a path of days (weeks) writing frameworks and toolkits.

Let's not do this anymore.

Instead, every time you, as a developer, get the urge to write a framework or toolkit or even just a utility class, think about extending an existing open source project to meet your needs; or even starting a new open source project. For one thing, your requirements will most likely be challenged (which is a good thing). You will no doubt end up with something better than you could have created yourself (yes, that's hard to swallow, I know!). Importantly though, your organisation will benefit; the less "quirks" particular to an organisation the faster it is for them to ramp up resources and "Get Things Done".

Your organisation will also be able to share stuff between the silos. Imagine that.

I often hear, "but my organisation doesn't contribute to open source" (despite heavily using it). In this instance I always ask if the person in question has actually tried selling the business benefit (above) and attempted to make it happen. More often than not, the developer hasn't tried. Organisational behaviour is driven by the views of their employees and contractors. Organisations change and are changing.

I do believe that at the end of the day, it is better to suffer with an xyz widget that does most of what you need it to do than to re-invent the wheel. If you're an application developer then focus on the application, not frameworks and toolkits; unless you're contributing to open source projects.


John O'Malley said...

I will certainly concede that that developers often don't look hard enough for open source solutions. I've been guilty of this a few times.

But I think ultimately you have to deliver a good product; that concern overrides just about any other. Sharing code at the organizational level is certainly preferable to keeping every application within the organization in its own silo. I will agree that large frameworks generally aren't a good idea to implement at the organizational level but I could give you at least one exception.

When an open source project doesn't solve the problem correctly out of the box (as it usually doesn't) my first priority is to make it work correctly in the product I'm delivering to the customer. In a perfect world, perhaps, I would be able to concentrate on enhancing the public project but we typically don't have the time (nor the support from management) to do that.

Application development is a never-ending struggle against entropy. Every project, no matter the quality of the development team, is going to end up with some ugliness as it gets larger. Our job is to fight that as best as we can. Anything that make the code smaller or easier to maintain is probably worth the effort, even if it violates the principle you advocate here.

So while I don't disagree with the sentiment behind your post I maintain that when it conflicts with the larger concern of delivering the best product, I will violate it without remorse.

Christopher said...

Thanks for the great comment. An over-arching concern I have is that we all-too-often bow to the business in relation to determining what a legitimate business requirement is. When a business states that xyz widget must do abc, and then we go and create a project to manage that requirement, then I think there's a problem. We have to stand up to the business more; it is in their interest for us to do so.

I'm entirely focused on delivering the best product in the least amount of time.

Samual James said...

The matter of moment is to deliver a quality product, and hence you have to keep certain points in brain. you can not opt any of the technique if you really want to deliver a quality Service Business Software and hence quality with quantity is a must.

MobileFun said...

nice blog very intrusting information

To download more latest application visit

pixelsmedia said...

Excellent content! keep on posting this kind of useful articles. Thanks for sharing such an informative post.
Web Development