|
Let me get this straight. You want a Scripting Framework? |
If you ever watch “Pimp My Ride” you can relate to this statement: "We heard you liked frameworks so we put a scripting framework on top of your application server so you can write code while you write code." During every episode of “Pimp My Ride”, Xzibit will install something into the now pimped ride that is relevant to something the owner enjoys doing. The one episode I saw had him installing turntables and a mixer in a hatchback because the car owner was an aspiring DJ. It made me think about those of you that want a scripting framework. It seems just as ridiculous.
In my last blog posting, I said that scripting was bad and you should just stop. The most common reasons why most Java EE admin’s still script include job security, hacking scripts for hacking’s sake, and inability to affect change in your organization.
Frankly, these are absolutely horrible reasons to script. But, I’ve seen something worse than scripting: script frameworks.
First, I want to point out how absolutely ridiculous it is to purchase or build a scripting framework in the first place. First, the entire reason you are using a Java Application Server is because it cuts down on the code you have to write. For example, back in the day, you had to create your own security, persistence, messaging, you-name-it framework. With Java EE, you don’t need to do that. It’s built into the API and Application Server for you. But, because of the configuration headaches, you are simply reintroducing any costs that were saved by writing less code. Shame on you for trading one head ache for another.
Second, the idea of writing code that does not generate revenue or cut costs, is just bad business. Think of it like this: why do construction companies rent scaffolding and not just buy it? Because it’s not their core competency. Managing, constructing and breaking down scaffolding will never make money for a construction company. But, it’s necessary for other revenue generating tasks, like brick laying or façade work. So, there is no reason to have scaffolding techs on duty when an outside company can provide better resources than the construction company can. So, construction companies use outside scaffolding company to not only deliver the scaffolding to the job site, but they also provide support for maintenance, reconfiguration or final pickup.
Look, times are rough. The tech industry is getting hit hard by layoffs. However, if you think that you will be the last one laid-off because of your position as the Script Guru, you are mistaken. I would argue that you might be the first; here’s why. Companies that are exposed to Phurnace for the first time, immediately start doing calculations on how they become more effective and efficient with Phurnace. Typically, that will mean utilizing the existing resources to perform more tasks with less resources. We see new customers begin tasking their resources with larger levels of responsibility. This could include the updated disaster recovery plan that has been languishing, or the upgrade to WAS 7 everyone wants because WAS 5.1 support is now costing so much more than in the past. But, if you have been simply the “Script Monkey” for the past several years, your kung-fu is rusty.
If you really want to stand out, offer your manager an alternative to scripting. Provide an ROI model that shows how adopting Phurnace Deliver can save your company hundreds of thousands a dollars yearly. Show how the time to value is in days, not months.
Of course, that does sound like more work. But, don’t worry; we have account managers that can do that for you. Heck, you can even say it was you that put it together. We promise not to tell.
So, save your company money and save yourself some headaches. Don’t buy into a scripting framework.
 |
Subscribe to this comment's feed
Giving up scripting means giving up "infinite" flexibility and customization for a standard and supported way of doing things. Nearly all businesses choose to give up that flexibility for standard procedures, with higher transparency and with lower maintenance - even if it means trading some capabilities for perhaps many others that the product offers or will eventually offer.
While it's possible with our product to have a script-free build system, the reality is that we only drastically reduce the number of scripts (>95%). Not to totally deny the script writer his/her creative outlet, we find there will still be a need to fill integration gaps, perform valuable customization, get reports and meet the whims of certain high-level managers. In addition, the former script master, now perhaps script tinkerer, obtains a much more elevated position through the benefits of managing the tool. In our case, the build meister becomes responsible for a 10-fold increase in builds and becomes a component architect managing standard libraries, their changes and upgrades for the entire organization.
So, I'll bet it's similar with your situation. You can tell the script lover that there will still be a few scripts to write and your job will be much more visible and important managing the product.