I'd like to coin a new word, genericization, mostly because it's fun to say, but it's hard not to go back and try and correct that red squiggly line. Anyway, I didn't really want to talk about new words and automatic spell-checking. What I really want to expound upon is all this talk about innovation and how it occurs in the software development space.

Where I'm currently working, they have some weird calculation involving revenue and GP to measure innovation. I'm not, to be sure, exactly up on all the conceptual math behind it.... At any rate, the prevailing concept amongst the operational and business folks is that innovation should be done on the client's dime. Furthermore, such innovation should always be genericizable, i.e., applicable across all clients. What, apparently, gets lost in translation, is that converting a concept into a software-based process, given a reasonable set of requirements and under an always aggressive timeline, is a shaky proposition anyway. To expect development teams, especially immature or relatively new and unschooled teams, to think generically when they're feverishly working to implement specifically is akin to trying to find something that resembles a pin to stick back into the grenade...

And, of course, when that grenade explodes, all the buts start:

  • "But why can't that whatchamacallit be used on my program?"
  • "But you made that generic, why do I have to pay for customization?"
  • "But I need it to work this way."

What I think most of the business folks aren't realizing is that they are the ones who own the domain. They own the concepts. Of course, translating the conceptual into the physical is one of the roles the architect plays. If you are the architect and you're heads down on specific delivery, i.e., client work,  you'll never have the chance to look around and truly learn the breadth and depth of a particular domain. Therefore, you'll rarely ever be able conceptualize it into something generic. And, you'll just be stuck re-inventing the wheel over and over.