Alpha-Geek gave us a reading assignment last week, namely a SimpleTalk article called The Framework Myth. And, of course, be ready to discuss during the weekly dev. meeting. (For the tl;dr crowd, the gist of the article is that writing code for multiple purposes is overrated; you're better off staying out of the way of people who will tighten up code organically rather than imposing it from the top.)
During said discussion, Beta-Geek opined that the piece was "schizophrenic" and (not surprisingly) came out in defense of writing code in such a way that it's easier to snap existing pieces together than letting everyone roll their own. Personally, I completely missed any "schizophrenic" aspect: I thought it was just trying to cover a reasonable representation of the major points. Which, in the software world, is the proverbial breath of fresh air, given how many manufacturing/engineering philosophies are over-enthusiastically misapplied. (And, by "misapplied" I of course mean "shoved down everyone's throat with the business end of a bayonet.")
To illustrate: The same dorm-room-hacking that made Mark Zuckerberg a bazillionaire should probably not be used for software that controls nuclear reactors or the space shuttle or guide military equipment. And vice-versa.
So. Yeah. Context. It actually matters. (Who knew?) Sadly, when management gets a methodology "religion," they're far more likely to be mixing Kool-Aid in the Jones compound than, say, brewing coffee in the Unitarian fellowship room.
And that's a whole 'nuther blog-post.
But what I think is missing from the commentary was the human--i.e. personnel--cost of implementing frameworks. In my world-view, the "cost" of an over-rigid framework is not so much its overhead--meaning all the bells and whistles you don't use, but have to waste memory space on anyway. It's not even so much the rigidity of them--meaning the programming equivalent of a Happy Meal vs. going a la carte. Or even what a tedious pain in the wazoo it is to try and make a change under the hood. Particularly when the original authors consider themselves illuminati--as evidenced by lack of documentation.
Actually, maybe I should qualify that criticism of pre-fabricated "framework" code. If you want to hire people willing to snap together other people's code for a living, you can stop reading now with my appreciation for your time...and fervent hopes that you will keep those people from potentially becoming my co-workers. (Or--shudder--promoted to their proverbial level of incompetence into management.)
But that tab-A-into-slot-B Ikea mentality brings us right back around to the afore-mentioned mis-application of an industrial/manufacturing model. In that mind-set, a few bright lights (e.g. Henry Ford, Taiichi Ohno) set up the machinery to feed piece-work to droves of interchangeable automatons. Efficiency and profit ensues. (I'm doing a disservice to both gentlemen by oversimplification, btw, but you get the point, yes?)
Problem is, software is the business of solving problems, sometimes before people know they have them. But the problems change continually. Granted, history is sometimes circular. Not every problem, for instance, is solved optimally the first or second iteration through. Sometimes solutions create their own problems. The point is, that if you find yourself implementing the same solution or small set of solutions, chances are you're solving the wrong problem. Which is precisely when and why you need the sort of person who recognizes that...and can push solutions upstream. As often and as forcefully as needed. That's pretty much antithetical to the top-down ethos of manufacturing.
And, for that matter, frameworks.
In my considerably less than humble opinion, comissioning the programming Brahmins to write lego-code for the Untouchables to snap together is no less than a blatant admission of failure in software management. Possibly any number of failures. Failures of not cross-train people (or cross-pollinate functions) so the same problems aren't invariably solved redundantly. Of not smoothing out inter-team frictions (i.e. the "Not Invented Here" syndrome). Of not making it stupid-simple to sift and search existing code libraries for plagiarization--errr, I mean, code re-use. Or--most especially--of leaving no time to poke, prod and tinker.
Don't get me wrong here: I like playing with Legos, especially the very, very basic ones. Dennis gave me Lego knights and horses one Christmas, but I tend to gravitate back to the plainer blocks. More possibilities, I think. Just like writing software.
