The Hand-Coding Vs. Automation Tug-of-War

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.

Many developers got into the profession because getting paid to do what is or was a hobby, a passion, or both, is like a dream come true.  Yes, getting paid for it adds stress that doesn't exist on the hobby side.  And yes, it adds politics and inefficiencies as well.  That's why they call it work, and that's a fair compromise to do what you love.  But the love is important, and most developers find it somewhere between tedious and unacceptable for their core work to be based on outdated technology, use ill-conceived architectures, or worst of all, be boring and clerical.  Most developers know that the right work situation will be fulfilling.  At the same time, smart developers know that the wrong situation is often close at hand –- and one out-of-their-control decision away.  And, like it or not, developers see frameworks and code generators as harbingers of those bad decisions.

But the question of "to tool or not to tool" may have a false premise; maybe there's a middle ground.  Some frameworks are published in source code form.  I recently reviewed one such product, called B1Framework. I didn't love everything about it, but I did like the well-structured source code, and I especially liked the multithreaded, non-blocking code used for all data access operations against any of the big three relational database products.  I happen to know this code was borne of projects at very demanding financial services clients here in New York.  And the idea that my consulting firm clients could appropriate the techniques in the code, or use the code outright, at projects for similar clients, without having to buy into the entire framework, seems pretty compelling.

I used to think the benefit of frameworks with source code was the deterrent against bad code that shared source can provide, and the ability for developers to tweak what the framework does.  But during my review, I realized the bigger benefit is the ability to learn exactly how the framework does something, to become a better coder for it and, yes, to develop an app more quickly and with fewer bugs by using that knowledge.  And developers aren't limited to mere adoption of the code; they can outright steal code that looks solid.  In fact, this isn't stealing at all, since the whole benefit of a framework is that you license it so you can use its code.

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.

Maybe I'm the one being naïve, and I'm eager to hear your comments on the matter.  But sometimes the key to solving problems is outlook, rather than conquest.

Posted by Andrew J. Brust on 02/23/2012