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

move on?

[Russell2566]

It's hard to give tons of feedback without knowing more about what your currently using (low use tech / vs god hates your HR staff) but if your going to consider making a tech jump, I would highly recomend making a major version jump (assuming your writing that kind of application).

Depending on the age of the current app(s) and skill of your past developers, sometimes a total rewrite is cost saving in the long run by aiding in faster turn-around and all around easy of adding on to the app at a later period...

Re:Solution

[shutdown -p now]

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

Re:Which platform?

[LithiumX]

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:If you have abstraction, switching is a LOT eas

[doom]

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.

Why that's a great idea... if you don't mind crippling all of your database code so that it runs at the same mediocre level with every database. ("We can't use materialized views!"; "Why not?"; "Well, database X and Y don't have them yet."; "But we're not using X and Y...")

(Personal opinion: if you start with postgresql, you won't ever need to switch, and database-independence starts looking like a pretty silly goal.)

Holy negativity pal

[microbox]

Hi,

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

[CustomDesigned]

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?

[mongus]

Not all Java "solutions" use XML and require that you develop EJBs. You just haven't seen the right platform for Java web development.

Re:Asking the wrong questions....

[G Wonder]

I completely agree with the above post. When hiring developers it is much more important to look for smart people, who get things done. Not for someone with a lot of keywords in a resume that match your particular environment. Smart programmers will be able to pick up the languages, concepts, methodologies and design patterns used in your current application whatever platform it's on.

A smart developer will be able to tell you whether your application is built in such a way that it can be maintained and expanded upon or if it's such a mess that it may be better to abandon it to re write on another platform. So the real answer to your question is to hire someone who is smart and let them have a lot of input into the decision about platforms, technology and such.

That being said if you can find a smart programmer who also has experience in your platform and in your business domain, that's the cats behind ;)

I do a lot of hiring of developers at the company I work for and I've found that my favorite person to read about hiring and interview practices is Joel Spolsky, check out http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html, it's a great article that I've used as the basis for my own interviewing technique. Also check out his archives at Joel On Software. He comments on interviewing and hiring practices a lot.

Is there a Right Horse?

[Greyfox]

I haven't really run across a web application platform I really like so far. It seems like the best solution is to write a Javascript front end to track state and a back end that delivers chunks of data to the front end. I don't particularly like Javascript either but so far it seems like the least sucktastic solution available. In that scenario, pretty much ANYTHING could serve as the back end as long as it can route requests based on the URL. Or you could use SOAP to get the data you need.

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

Popularity...

[mengel]

Actually, the OP mentioned why most people think popularity of platform is important -- being able to hire people who already know how to work on it -- it's the "wanted: programmer with 3 years experience coding java beans" mentality; you pick the platform so that when you put that want ad out there are lots of respondants.

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.

You do the math.

[FatSean]

Cost of maintenance/repair for 3 years vs. cost of new platform + app migration. Eat the support costs. Factor in the increased performance the new platform may provide. Wave hands around and shake the 8-ball.

At least, that's how I do it.

Re:You do the math.

[swillden]

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 your old one will be a few months from now. Also, don't forget to factor in time for developers to learn the new toolset, and if they have any responsibilities for supporting the old stuff, better assume a good chunk of their time will be going to that.

Finally, don't forget to add a fudge factor to correct for the fact that you probably really want to build a new system. That fact is clouding your judgment on any number of issues.

Re:Which platform?

[Roadmaster]

Using vim? here ya go (automatic end insertion on ruby and erb code). Not using vim? well not everyone is perfect ;)

Betting on ANY specific tech is the wrong horse

[rmerry72]

How are folks out there determining when you've backed the wrong horse, and getting back on track?

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:All depends on what you write

[demi]

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.

Yes, you can, and pretty easily, too, using Erlang. The contortions you have to go through in Java to get messaging, queuing, bus-connections, failover, clustering and all that stuff to work is ridiculous. You can spend hours declaring, configuring, creating adapters, installing drivers, extensions, hibernate properties, blah blah blah and you're not only no closer to being done, you get to write your logic in... Java!

Java goons can spend days talking about persistence layers and attribute storage and web service connecters to the enterprise bus. And after weeks of hobbling along and some purchases of middleware and object brokers and JMS this and that (and don't forget the servers to run it) they can start writing a bajillion classes and interfaces for every function. All this to support a messaging system with no more functionality than this:

resource ! {self(), {request, Key}

And no, that's not the abstraction or exposed interface--that's the nitty gritty detail.

Java--the technology, the language, and the culture is a joke. Unfortunately, as you say, it's ever so Serious and Ready for the Enterprise--so it's not a very funny joke. When you actually get your Enterprise Solution delivered (never anything so Un-Serious and Un-Enterprise as a program in Java World), you now get to deal with upgrade and dependency headaches, schema changes and--why is my RPC performing so poorly? Marshalling overhead? How do I fix that? Throw away my objects, throw vectors of strings at it, buy faster CPUs, throw some more Tibco on it, please!

Five 9s? Erlang has been used to build systems with Nine 9s. In your list of desirable features (many of which don't inherently require teams of engineers poring over UML diagrams but in fact are trivial or easier in Erlang). I mean, good God, why should you have to "know exactly what you are going to write first" just to distribute load and share data amongst servers? Why should you need "special training" to write an application that can automatically and statefully fail over from one node to another? Next you're going to tell me the answer to software reliability is just to make sure you don't have any bugs in your application!

In your more or less random list of requirements you forgot online code upgrades (with no sessions dropping, please), task migration and interactive management.

There is nothing wrong with a full up J2EE environment. It simply exists for certain specific purposes.

Paul Graham had it right when he said that Java was popular in corporate environments because it produces a lot of what looks like work. If you want a lot of mediocre people busily coding away--well, not coding; declaring, annotating, configuring, setting build properties and constructing--then Java really is great for that specific purpose.