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?"

Solution

[TheSpoom (715771)]

Stop using FORTRAN. It really wasn't built for the web, you know.

But that would obsolete our hardware!

[EmbeddedJanitor (597831)]

Fortran works better than anything else on punch cards.

System/36? Newbie! I used a System/34

[billstewart (78916)]

I has a summer job in college doing programming on an IBM System/34, mostly in RPG2. It had 48KB of Semiconductor RAM (as opposed to real core), and a 13MB Winchester drive, and came with two IBM employees who were around every couple of weeks to keep it happy (usually by updating the accounting software, and then re-patching the updates to deal with the customizations our system had because the construction industry does accounting differently.) Unfortunately, we only had the slow printer, not the fast printer, so compile time was largely constrained by how long it took to print out the 10-page program listing, which was 20-30 minutes, and the printout was not optional; you always got one when you compiled. And of course when the Apple II came out, except for the disk drive it could totally kick the /34's ass, not that you'd want to run corporate accounting packages on the Apple.

The thing that was cool about the /34 was the Operations Control Language, which was a shell-like interface that you could actually do simple programming in. It was obviously cooler than JCL, but it was also even cooler than the PDP-11's RSTS-11 user interfaces that we used to run BASIC programs.

One thing that wasn't cool about the /34 was its mainframish approach to file system management - the OS wrote new file system headers when you saved or closed a file, but if it got interrupted before you'd done that, you basically lost everything. We were a steel fabricating company, and one day the clerk had spent about 6 hours typing in the list of parts we were going to need for a project, and some guy in the shop was trying to shut off the circuit breaker for his welder and powered us down instead. Fortunately she'd entered an hour or so worth of data the day before, so there were pointers to the beginning of the file and where it had ended after the first hour's work, and it was an extent-based file system. So I spent about 5 hours on the phone with IBM wandering through hex dumps of the file system to find the remaining pieces; it ended up being slightly faster than just retyping the whole thing would have been, but that could have easily gone either way. If you remember fsdb, it was kind of like using that on the raw disk.

Binary is better

[sjwest (948274)]

we train monkeys to shout 1's and 0's at computers. The Monkeys are happy.

Re:Solution

[shutdown -p now (807394)]

You're joking, but sometimes it's for real. Care to try PL/SQL [fortunecity.com] for that instead?

Re:Solution

[lexarius (560925)]

You'll change your mind after you see FORTRAN on Rails.

Re:Solution

[by Anonymous Coward]

FORTRAN runs in Ruts, not on Rails, don't forget.

ha ha

[mkcmkc (197982)]

You think you're joking, but you haven't lived until you've helped someone deploy their Java-on-AS/400-based webserver (itself a front-end to their RPG-based database).

(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

[HomerJ (11142)]

I've actually WRITTEN web backends in Fortran....how else are you going to make a pretty website with data that only sits on a 20 year old VAX?

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.

Which platform?

[by Anonymous Coward]

How do you expect Slashdot readers to tell you whether to ditch your platform unless they know whether it is Microsoft or not?

Re:Which platform?

[LithiumX (717017)]

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.

Re:Which platform?

[Brian Gordon (987471)]

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.

Re:Which platform?

[moderatorrater (1095745)]

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.

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 .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.

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?

[MightyMartian (840721)]

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.

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:Which platform?

[localman (111171)]

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.

Re:Which platform?

[Dragonslicer (991472)]

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.

The big difference is that PHP gets more readable as the skill level of the person who wrote it increases, while Perl gets less readable as the skill level of the person who wrote it increases.

Re:Which platform?

[Rary (566291)]

But there isn't a general answer. In order for anyone to give an accurate assessment of the situation all factors must be taken into account.

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?

[blincoln (592401)]

Is the site Java based? Dump that trash, because only bitches use Java.

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?

[LithiumX (717017)]

Out of curiosity, what would you recommend using instead of Java (and don't you dare say PHP)?

My unreasoning hatred for Java blinds me to any semblance of logic. I would suggest Ada before I'd suggest Java.

Re:Which platform?

[Omnifarious (11933)]

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?

[CustomDesigned (250089)]

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.

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?

[Tablizer (95088)]

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.

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?

[forgotten_my_nick (802929)]

"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.

All depends on what you write

[Giant Electronic Bra (1229876)]

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.

Re:Which platform?

[Grayputer (618389)]

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.

Re:Which platform?

[LithiumX (717017)]

I do believe the original question was how do you know when you're off-track, rather than asking if he should drop his specific technology.

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.

Re:Which platform?

[powerlord (28156)]

I wear KDEs shoes. Don't all Linux users?

Only the Dyslexic ones.

Re:Which platform?

[mooingyak (720677)]

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.

Re:Which platform?

[orclevegam (940336)]

He wants to know, generically, how you decide that what you're using is the wrong choice.

All choices are wrong, some are just more wrong than others. Generally you attempt to find the least wrong choice at that time, and then periodically re-evaluate the cost of switching to a newer less wrong choice.

Easy answer.

[Colin Smith (2679)]

He wants to know, generically, how you decide that what you're using is the wrong choice.

Well, that's simple. It's when you are more than two standard deviations away from the mean.
 

As soon as I heard this...

[Weaselmancer (533834)]

..but the rubber hits the road when you have to hire someone to maintain that code...

Soon as I heard this I envisioned pointy hair.

Wrong Question

[tha_mink (518151)]

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.

Sometimes, you can't ditch soon enough

[susano_otter (123650)]

The developers I support have somehow convinced upper management to let them build their app around a third-party application that, get this:

• Can only be installed by third-party technicians
  
• Costs us several thousand dollars for the installation service
  
• Must be scheduled at least a month in advance for installation
  

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:Holy negativity pal

[susano_otter (123650)]

Like I said, we live in opposed-alignment alternate universes. Each of us is convinced the other's universe is the evil one. Everything you've just said only serves to reinforce my own conviction. Indeed, even the way in which you said it reinforces my conviction. Far from including the kind of technical clarity that would allow me to rationally evaluate your demands and make a well-informed decision on whether or not an exception to the policy was warranted in this case, you instead degenerated steadily into technical inchoherence so that by the end of your post I have no idea what you're talking about anymore. No doubt you--like my own developers--sincerely believe you've been crystal clear in every important detail.

All that aside, I do have some commentary:

Too hard for us to administer

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.

We can't run our anti-virus on your computer (ahem, I don't need that crap)

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 can't tell if you're running unlicensed software on that computer (why don't you just like, ask me?)

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.

We can't tell if you're running encryption software of packet sniffers you would-be corporate spy?

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.

Autocratic, and completely clueless.

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:Holy negativity pal

[microbox (704317)]

Well...

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...

[javabandit (464204)]

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.

Without knowing the platform, how could we say?

[seebs (15766)]

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.

Immediately

[z-j-y (1056250)]

And I recommend Ruby on Rails. Its developer community has been growing exponentially, from 5 guys in 2006 to 10 guys in 2007. If you are extra conservative, you can try Groovy on Rails. It's just like Java, but better.

languages, talent, and community

[davejenkins (99111)]

A platform is a semi-permanent thing. You cannot just switch your website platform for a major ecommerce site over the weekend-- plan on several months of pain. If you don't plan, figure on several years of severe pain.

Platform choice should come down to three things, IMHO:

• language - must be flexible and interconnectable with 3rd parties. Your platform won't do everything, and you'll be using a lot of 3rd party vendors for analytics, cross-sell, reviews, image hosting, etc. Make sure your language plays nice with others: Java, PHP, perl, .NET are all 'common', so these should be good.
  
• talent - in my previous city, there was a good amount of perl people, as well as java developers. Now I am in the midwest, and everyone seems to be all .NET this and .NET that-- so, .NET seems to make sense, as we would be pulling talent from this pool for our staff. Some areas of the country are stronger in different languages and platforms.
  
• community - there are some great platforms out there, but their communities are dying or shrinking. Other communities have a lot of people, but most of them are script-kiddies. Beware. A platform should be both 1) a bit mature, and 2) viable community.
  

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?

[SmallFurryCreature (593017)]

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.

When the cost of maintaining it...

[KillerCow (213458)]

... 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.

Re:When the cost of maintaining it...

[Timinithis (14891)]

"We couldn't find anyone" usually equates to we are too cheap to pay the market rate.

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

[paulpach (798828)]

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....

[johnlcallaway (165670)]

So .. you can't find someone with the right 'skill set'.

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 ... go find some smart people and let them loose. They'll take care of it.

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.

My first clue is usually...

[penguinstorm (575341)]

when Microsoft "embraces" the platform.

The Platform? It's Ruby (on Rails)

[Azure Khan (201396)]

He said all the right words to point to Ruby or ROR as the platform they chose:

- 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 .NET/LAMP/Perl/Python in terms of available production man power.

Don't assume it's the platform

[Dynedain (141758)]

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.

Re:Based on my complete lack of experience...

[ajs (35943)]

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.

Re:measure the hype

[Kingrames (858416)]

"I've found that the more a manufacturer hypes a product the more likely it is to be a flash in the pan...
--
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

[quanticle (843097)]

Most platforms don't provide a simple way to transition between one platform and another, especially in the web development sector.

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.