|There's more than one way to do things|
Re: Management that just doesn't understandby footpad (Monsignor)
|on Oct 24, 2001 at 21:14 UTC||Need Help??|
Handle this very carefully.
It's likely that the person that tagged your code as "insecure" manages (or is) the developer that would have been assigned to the project--meaning you may have inadvertantly triggered a turf war.
How? In my experience, companies of the size you're talking about plan projects long before code gets written. They allocate resources, draw up specifications, etc. and so on. It's weird, but it's easier to get a $300,000 project approved than a $3,000 one--even when the latter project will save more money in the long run.
Furthermore, most dev. teams in such shops have huge backloads. It can take a year or more for "permission" to start coding. During this time, middle managers wanting more people, budget, training, power, or whatever are dueling with senior managers wanting the same and to hold down costs. This is especially true in large organizations where some fear the next re-org.
As a result, project estimates are frequently inflated, in terms of cost and development time. What seems like a simple 40-hour job may be estimated at taking six to nine months to complete. It sucks, but that's the way some companies work.
Now, imagine yourself in such a position. You're bidding this project at, say, six months of dedicated time by however many developers. And you're close to getting approval. It's taken three months of wrangling, but you're almost there.
Suddenly, this upstart no one's ever heard of (from Tech, of all places) comes along and shows a working version written in four days. At the very least, senior management is going to want to know why that was possible when your estimates were far longer. It's clear you need to discredit it and to do so in a way that will sound good to your budget minded, but non-technical superiors. So, you play the "security" card.
Now, I'm not saying that's what happened, but I have seen it done before. And, yes, I'm speaking from experience.
A number of years ago, I wrote a little program that would save countless hours and tens of thousands each year. I demoed it to the people that would be using it, generated some enthusiasm, made some fixes...and got abruptly shut down by a senior manager that was as technical as a fish in a locomotive.
Furthermore, I handled it badly. I blew up, made a lot of disparaging comments, and very carefully dissected the senior manager's skills and reputation. I felt smug in my moral and technical superiority. I also lost my job a few weeks later. It was called a "reduction in FTE's" in public, but my manager told me (off the record) that the manager I'd embarassed (his superior) had me fired.
Now, that was a long time ago and I spent a lot of time thinking about other ways I could have responded. My working theory is:
I really hated losing that job. While it wasn't the best one I ever had and I did end up with a better one (in Silicon Valley, no less), I always felt I'd been, um, had....and only because I was trying to do the best thing for the organization and because I'd been honest. Furthermore, I was right. Yet, I was the one that got fired.
I think diplomacy is your best weapon at this point. Be tactful and try to co-opt the person(s) who shot your code down. Make darned sure you give people graceful ways out of an untenable situation...even if that means taking a little heat or giving them credit for "saving" your code. Do you deserve it? No. However, having your code actually deployed should help make up for it in the long run. It's probably not going to be easy, but gentle persistence should help.
On the other hand, you may need to simply let it go. Above all, be discrete and respectful--especially when dealing with managers and senior personnel.
In closing, here's a relevant quote (blacked out because some may find it offensive):