When Should We Ditch Our Platform? 622
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?"
Solution (Score:5, Funny)
But that would obsolete our hardware! (Score:5, Funny)
Re: (Score:3, Interesting)
System/36? Newbie! I used a System/34 (Score:5, Interesting)
The thing that was cool about the
One thing that wasn't cool about the
Binary is better (Score:4, Funny)
Re: (Score:3, Funny)
In COBOL [uncyclopedia.org]. Using Hollerith cards [uncyclopedia.org] because keyboards are for pussies [boingboing.net].
Am I done yet? Can I go home now?
Re:Solution (Score:4, Informative)
Re:Solution (Score:5, Funny)
Re:Solution (Score:5, Funny)
Re: (Score:3, Funny)
And here I was thinking that COBOL on Rails would be released first.
Looks like I backed the wrong horse again!
Man, I am going to be SOOO fired for this...
Re: (Score:3, Funny)
ha ha (Score:5, Funny)
(And no, AS/400 is not the name of an obscure Linux distro, and RPG does not mean "role playing game" or even "rocket propelled grenade"--it's much worse than that...)
Re:Solution (Score:5, Interesting)
I also did one site in Fortran just to see how it would work. Fortran write statements using formats, is a lot better than using C, I'll tell you that much.
Re:Solution (Score:4)
Re:Solution (Score:4, Funny)
Oh, haven't you heard? HTML tables are out; layouts based on Hollerith fields are in.
Which platform? (Score:5, Funny)
Re:Which platform? (Score:5, Insightful)
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.
Re:Which platform? (Score:5, Insightful)
Re:Which platform? (Score:4, Interesting)
Depends how you measure efficiency, but yes. (Also depends how you define "framework".)
I'm sure someone could write a book -- I haven't got the experience, but someone -- which covered all the possibilities here. Fact is, this is actually something you want to do your best to translate into numbers, and then have a manager look it over and make the call.
The kinds of questions you want to ask are:
You could fill a book with questions like this, analysis, etc -- it's really a bunch of boring business stuff. And it's going to be very different based on what the framework is, what your project is, the lifespan of your project, etc.
For example: I just finished porting a simple corporate website (and a blog) from an old, contractor-hacked version of a blogging engine to a shiny new one. In the process, I tried to avoid touching the actual engine itself, rather adding our skin as a theme, and adapting the site to the features the engine had, rather than the other way around.
Say what you will, but it took the contractors months to make those modifications, and it took me about a week to port what I saved of their stuff over to the new engine. The old site was buggy as hell, probably because of the contractor modifications. The new one actually works.
Now, a few jobs ago, I was working at a company which had a fairly large .NET app, which had SQL injection vulnerabilities all over the place, and was not fun to maintain. But we did anyway, because it was a big app, and we'd lose money anytime it went down, and so on. Maintenance may have been a pain, but a ground-up rewrite was just not feasible, as much as it was needed.
And then there was the odd job I did -- a single server (an old, retired computer) which sits in a corner, whose sole purpose is to run a single app once every three months. I hacked it together as an AJAX app before I really knew JavaScript, with an ugly, hackish backend, horrible limitations, etc. But it allows one person to do in 20 minutes to an hour what used to take two people more like five hours or more, and allows reports to be sent via email, rather than printed out. And it's only run once every three months, so as much as I would like to patch it up now that I know better, it's not worth it -- it's good enough, and no new features are really needed.
Re:Which platform? (Score:5, Insightful)
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.
Re:Which platform? (Score:4, Interesting)
I'm attempting to manage someone else's PHP code, and I can tell you it can be every bit as awful as maintaining alien Perl code. Throw in a spattering of CSS and DHTML, and man-o-man, but trying to read some absent developer's mind can be a nightmare.
So here I am, thinking about redoing the whole thing, just so it makes sense. This is the real problem with a guy sitting in his basement writing your platform for you. Unlike a team where there is proper documentation, notes and usually decently documented source code, you have a collection of half-baked half-used ideas tossed together until they work, but in a fashion so maniacally complicated that you end up spending more time (and thus money) trying to sort it out than if you just simply rolled your own again.
Of course, the guy that follows you has the same problem, because the need to get it into production fast means you don't properly follow conventions either. It's an endless vicious cycle, and PHP is every bit as bad as Javascript, Visual BASIC, VBA and so forth for producing this shitty code.
Re: (Score:3, Insightful)
The problem with your statement... (Score:3, Insightful)
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.
Answered! (Score:4, Interesting)
He gave the answer to this question in the summary.
"It took us an extremely long time to find someone with the necessary skill set."
This can be unacceptable in just about any organization. Depending upon the definition of "extremely long time", which can vary from organization to organization, this is unacceptable. Most places want easily pluggable modules for positions, so that retirement, death, transfer or quitting doesn't break the organization.
This is the equivelent of "vendor lock in" that
There is an unacceptability in being held hostage to a singular developer. At this point, I usually recommend switching to one of the various CMS setups available. It is much easier to find people able to tweak and update using one of the available CMSes, than some proprietary hack that has less features and no other developers.
While this advice is not universal, it most likely would fit the kind of shop that has a single Web Developer on staff (or contract).
This is based upon the general problem presented, the general details, and my understaning of what is available in the market.
Re:Which platform? (Score:5, Insightful)
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.
Re:Which platform? (Score:4, Insightful)
Python seems like it is better for maintenance but that is from just a quick look.
Re:Which platform? (Score:5, Interesting)
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
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 combinatio
Re:Which platform? (Score:5, Insightful)
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.
Re:Which platform? (Score:5, Funny)
I didn't know Lil Jon worked in the tech industry. I suddenly feel the need to crunk-enable all of my servers.
Re:Which platform? (Score:4, Interesting)
My unreasoning hatred for Java blinds me to any semblance of logic. I would suggest Ada before I'd suggest Java.
Re:Which platform? (Score:5, Interesting)
My hatred of Java has nothing to do with speed. The platform has become a giant morass of 'enterprisey' 'solutions' that create more need for more 'solutions'. And all Java 'solutions' must somehow involve XML, because it's standard, and enterprisey.
Re:Which platform? (Score:5, Informative)
I sympathize. However, that is hatred for J2EE, not Java. I stuck with JDK 1.1 until last year just to keep away from J2EE. However, I've found that you can safely ignore that crud, and just use core stuff. It doesn't affect startup time thanks to the classlib precompiler introduced in Java5. (In theory, you can create your own custom compiled classlib minus the crud to save memory also, but the memory isn't an issue anymore with current hardware.)
Re:Which platform? (Score:4, Informative)
Re:Which platform? (Score:5, Funny)
Java is a gift from the Job Gods to make up for the offshoring by creating new specialists such as GUI architects, Object-Relational-Mapper Admins, XML Configuration Admins, I/O library figure-outers, etc. etc. etc.
I'm applying for Hello World Architect by showing on my resume it can be done in under 30 Java classes.
(Yeah, it's flamebait, but venting's therapy.)
Re:Which platform? (Score:5, Insightful)
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.
JDK 1.1 (Score:3, Interesting)
All depends on what you write (Score:5, Insightful)
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.
Re: (Score:3, Interesting)
You know, there's a reason that Java disallows its use in life critical systems in the license. If you really think J2EE is the top of the line in those four topics, you need to do
Re: (Score:3, Insightful)
PHP + Zend Framework [zend.com] - seriously
Re:Which platform? (Score:4, Insightful)
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.
Re: (Score:3, Interesting)
1) Some of the magical pre-processing that occ
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
Re:Which platform? (Score:5, Insightful)
You do the math. (Score:4, Informative)
At least, that's how I do it.
Re: (Score:3, Informative)
Cost of maintenance/repair for 3 years vs. cost of new platform + app migration.
And keep in mind that you're likely to underestimate app migration costs by a significant factor. I think people tend to say "Well, it took four developers and eight months to build the old one, so we'll assume that this newer, more efficient platform will take a little less", completely forgetting that the system as it was at the end of that eight-month development time did significantly less than the one that has since evolved over the course of five years. Your new app needs to be as functional as yo
Re:Which platform? (Score:5, Informative)
Using the shoe analogy, I'd probably say that if she shoe was comfortable, wasn't breaking down after a week of use, and people weren't openly ridiculing your choice of footwear, then your brand should be fine. If it wasn't comfortable but everything else checked out, I'd suggest a different type of shoe regardless of brand. If it was breaking down immediately, hell yes get another brand, and consider spending more than $15 bucks next time. If people are laughing, then you venture into a whole new line of questioning.
Through that whole thing, I don't need to know what brand you wear now. If I did know, I could give you better advice, but what if you were wearing a brand that might not be popular on a particular forum? You would have to separate out the BrandX-haters who make reasonable arguments from people who honestly don't care but have a low opinion of that specific brand.
Which proves the man is running a Microsoft product, because he's hiding something. Only MS can produce that level of guilt.
Popularity... (Score:4, Informative)
Although, in my opinion, you are better off hiring someone who's worked on numerous systems/languages and is willing to learn yours, than switching platforms to get someone with experience in that single platform.
To the original question; if you were planning a major rewrite anyway, that's possibly the best time to switch platforms -- treat the old one as a prototype, and build another. But you're still better off with a team of programmers who have diverse experience, and letting them agree on the platform (after suitable battles with Nerf-weaponry), rather than picking it based on popularity.
Re:Which platform? (Score:5, Funny)
Only the Dyslexic ones.
Re:Which platform? (Score:5, Insightful)
He wants to know, generically, how you decide that what you're using is the wrong choice.
Re:Which platform? (Score:5, Interesting)
Easy answer. (Score:5, Funny)
Re: (Score:3, Funny)
This reason. I like this reason. Is good reason.
As soon as I heard this... (Score:4, Funny)
Soon as I heard this I envisioned pointy hair.
Re: (Score:3, Interesting)
measure the hype (Score:3, Insightful)
Re:measure the hype (Score:5, Funny)
--
When is the last time you hadn't thrown your vote away? Ron Paul even if its write-in!"
The Irony is... overwhelming.
If you have abstraction, switching is a LOT easier (Score:5, Insightful)
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.
If you have a good abstraction layer, even the most proprietary platform won't lock you in.
Re:If you have abstraction, switching is a LOT eas (Score:3, Informative)
Based on my complete lack of experience... (Score:3, Funny)
Re:Based on my complete lack of experience... (Score:5, Insightful)
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.
A few questions (Score:3, Insightful)
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.
Wrong Question (Score:5, Insightful)
Sometimes, you can't ditch soon enough (Score:5, Insightful)
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.
Re: (Score:3, Funny)
Holy negativity pal (Score:4, Informative)
As a software developer I'd like to shoot back.
First of all, I appreciate sys-admins, and would not want to do their job. But they sometimes do seem to miss a few key things about software. Where I used to work, they *refused* to let me run OS X or Linux. I even offered to pay for my own computer. This is in a large multi-national development shop, and also another time in a government department. If shares as servers are configured in a rational manner, then OS X or Linux should have no trouble talking to them, and maybe a developer may be able to to a few tricks on those systems that will save time. But no - the sys-admins just said:
+ Too hard for us to administer (yes your highness)
+ We can't run our anti-virus on your computer (ahem, I don't need that crap)
+ We can't tell if you're running unlicensed software on that computer (why don't you just like, ask me?)
+ We can't tell if you're running encryption software of packet sniffers you would-be corporate spy?
This last item is a complete joke. 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. Perhaps you could scan the computer for filenames of well-known software, but that wouldn't stop someone who knew what they're doing. 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.
Autocratic, and completely clueless.
Re:Holy negativity pal (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
Just to clarify (and not take sides), I think what he's saying is that these people are foolish to assume just because they monitor standard installation procedures (Setup.exe or whatever), they can prevent a developer from running whatever software he wants. As such, their insistence o
Re: (Score:3, Funny)
You know, the rest of your post would have been somewhat reasonable, but this part ruined it all. There was absolutely nothing in the GP post that should have posed the slightest difficulty for a competent system administrator to understand.
I'm going to choose to believe you were exaggerating for effect.
Re:Holy negativity pal (Score:5, Interesting)
They develop web applications but only ever test them on windows. These are apps for the government that are for general consumption. Not having a single OS X or Linux testing station is plain wrong. But hay, at least the corporate types got the contract right? Never mind doing the job properly, or even learning what that means.
Also, testing things on Linux, Windows and OS X is a great way to make sure that what you're doing doesn't have hidden quirks. That goes for designing webpages as well as network shares and other network services.
I find Outlook a terribly annoying email client to use, and would prefer to use my own.
When writing documentation, I find it *much* easier to use OS X's screenshot technology and inter-app tools to bring the pieces together. This saves enough time that I frequently go home to write significant amounts of documentation, and it looks great when it is done, and it's done *fast*.
OS X and linux have a superior command line with a complement of tools that is esp. useful when you're batch processing vast volumes amounts of files. I used to write ruby scripts and run them on windows because of a lack of a command line. That is not the most efficient way of doing things. My co-workers were wowed at the things I could do that they just didn't think were feasible because they have no real experience with getting the command line to sing. Large numbers of files is typical when working on software projects.
I like using multiple desktops, I find that much faster and easier to do than work with the almost crippling windows taskbar.
And there's tones of fanboy stuff too.
What I don't get is how anybody thinks that standardizing everything on windows is somehow going to just make everything cheaper and hunky dory. People use other platforms for a reason, and using a bit of intelligence there is no reason why sysadmins can't figure it out. And you get the benefit of not grid-locking yourself into a single vendor.
To me it seems like common sense is being replaced by a rule book. That's why I left for a smaller company, and they let you run what you want - but only support you with stuff they know. It works out great.
Sounds like you already made a decision... (Score:5, Insightful)
When you start to experience those things in your platform, its usually time to start an exit strategy.
Without knowing the platform, how could we say? (Score:5, Insightful)
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.
Immediately (Score:5, Funny)
languages, talent, and community (Score:5, Insightful)
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.
Well, what is the platform? (Score:5, Insightful)
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.
hmmm (Score:3, Funny)
When the cost of maintaining it... (Score:5, Insightful)
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.
Re:When the cost of maintaining it... (Score:5, Insightful)
I speak from experience. I apparently set someone off in upper management, and the process was set in motion to replace me. When the company received no applications (they placed the salary range in the ad), they removed the salary and asked for salary requirements. My supervisor, who was reviewing the resumes, actually resigned when he saw how underpaid he was!
I got a small raise, I am above the minimum range, but not close the the average for my position. I stayed only because I was already holding on a security clearance to come through for another job. Took 6 months, but it came through and I'll be resigning myself shortly .
Never let management/HR tell you "they can't find anyone." Odds are they are too cheap to pay market.
Exact same problem with Flash (Score:4, Interesting)
This same thing happened to us with Flash.
Flash was all powerful and pretty. Putting aside the serious deficiencies with flash, hiring quality people to work with it was nearly impossible. The people that where good with flash where graphics designers, they like to do pretty animations and colorful graphics, but they where terrible programmers, and knew nothing about usability and user interfaces. The people that where good programmers avoided flash like the plague ( myself included :), why did I ever go work for them? ). Usability people's first recommendation: dump flash.
So if you are a big enough shop, and you decide to do your web application in flash, you need a minimum of 4 people: A graphics designer to do flash, a user interface guy to design your interface and a programmer to do your code, and a project manager that can make them work together. If you are a small shop, and can not afford 4 people, you should really reconsider your choice of platform.
At the end, we ended up switching to good old HTML, the transition was very painful, but now there are lot more options when hiring, the product improved dramatically, and there is less worry about someone being hit by a bus.
Asking the wrong questions.... (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
This suggests a good rule of thumb for replacing a platform:
If a sold-seeming programmer you're about to hire says "You're using platform X? Oh god no, I'm not interested in this job anymore." more than once, it's time to switch platforms.
My first clue is usually... (Score:4, Funny)
True Solution to your problem (Score:3, Insightful)
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.
Do you hate the guy? (Score:3, Interesting)
1) Get 3 vendors to bid on replacing it on your platform of choice, without any functionality changes. Triple the price of the lowest bidder, double the price of the highest, and toss the middle guy out. Then ask: Would you rather pay those prices, or live with what you've got?
2) Answer these questions: Is it a mission critical app? Do you have support for all the hardware and software components - or are some so old that you're on your own?
3) Is the existing code really really a mess, or just the usual well-commented mess most programmers like me leave around?
4) What features do you need to add to it in the next year or two? Can they be added reasonably to the existing code base? Will the hardware, OS, etc support the new functionality, or cave under the weight?
5) Do you hate the guy who wrote the original?
Ok, maybe you should weight that last question a little lightly. But at least there's some things to think about before pulling your own plug, or someone else's chain.
Job Trends (Score:3, Interesting)
did other factors come in to play? (Score:3, Insightful)
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?)
The Platform? It's Ruby (on Rails) (Score:5, Insightful)
- 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
What is your job description? (Score:3, Insightful)
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"
Don't assume it's the platform (Score:5, Insightful)
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.
The road ahead (Score:4, Funny)
I love business metaphors.
Is there a Right Horse? (Score:3, Informative)
Anyway... the easiest way to tell if you're wrong is to show your code to several developers in house and if they run screaming from the building, you might consider switching platforms...
Be sure you're not overvaluing platform knowledge (Score:3, Insightful)
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.
Quick answer (Score:3, Interesting)
Is this some scientific/complex application that is written in a language that just isn't popular today, but isn't too large? Well then you "might" consider migrating it over time.
Obviously this isn't something to be taken lightly, because the expense of migration/bug testing and possible validation can be HUGE for large systems.
I only have a small amount of data that you provided, so I can say that I "might" look at trying to expose as much of the legacy system as possible via a web service or some other "normal" RPC call and then look at having another system start to use the business logic in the core system, but have in written in a more modern and common language (Java). You "might" be able to start and pull off parts of the system over time that way.
You, Sir, are talking Bullshit. Plain and simple. (Score:4, Interesting)
Since you're not saying which plattform I suspect you rode with some standard fare OSS plattform (which are all very good for 99.9% of all web solutions) for free and expected to get the programmer along with it for $4 per hour or something like it.
You said you had to look hard to replace you guy ("It took us an extremely long time to find someone with the necessary skill set."). You, Sir, are a liar. Here's what really happend: You chose a plattform (... jadajada, Django, Rails, Zope, EZ Publish or even
I tell you what: Stuff this bullsh*t about 'lack of skillset'. I've heard it all many times over and I'm sick of it!
Pay and treat the people the fair and you'll have so many well-versed devs at you doorstep you'll have to shoo them away. And once you've got your favorite, show him/her your web-setup. If he's an OSS guy and you happend to jump on
Oh, and to drive the point home:
If you're really lacking skillset and have a tough time finding it, I've got customers in the US too. I'm a freelance webdeveloper from Europe who also does consulting. Especially for the very sort of situations you claim to be in. Give me a neutral contact email-address here (post it in a child) and you'll get my contact data. Get back to me over your official channel and if we strike a deal and you afterwards can plausibly refer to this slashdot question as being your's I will apologize, stand corrected and you get 200 Euros off the bill. That's fair, isn't it?
And now I ask you, my fellow slashdotters:
What's the bets we'll never hear from this guy again?
WWGGD? (Score:3, Funny)
Betting on ANY specific tech is the wrong horse (Score:3, Informative)
By realising that if you back any kind of specific technology you've already backed the wrong horse. Back your people and you'll stay on track a lot better. Good technical staff can learn any new technology - really, how many genuinely "new" technologies have there been in the last 25 years anyway? Two, three?
But the modern world hires specific people for specific roles and specific technology. Know J2EE and .NET? Tough you'll be hired only for one or the other and the MBAs will bitch that they've backed the wrong horse if there choice goes south. Doesn't matter that you can do both and learn both - you were only hired for one, so they'll sack you and spend months finding somebody else.
All technology is extict and replaced within a decade. Yes, even COBOL has gone through significant "upgrades", and I seen managemers not hire people because they have worked with Cogen 2.5 and not Cogen 4. Like its *that* different. Worked with Oracle 8 for most of your career but somebody else has worked with Oracle 9 for six months? They'll get the job because "They have more recent Oracle 9 experience".
So in summary: You're screwed. And you're screwed because you've been too specific in your hiring and have bypassed generalists who can learn. Computers can't learn and technology never will.
Oh all right, I'm generalising. I'm venting. I don't know whether your company has this sort of a hiring practice (but I really bet it does). I've been looking for a role for a couple of months and been pidgeon holed so bloody often. And yet my home network is more complicated and technically challenging then anything I've seen commercially for the last few years.
Re: (Score:3, Insightful)
I think that tells you something about why people choose Microsoft no matter what. Quite often the decision to go with a cool, new technology is not a good one simply because it is new and cool. Old and boring generally always wins in this industry.
Re: (Score:3, Funny)
- think of an add "wanted: lean, mean programmers, that are worth their weight in gold"
- We pick the small ones, they cost less.