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

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

But that would obsolete our hardware!

Fortran works better than anything else on punch cards.

Re:Solution

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

Re:Solution

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

Which platform?

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?

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?

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?

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?

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?

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?

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?

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.

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.
 

Wrong Question

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

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.

Sounds like you already made a decision...

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?

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

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

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?

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

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

Asking the wrong questions....

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.

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

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

"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

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.