Slashdot Mirror
When Should We Ditch Our Platform?
odoketa writes "My organization recently had to replace our Web developer. It took us an extremely long time to find someone with the necessary skill set. I don't know if this is because of the platform we are running (which I will leave nameless), or simply because the fates conspiring against us. It's easy to assume that languages or platforms are popular based on buzz, but the rubber hits the road when you have to hire someone to maintain that code. How are folks out there determining when you've backed the wrong horse, and getting back on track?"
I've found that the more a manufacturer hypes a product the more likely it is to be a flash in the pan; If your lucky the previous programmer made a well designed application that will be easy to translate into other platforms or languages. Still sooner or later everything goes the way of the dodoe, I learned COBOL once apon a time.
Apocalypse Cancelled, Sorry, No Ticket Refunds
Why can't we know it anyway? That's just stupid, like for security reasons or something we can't know? Nobody answer this joker.
You didn't say where your organization is, but have you factored your location into the equation? Maybe in another area, you could find web developers with the correct skill set. Of course on the other hand, you could be using something outdated.
Last time my company hired a new programmer, we had trouble. However it had more to do with the local job market, a general lack of IT talent in the area and other human factors (pay, benefits, etc...).
You know when you are asking about an older technology when most of the younger applicants give you a blank stare and the older ones sit there for a minute thinking about the last time they used it.
Maybe he wants an objective response?
If you know what platform he's talking about, opinions would be skewed based on what people think of that platform. It would be a distraction.
Not knowing the specifics makes it easier to provide the general answers he's looking for.
Do not confuse "Freedom of Choice" with "Free Will".
Everybody always says about the various platform/language wars, use what you can to get the job done. Since you said "web developer" and not "web developers", I assume the project isn't that large, or at least isn't large enough where you can't afford to do a bit of a re-write. The thing that is more important to me than language and platform, is design. If you have a good design, then refactoring your code_base into a different platform, shouldn't be all that impossible. (Remember, I'm assuming your application/site isn't really really big) And if you don't have a good design, then you need to redesign anyways. Just my two cents though.
You'll have that sometimes...
Yes, this does, in fact, mean that if one of our application servers dies and has to be re-baselined for any reason, our entire application[1] is down for over a month and will cost us several thousand dollars in re-installation fees alone.
[1]The entire application is a system of interlinked application servers, each of which has a different role in the system and each of which represents a single point of failure.
I know what you're thinking: You're thinking we should have ditched the development platform before we ever even implemented it.
But you're wrong. We should have ditched the developer platform the moment they came up with this hare-brained scheme.
Any sufficiently well-organized community is indistinguishable from Government.
This is probably not a great idea. Instead, consider broadening your hiring criteria, and hiring people who don't have experience with that particular platform, but know the application domain well. For example, if you're a PHP shop and you need someone to maintain PHPNuke, but can't find anyone, consider bringing in someone who knows Slash or some other Web logging software and has a grasp of the technology.
Make one of the new guy's first tasks the evaluation of competing products and the overhead involved in moving to them, not with an eye to switching, but just to get a lay of the land and further expose him to a breadth of approaches. Periodically, send him off to appropriate conferences too.
All together, you'll end up with a well-rounded employee who can speak to the costs and benefits of your platform.
Or not- many older platforms are just worth ditching in favor of easier or more efficient platforms. Yeah he'll get objective answers, but they won't be valuable.
Jokes about Fortran might be funny, but without knowing what your platform is, we can only answer in very vague ways. If you can't find anybody to work on this platform, and can't train anybody, then you need to replace the platform now and you have no choice. But this probably isn't really true -- what's more likely is that people who know this platform are hard to find or want to be well paid and it becomes a tradeoff. How much is invested in the platform? How much work to move to something else? And what to move to? We need more details
The platform is irrelevant. Maybe you could list a dozen problems with it off of the top of your head, but THAT'S NOT WHAT HE'S ASKING.
He wants to know, generically, how you decide that what you're using is the wrong choice.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
If sensible individuals in the organization are starting to question whether or not the platform needs to be replaced, then it probably does. Because usually those discussions don't come about unless you've hit a wall of some sort: performance, unavailability of employees with those skills, incompatability, unsupportability, deprecation, et cetera.
When you start to experience those things in your platform, its usually time to start an exit strategy.
You could be talking about anything from RealBasic to perl. Without knowing, we can't even speculate on whether you can't find someone because demand is so high that they've all been snapped up, or because the product is dead.
In general, I tend to look for a healthy third-party community. If there are multiple third-party sites, well run, with competent spelling and grammar, and no legal affiliation with the primary vendor, that's a good sign.
Examples: Ruby, python, perl, C.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
But here are a few tips anyway, perhaps they can make your decision easier:
So, in a nutshell, I recommend Perl, Postgresql and FreeBSD. Plenty of experienced developers, and the tools Just Work.
Platform choice should come down to three things, IMHO:
Having said those points, DO NOT switch platforms just to make your developer happy. If you have a staff of architects and developers and they all agree that some new platform is better in the short- and long-run, then go ahead and switch. But if this is just the whim of 2-3 guys, tell them NO.
One last point: if/when you do switch, make sure the clock drives the functionality, not the other way around. If you let functionality drive the clock, you'll be 4 years and several million dollars into a nightmare. Set a deadline (a REAL deadline) of 6 months and take what you get at the end of that 6 months. your developer crew (internal or external) will be augmenting and building out on that platform no matter what, so you're far better off having something cuick and crude rather than late and fancy. I cannot emphasize this point enough.
davejenkins.com |
It matters, because it relates to why you might be unable to find any people for it. It might be a really obscure one that requires deep knowledge. Any programmer worth his salt should be able to switch between PHP/ASP/Perl/Ruby and the likes with relative ease. Did you look for a programmer worth his salt or did you search for someone with 10 years experience with Vista? The more obscure and closed the platform, the less likely you are to find someone with specific knowledge and them more you will just have to hire someone who can train himself on the job.
The easiest way to determining if your platform has support is to look through personal ads, is nobody else hiring people with those skills, then you got to wonder why. Browse for tutorials, see the forums for that platform for activity.
The way to avoid this in the future is to remain low-tech. Don't tie yourself to deeply into solutions crafted onto solutions. For instance use PHP, not bloody frameworks build on that. If you then use a software suit, build on a framework, build on a language, build on a platform, well you are going to have problems finding someone with those exact skills.
Oh and replace PHP with whatever language you prefer.
I see this all the time, some company buys a solution, does some half assed training, do half of the updates that are available and then a couple of years later when the site is hopelessly out of date wonders why they can't find anyone who responds for their personal ads.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Ok, let me see if I follow your logic here. We're supposed to provide feedback on whether he should ditch his platform or not, but we can't know what the platform is because it might effect our opinion of whether he should ditch it or not. Riiiight. Hey, you think I should be using a different brand of shoe, but I can't tell you which brand I'm currently using because it might effect your opinion of whether I should switch or not.
News flash, when asking for an opinion about something, you have to tell people what that something is so that they know which opinion they're supposed to be giving you. I suppose I could just run down the list and toss out an opinion of every platform that's ever existed and you could make your decision based on that, but that really wastes rather a lot of time don't you think.
Curiosity was framed, Ignorance killed the cat.
... exceeds the cost of replacing it.
P.S.
I don't buy this "we couldn't find anyone" BS. Were you, by chance, using a 2 year old technology, and your HR drones were looking for someone who "must have 5 years experience" with it. Were you looking for a laundry list of tools, apps, and domain knowledge that, realistically, no-one except the previous employee had? You could, you know, find someone with a modicum of intelligence and [*gasp*] train them. Did you insist on someone with a degree to do little more than cut and paste text files? Were you paying at the market rate? I suspect that the problem was more with your hiring process than with your technology. If it was purely a technology problem, then the answer would be obvious and you wouldn't be asking us.
There is no single general answer, but:
If the system is already fully developed and no major changes are expected, that's a plus for sticking to their guns.
If they can find an already-good web developer who's willing to pick up a new platform (and they're in no rush to change it much), that's another plus for sticking with it.
If the system itself is older, then a rewrite becomes more reasonable even if it works great.
Is the website largely static? Platform barely matters then.
Is the site Java based? Dump that trash, because only bitches use Java.
That is some of my totally unbiased generic input.
Maybe it would be a good idea if a list of current "optimal" systems were given out. On second thought, though, maybe it would be better if the actual platform were named, as any ProductX blasting would still contain a few useful threads.
Do not confuse "Freedom of Choice" with "Free Will".
So .. you can't find someone with the right 'skill set'.
... go find some smart people and let them loose. They'll take care of it.
Maybe what you really need are smarter programmers. Anyone who has talent can pick up new languages, especially when they need to maintain an existing system and not create a new one from scratch. Ignoring C++ developers simply because one has a Java web platform (or WebSphere because one has a JBOSS environment) is just plain ignorant. All languages share common elements, and good developers use those elements to pick up the nuances of syntax. All application servers share common elements, and good application support staff can learn new ones.
Every time I hear a developer or app support person say 'I don't know that', I just want to reach across the room and ask them how stupid they are. The smart ones get online, research, and learn it very quickly, the non-as-smart ones use their ignorance to stay in their comfort zone. I'd rather find the smart ones, because in 6 months there are going to be more changes in the computer industry and I would want staff that can adapt.
So
Then, once you get those smart people that have experience in other areas, work with them to determine what platform to go to, or if you even need to.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Curiosity was framed, Ignorance killed the cat.
This is why you write an abstraction layer to sit between your business logic and the platform. Lets take databases as an example. Suppose your application is initially written for MySQL. Now, lets say that your application becomes a big hit, and you want to move it to a more robust backend. If you're application is tied directly to the platform (i.e. you've peppered your code with direct MySQL calls), you've got a lot of work in development and testing to make sure that all of the MySQL stuff is replaced with Oracle equivalents. However, if you've got an abstraction layer, the only things you have to rewrite and retest are the components of the abstraction layer. Its not zero work with the latter strategy, but it is a lot less work.
This is actually one of the gripes I have against web programming as it stands today. It seems to me that programmers are far too eager to call the database directly from their application, without using any sort of abstraction layer. Sure, its faster to create the application without an abstraction layer, but it makes porting the app to another backend an absolute nightmare.
Some lock you in more than others, but I think it would be quite difficult to switch between them, if you had a reasonable amount of code.If you have a good abstraction layer, even the most proprietary platform won't lock you in.
We all know what to do, but we don't know how to get re-elected once we have done it
No he it NOT asking whether he should drop his platform. He is asking the more general question, how do you know when ANY platform has reached it 'drop' time'. You want to feed him a fish, he is asking to be taught to fish, big difference.
I don't need to know your platform to help you qualify that answer. This is easy.
1) When you look the technology up on monster.com, how many results do you get?
2) Does the technology have an active community? How supported is it?
3) How big is your site?
4) How much are you willing to spend for someone to maintain it, convert it, implement it etc?
5) What is your time span?
I've done a hell of a lot of conversion from PHP and ASP to ColdFusion simply because companies want a language that's easy for other developers to come behind and figure what's going on. Like ALL code... even ColdFusion can be made to look ugly by a bad developer.
The most important thing is what many echoed already. Pick a language that has years of support behind it with an active community. You'll find your developers easily then. It also prevents the entrenchment technique used by bad developers.
The answer's easy: ditch the platform when the costs of maintaining it become greater than the cost of switching. That answer's so easy, in fact, that it's pointless to ask slashdot about it, bring it up in conversation, or even think about it for more than 2 minutes.
.NET, in which case the necessary skillset is having your head up your ass ;) But seriously, if he's having problems finding people of the right skillset on .NET, he needs to increase pay or switch to a platform where the pay's not as high as it is.
If you want something that actually requires an answer, you need to give more details. What's making him think of switching platforms? What's costing so much in maintenance or in finding people that it's just not worth it? Are these difficulties in his head, or is he actually having problems?
My guess is that he's talking about ruby on rails, because it's got a lot of hype and it's short on people with the necessary skill set. My answer in that instance would be, don't go with a young platform in the first place. Don't buy into hype until it's so mature that it doesn't have any hype, just a good solid list of pros and cons.
But maybe he's using
Perhaps he's using LAMP on either perl or php. If it's perl, he should shift to php as soon as possible, because perl code becomes very hard to maintain the longer it goes and developers are fewer and higher paid. He might have a problem with php because the developers lack the professional focus, in which case he should tighten his hiring practices.
Those are just some of the possible scenarios, and each of them requires a different response. The variables going into platform decisions are so complex that asking for an analysis without giving details requires a response that would be well over a hundred pages. He deserves credit for coming to the proper forum for his question (instead of asking a legal question, like "when is it legal for me to take my children without my ex-wife knowing?"), but that doesn't change the fact that any discussion which arises will be based on things that almost certainly don't answer his question.
Don't you really mean it took a long time to find someone ..... who was willing to work for you?
Without wishing to start an argument, web developers aren't exactly the rarest species of techy. Unless you have something truly bizarre, a remote location, or are paying peanuts, it shouldn't need much more than a "webmaster wanted" ad. to have them queuing round the block.
Did you interview lots,, and not choose any - or was it simply that no-one wanted to take the job?
(silly thought - did you consider recruiting someone without the skills, then training them?)
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
He said all the right words to point to Ruby or ROR as the platform they chose:
.NET/LAMP/Perl/Python in terms of available production man power.
- The illusion of popularity based upon buzz
- Lack of employable gurus who are familiar with production level platform development.
Most of the folks who have the latter work for a firm or work as "consultants". There are few folks with enterprise or production experience with ruby systems to actually employ to develop and maintain an entire codebase, especially one expected to be a jack-of-all-trades, as their 'single web developer' issue probably requires him to be.
I'm not saying that Ruby isn't a great development platform. I'm just pointing out that it's adoption and dissemination have not allowed it to reach the stage of
--- I'm going sane in a crazy world.
Hey, this is funny! Don't you get the joke? Ruts=punch cards.
Nothing interesting to say...MUST...NOT...REPLY...ohtheheckwithit.
You probably are not the person to make this decision.
Whenever management decides on software it is by reading one-sided literature distributed by the software vendors. Never a true story. Then it is cost driven. Never mind that the platform cannot possibly solve the business problem.
Tell the developer(s) your problem. They know what the application needs to do and which different solutions can get them there. If you hire good programmers, they will make good decisions, that is OUR expertise.
When management or marketing (or worst of all -- sales) get to contribute to decisions for software platforms for development, something is REALLY WRONG.
I tend to "Pink Floyd" in situations like this.
i.e. "Run Like Hell"
- I live the greatest adventure anyone could possibly desire. - Tosk the Hunted
As the Senior Web Developer, I've been tasked with interviewing and hiring my team.
It's been extremely difficult finding candidates because for website design and development, there is an extremely high ratio of signal to noise in quality candidates.
I've only been able to find 3 people worth interviewing after posting a junior position on several job boards and with several staffing agencies. And we're using an extremely common platform and set of services.
Anyone who's fired up design mode in Dreamweaver thinks they're a qualified developer. And anyone who's created something in Flash thinks they're a qualified designer.
And the talented people who are easy to find, are frequently only interested in freelance work because they want the flexibility.
As for actually switching your development stack, it's doable. Don't try to switch existing clients and projects, instead setup your new stack and only put new projects on it. There will be a learning curve, but if the end results show a significant improvement, it will be well worth it. Don't try to force in-progress projects, or old projects onto the new stack. Once you've done some work with the new stack, how feasible migrations are will become better apparent.
I've used this method for switching web development stacks several times. From plain old HTML, to ASP/IIS, to PHP/Apache, to Object-oriented PHP, and finally to an OSS CMS that we like. Old sites are only migrated to a new stack if we are redoing the design or functionality as a new project. Otherwise we just deal with the old and focus on making the new the best we can.
I'm out of my mind right now, but feel free to leave a message.....
PHP + Zend Framework - seriously
Bradley Holt
I agree that your statement is 100% correct... but it's also not as easy as you make it out to be.
Indeed, you should switch when the cost of switching is less than the cost of continuing with your current platform... but realizing that is obviously not the tricky part.
The tricky part is knowing WHEN switching costs less than continuing with the current platform. That can be a very difficult question to answer, and involves looking at many, many factors.
-Vendal Thornheart
I think that's the point. He doesn't want us to assess the situation for him, he wants us to identify what the factors are that he should take into account to do the assessment himself.
If he leaves the assessment to the SlashHorde, the factors that will be used will include religious bias. He's trying to eliminate that.
"You cannot simultaneously prevent and prepare for war." -- Albert Einstein
ASP.NET with C# as the back-end language.
"I stuck with JDK 1.1 until last year just to keep away from J2EE."
ROFL. That's like saying I stuck with Windows 95 because I wanted to stay away from XP.
Even 1.4 JVM is considered dated by todays standards and still way better then 1.1.
You should drop it when there's another platform that's so much better than yours as to justify the effort of moving away (ie not just slightly better unless your code base is tiny). Normally any decent developer won't have a tough time adjusting to any decent platform, so the reason to switch isn't really that developers are hard to find who can work on your platform (unless it's something really unsuited to the job), it's that developers are hard to find who _want_ to work on your platform.
If you're running on platform X and you keep advertising for developers with 3 years of platform X experience or turning away really skilled people who have been working on some other, similar platform, the problem is your hiring. If you're advertising for good developers in your application domain and they're not accepting offers, then the platform may be at least a marketing problem (which can be a serious problem indeed).
But if, say, you're using Ruby heavily, there's no significant reason not to hire experienced Python or Perl developers (or vice-versa); if they're any good, they'll pick it up very quickly. There are limits; obviously if you're doing C development on an MMU-less embedded system, you don't want a great Visual Basic developer who's never worked with explicit memory management before. But if the developer is skilled in the application domain that you're working in, that's a lot more significant than knowing even the language (let alone the IDE or libraries) that you're using.
rage, rage against the dying of the light
and people weren't openly ridiculing your choice of footwear
Which proves the man is running a Microsoft product, because he's hiding something. I think he may actually be referring to Apple. But like you pointed out, wants to avoid the fans.
.
ditch the platform when the costs of maintaining it become greater than the cost of switching.
Yeah, sounds so simple -- except you've missed a critical variable: how much does it cost to maintain after the switch.
If the cost of post-switch maintenance is only 80% as much per year as the pre-switch cost (a generous estimate in most cases), and the switch takes you only six months (another generous estimate), it's a 2.5 year ROI. Meaning you'll actually be behind where you would have been for 2.5 years before getting any advantage out of the switch. How many businesses can weather that?
I've never seen anyone correctly estimate the cost of switching. Partly because they underestimate the costs of maintenance after switching, believing in the glowing code Utopia of the promised platform. And partly because rebuilding from scratch is usually much more time consuming than people expect: most working systems have lots of tedious, forgettable, but absolutely critical code that must be rewritten and debugged.
To answer the original poster's question: if you've got a substantial working system (read: reasonable performance and reliability) stick with it. Almost any platform can be set up well enough that a decent programmer can work well with it. If the maintenance is such trouble it may be that the programmer sucked, not the platform. In that case, a good programmer can slowly replace the most troublesome components and bring it in line for probably less than the cost of a full switch.
If you can't find programmers who are expert in your platform, look for programmers who are generally experienced and hungry to learn your platform. They're often better anyways.
If the system as it stands doesn't work (read: has major performance or reliability problems), then a switch is a more reasonable option.
Cheers.
I hate Python for the simple reason that I think blocks should never under any circumstances be delineated by whitespace. Sadly there are a number of Python frameworks our there that I really do like, if only they were written in something besides Python.
Curiosity was framed, Ignorance killed the cat.
Been there, done that, rather not do it again. Better to have a pool of people from whom you must determine who sucks, who doesn't, who's a scheister, and who's the straight shooter than a pool of one who could be any combination of the above.
If you never make mistakes, it's probably because you're not doing anything.
All that aside, I do have some commentary:It sounds like you're talking about IT Helpdesk, which I don't know much about anymore. But in the realm of "enterprise" applications (the big, customer-facing, 99.99%+ uptime moneymakers), a developer's insistence on using their own favorite OS rather than the departmental standard is, in my experience, a guarantee of systems-adminstration headaches, instability, confusion, and vulnerability. You may have a list of reasons longer than my big swinging dick as to why your OS is better than the departmental standard, but I guarantee you that once it goes into our datacenter, its nonstandard nature will cause far more problems than it solves.Contrary to popular belief, non-MS operating systems and the applications that run on them are, in fact, exploitable. And I have yet to meet a Linux developer (of which I support several) who didn't insist on flatly ignoring Linux's built-in security features (such as the permissions system, for example), because it was either easier to develop everything as root, or because he had a hard-on for some third-party app that needed to run as root, or both. Maybe your corporate Linux workstation isn't a big security threat, but all my enterprise Linux servers are just as exploitable as my Windows servers. Because it makes my developers' jobs easier.We don't ask you because we don't trust you. We don't trust you because you generally spew evil-universe stuff like this post at us. Also, we don't trust you because you obviously don't know or care about the requirements of good systems administration policy. Asking end-users if they're complying with regulatory requirements is not a sufficient test of regulatory compliance. Your refusal to acknowledge and accept this fact, and work within its framework, only serves to enhance your notoriety as a super-villain from an evil alternate universe.This last item and its explanation are complete gibberish to me. About the only thing I can say for sure is that, yes, if you want to run packet sniffers on a corporate network, then you will get looked at like a criminal.Only from your point of view. From our point of view, we're just trying to do our jobs, within a set of constraints you refuse to understand or even consider, and to prevent you in your ignorance and sense of entitlement from undoing our hard work, ruining our weekends, or putting our employer into serious legal and financial jeopardy.
Any sufficiently well-organized community is indistinguishable from Government.
Sorry I have work on both Perl and PHP. I see little difference in them as far as read ability. Heck if nothing else PHP can be worse.
Python seems like it is better for maintenance but that is from just a quick look.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Any language can result in a mess if used improperly. The solution is to use well defined conventions or a standard framework like Fusebox, and document every process. This requires well trained programmers, who cost more to hire then 'a guy sitting in his basement'.
Dungeon Tactics : Free Open Source SRPG
These days I develop primarily in Java and Php, and I can say with assurance that if you think you can do anything in php that you can do in Java, you're out of your mind.
Php has its place, and it's easy to develop in, but if you can do everything you ever need to do in php, you have pretty simple needs.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
There is nothing wrong with a full up J2EE environment. It simply exists for certain specific purposes. It makes no more sense to write many applications on J2EE than it does to write web sites in FORTRAN.
On the other hand, if you write serious enterprise class middleware there is nothing better and those frameworks you find 'icky' are 100% necessary. You simply CANNOT in any sane world replicate the large scale clustering, distributed transaction management, connectors, and resource management capabilities of a good J2EE server. Furthermore you WILL need that kind of thing if you want to build a piece of software that has requirements like ABSOLUTELY no single failure under any circumstances can ever loose a transaction and you process 10k transactions per second with 5 9's reliability 24/7/365.
The other problem with most developers (most teams) is they simply don't have the training in properly designing their applications for that kind of environment. You HAVE to know all the ins and outs of where your transaction boundaries are, exactly what all the possible execution paths (exceptions especially!) are, and map it all out. Anyone that tries to build complex J2EE apps by sitting down at a keyboard and pounding keys will FAIL miserably, and they will then lament about how horrible J2EE is. No, you need to know exactly what you are going to write first. THEN when you sit down and start developing all that 'J2EE cruft' actually turns out to be your friend because most of the hard stuff is already done for you.
Its all a matter of what you're problem set is, and knowing the tools well enough.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
The problem is that a lot of firms, even some larger ones, don't want to pay the initial outlay for a well-trained programmer. It's more like "Bob, do you know anything about website scripting?" "Why sure Doug, I read the PHP Cookbook last week!" "Great, Bob, write us an E-commerce site."
The world's burning. Moped Jesus spotted on I50. Details at 11.
Keep in mind the original question. The submitter had problems finding a developer for their language. Are there really as many Python, Ruby, or TCL programmers out there are there are Perl, PHP, or ASP programmers? That's why I tend to stick with more commonly used languages. I haven't bothered to learn Python or Ruby, as I prefer to use Perl in case I need to hand the code off to someone else. I write server-side web code in PHP, even though I'd rather stick with Perl, which I'm more familiar with.
What a fool believes, he sees, no wise man has the power to reason away.
To put it another way, a programmer with access to a compiler can get whatever kind of illicit software he wants onto a computer without you knowing; they just program it themselves on the spot if necessary. Any precautions that presume otherwise are foolhardy and give a false sense of security, and can certainly seem foolish as an excuse to prohibit certain activities that would be otherwise harmless.
I've never worked in an environment where any of this applies though, so I may be misconstruing what's going on here.
+ Too hard for us to administer (yes your highness)
That's their job. They answer to their boss and must be able to confirm to them particular policies are in operation.
+ We can't run our anti-virus on your computer (ahem, I don't need that crap)
Just because your Linux/Mac OS X machine might not fall to a virus or trojan, doesn't mean your machine isn't capable of acting as a 'Typhoid Mary' -- capable of passing them to others. That's leaving aside whether they trust you and your chosen distro to keep up to date patches going.
+ We can't tell if you're running unlicensed software on that computer (why don't you just like, ask me?)
Because if you lie (and from experience, users do lie about these things) it can cost gigantic amounts of money in penalties if they're audited.
+ We can't tell if you're running encryption software of packet sniffers you would-be corporate spy?
Their general auditing tool is probably specialised for Microsoft environments. Again, the cost of being wrong (their entire client list or source code going missing or other sensitive information getting where it shouldn't) outweighs the needs of one whiney user -- unless you can give them a good business case as to why your need overrides the risk, you'll be out of luck. Sorry about that.
For some reason, a few of the sysadmins I've met aren't clued into the fact that you can get source-code and compile it into a binary and then execute it. Pretty standard stuff. Software doesn't *have* to be installed using some wizard-install-software, and never need show up on any audit.
I suspect they'd notice the installation of a compiler though where it shouldn't exist ;-).
Perhaps you could scan the computer for filenames of well-known software, but that wouldn't stop someone who knew what they're doing.
Don't underestimate a good Windows policy editor. There are many places where things are extremely well locked down.
I asked one "top" resource if he'd let me use it anyway if I could sniff the network from a windows box without "installing" any software - he looked at me like a criminal.
Well, you'd just admitted plotting to breach network security and likely breach terms of your employment contract. No wonder! ;-). Rather than bitching about sysadmin stubbornness, you should be thanking them for not reporting the incident to your manager and it turning into a formal warning or instant dismissal.
I don't buy that. If a perl developer has the skill of writing readable code then it will be readable. Yes they will have to stop using the mentality that every perl program should e written like a one time use macro but it can be done.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Yeah, right now Java's getting a firm Ruby in the butt though. The number of RonR apps I'm seeing developed is quite interesting. Personally this Ruby on Trains crap gives me a massive headache, but it does work and if you take the time to learn the extensive API it can truly magnify the agility of your site. As soon as I saw RonR I said to myself "how is PHP not dead yet?"
Consider yourself spoken to.
Depends on where you look. Most of the code you see on tutorial sites is pretty bad, since it was probably written by a teenager with no real software engineering experience. The good PHP code is usually done by professional programmers and software engineers working for a company, where it isn't viewable by the general public.
Can't be .Net or Java (shake a tree to find your dev). C/Perl CGI, Perl, Python, PHP, too common to find coders for. Ruby. Hah. Too popular still.
Nobody's considered the real dead end technology of late: ColdFusion. Yes, sites still run it. No, its not quite dead yet. Yes, Adobe provides and has provided plenty of hype to fool managers into deploying things to it.