Recently I've been exposed to the process of the aquisition of a large suite of software for the development of a large system. Needless to say the company is a large vendor, the client is a large organisation and the volumes of money involved were, well, volumous.
As usual the decision makers of the large organisation were bombared by a dizzying array of buzzwords designed to exploit the lack of technical knowledge of said decision makers by the vendors.
I thought it's time we start creating a set of buzzwords which are a closer reflection on reality.
These buzzwords are designed to express your feelings in front of managers in a non career limiting manner
Here are a couple that come to mind...
VDD - Vendor driven development: this is when a vendor sells you a set of tools which force you to adapt your working processes to be able to use their technology, since the software is normally too bad to use any other way and you paid a fortune for it, so you have to use it.
COA - Consultant orientated architecture (pronounced "kowa"): this is when you have to buy additional services via expensive consultants in order to make the software you bought for your VDD work.
SaaPG - Software as a Porsche Generator: What software means to the sales people selling you tools.
B-CIEPS - Bean Counter Ignorance Exploitation Procurement strategy (pronounced "beeseeps") : this is the strategy sales people use to enable SaaPG. This strategy works well with large companies.
ROP - Resume orientated programming: 'Nuff said really, just a reminder that we developers aren't exactly blameless either.
BCVLI - Buzzword compliant vendor lock in: This is when a vendor sells you "compliancy" with standards even though the standard is bent or broken or the standardisation process is so bad that only their tools work with the "compliant" product. Anyone who has ever worked with web services can atest to this.
The "Gates-Palminsano-Ellison process": The process whereby you make Bill Gates, Sam Palmisano and Larry Ellison richer men by buying their products, this is actually more an indictment on the company buying the software rather then the vendors, Many decision makers often lean towards large vendors and neglect smaller but equally capable companies because their butts are one the line.
6-zero compliancy: This is the rule that states that in order for a product to be perceived to be useful it's price must have at least 6 zeroes behind the most significant digit, hence; 6-zero compliancy.
UFL - Usefulness follows licensing: This is a rule normally applicable in VDDs, whereby only the basic functionality you could have got downloading an open source product is available and the additional features you actually bought the product for are only available after you purchase additional licenses.
So when you start having project issues because of the load of junk the CIO bought, and your manager asks you why, you can safely look him in the eye and tell him straight: "Well you see this product is very strictly VDD so we have to change the way we work and that takes time, The other product didn't have this problem but it wasn't 6-zero compliant and the "Gates-Palmnisano-Ellison process" eliminated which normally happens when B-CIEPS is employed. It should get better when we start applying UFL, the developers are also quite stoked to start doing ROP.
This list is only the tip of the iceberg, so if you have more let me know, a follow up post should be fun.
No comments:
Post a Comment