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

Comments

Solution

[TheSpoom]

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

Re:Solution

[lexarius]

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

Re:Solution

[Anonymous Coward]

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

Re:Solution

[HomerJ]

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?

[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]

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?

[mooingyak]

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]

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.

Re:Which platform?

[Grayputer]

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?

[moderatorrater]

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?

[Dragonslicer]

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.

Wrong Question

[tha_mink]

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.

Immediately

[z-j-y]

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.

When the cost of maintaining it...

[KillerCow]

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

Don't assume it's the platform

[Dynedain]

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.

All depends on what you write

[Giant Electronic Bra]

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.