Forgot your password?
typodupeerror
Programming IT Technology

When Should We Ditch Our Platform? 622

Posted by kdawson
from the future-shock dept.
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?"
This discussion has been archived. No new comments can be posted.

When Should We Ditch Our Platform?

Comments Filter:
  • Solution (Score:5, Funny)

    by TheSpoom (715771) * <{ten.00mrebu} {ta} {todhsals}> on Thursday March 06, 2008 @03:11PM (#22666280) Homepage Journal
    Stop using FORTRAN. It really wasn't built for the web, you know.
    • by EmbeddedJanitor (597831) on Thursday March 06, 2008 @03:14PM (#22666326)
      Fortran works better than anything else on punch cards.
      • Re: (Score:3, Interesting)

        by Omega996 (106762)
        I've had no experience with Fortran, but a billion years ago when I got my start in IT I remember writing programs in RPG II for a System/36. I remember the joys of the program cycle, and struggling to remember the positional params without the 'punch-card' cheat sheet. Actually, in retrospect, it's kind of keen in a really nerdy way that RPG had that 'virtual punch-card' support, but I wasn't so hot for it at the time...
        • by billstewart (78916) on Thursday March 06, 2008 @08:43PM (#22670948) Journal
          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.

    • by sjwest (948274) on Thursday March 06, 2008 @03:24PM (#22666514)
      we train monkeys to shout 1's and 0's at computers. The Monkeys are happy.
    • Re:Solution (Score:4, Informative)

      by shutdown -p now (807394) on Thursday March 06, 2008 @03:30PM (#22666594) Journal
      You're joking, but sometimes it's for real. Care to try PL/SQL [fortunecity.com] for that instead?
    • Re:Solution (Score:5, Funny)

      by lexarius (560925) on Thursday March 06, 2008 @03:40PM (#22666746)
      You'll change your mind after you see FORTRAN on Rails.
    • ha ha (Score:5, Funny)

      by mkcmkc (197982) on Thursday March 06, 2008 @03:56PM (#22666980)
      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 (Score:5, Interesting)

      by HomerJ (11142) on Thursday March 06, 2008 @04:33PM (#22667582)
      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.
    • by mengel (13619) <mengel.users@sourceforge@net> on Thursday March 06, 2008 @04:37PM (#22667670) Homepage Journal
      Sure it was! How about the following demonstration:

      program hellocgi
      write (*,100) 'Content-Type: text/html'
      write (*,100) ''
      write (*,100) 'hello world!'
      stop

      100 format (a)

      end
      (Boy is it hard to get Slashcode to do a decent fortran listing -- I had to do double-nested blockquotes with ecode blocks inside except for the line numbered part... And I had to add this at the end to make it not complain about how many characters per line the post is)
    • Re:Solution (Score:4, Funny)

      by hullabalucination (886901) on Thursday March 06, 2008 @04:37PM (#22667674) Journal

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

      Oh, haven't you heard? HTML tables are out; layouts based on Hollerith fields are in.

  • by Anonymous Coward on Thursday March 06, 2008 @03:14PM (#22666318)
    How do you expect Slashdot readers to tell you whether to ditch your platform unless they know whether it is Microsoft or not?
  • measure the hype (Score:3, Insightful)

    by budgenator (254554) on Thursday March 06, 2008 @03:14PM (#22666330) Journal
    I've found that the more a manufacturer hypes a product the more likely it is to be a flash in the pan; If your lucky the previous programmer made a well designed application that will be easy to translate into other platforms or languages. Still sooner or later everything goes the way of the dodoe, I learned COBOL once apon a time.
    • by Kingrames (858416) on Thursday March 06, 2008 @03:33PM (#22666630)
      "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.
  • Right now seems like the perfect time to get yourselves a new platform, preferably something easy to maintain.
    • by ajs (35943) <ajs@@@ajs...com> on Thursday March 06, 2008 @03:21PM (#22666456) Homepage Journal
      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.

  • A few questions (Score:3, Insightful)

    by Nightlily (140378) on Thursday March 06, 2008 @03:18PM (#22666396) Homepage Journal
    You didn't say where your organization is, but have you factored your location into the equation? Maybe in another area, you could find web developers with the correct skill set. Of course on the other hand, you could be using something outdated.

    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)

    by tha_mink (518151) on Thursday March 06, 2008 @03:20PM (#22666434)
    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.
  • by susano_otter (123650) on Thursday March 06, 2008 @03:20PM (#22666444) Homepage
    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: (Score:3, Funny)

      by Reverend528 (585549) *
      The developers convinced the management that they needed to use some god-awful platform? It's like you're working in some evil alternate universe!
  • by javabandit (464204) on Thursday March 06, 2008 @03:22PM (#22666476)
    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.
  • by seebs (15766) on Thursday March 06, 2008 @03:22PM (#22666480) Homepage
    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 (Score:5, Funny)

    by z-j-y (1056250) on Thursday March 06, 2008 @03:25PM (#22666516)
    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.
  • by davejenkins (99111) <slashdot@davejenkins. c o m> on Thursday March 06, 2008 @03:26PM (#22666534) Homepage
    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.
  • by SmallFurryCreature (593017) on Thursday March 06, 2008 @03:29PM (#22666586) Journal

    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)

    by circletimessquare (444983) <circletimessquare AT gmail DOT com> on Thursday March 06, 2008 @03:32PM (#22666618) Homepage Journal
    i highlighted "When Should We Ditch Our Platform?" but IntelliSense doesn't have any suggestions
  • by KillerCow (213458) on Thursday March 06, 2008 @03:33PM (#22666628)
    ... 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.
    • by Timinithis (14891) on Thursday March 06, 2008 @05:53PM (#22668940) Homepage
      "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.
  • by paulpach (798828) on Thursday March 06, 2008 @03:33PM (#22666634)

    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.

  • by johnlcallaway (165670) on Thursday March 06, 2008 @03:35PM (#22666668)
    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.
  • by penguinstorm (575341) on Thursday March 06, 2008 @03:38PM (#22666710) Homepage
    when Microsoft "embraces" the platform.
  • by RaigetheFury (1000827) on Thursday March 06, 2008 @03:46PM (#22666834)
    I don't need to know your platform to help you qualify that answer. This is easy.

    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)

    by Spinlock_1977 (777598) <Spinlock_1977@nOspam.yahoo.com> on Thursday March 06, 2008 @03:47PM (#22666850) Journal
    Here's what I'd recommend:

    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)

    by Target Drone (546651) on Thursday March 06, 2008 @03:53PM (#22666944)
    You can graph the trend of platforms/frameworks using job postings. For example heres rails, jsf, wicket, struts [indeed.com]. Make sure you look at both the relative and absolute numbers though. The relative gives you an idea of the trend for an individual platform. The absolute tells you how big it is compared to others.
  • by petes_PoV (912422) on Thursday March 06, 2008 @03:54PM (#22666954)
    You say It took us an extremely long time to find someone with the necessary skill set.

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

  • by Azure Khan (201396) on Thursday March 06, 2008 @04:00PM (#22667066)
    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.
  • by kcdoodle (754976) on Thursday March 06, 2008 @04:05PM (#22667134)
    You probably are not the person to make this decision.

    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"
  • by Dynedain (141758) <slashdot2@anth[ ... m ['ony' in gap]> on Thursday March 06, 2008 @04:06PM (#22667158) Homepage
    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.
  • by lennier (44736) on Thursday March 06, 2008 @04:32PM (#22667546) Homepage
    The rubber hits the road when you back the wrong buzzing horse off a running platform that's not on the right track, and have to ditch it.

    I love business metaphors.
  • by Greyfox (87712) on Thursday March 06, 2008 @04:46PM (#22667866) Homepage Journal
    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...

  • by pthisis (27352) on Thursday March 06, 2008 @04:51PM (#22667980) Homepage Journal
    You should drop it when there's another platform that's so much better than yours as to justify the effort of moving away (ie not just slightly better unless your code base is tiny). Normally any decent developer won't have a tough time adjusting to any decent platform, so the reason to switch isn't really that developers are hard to find who can work on your platform (unless it's something really unsuited to the job), it's that developers are hard to find who _want_ to work on your platform.

    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)

    by FatherOfONe (515801) on Thursday March 06, 2008 @06:02PM (#22669066)
    first you need to decide how painful it will be to migrate. Is this some mainframe application that has had 20+ years of refinement and bug patches behind it, that happens to be in the millions of lines of code size? If that is the case then you keep kicking the dead horse for a while.

    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.

  • by Qbertino (265505) on Thursday March 06, 2008 @06:11PM (#22669174)
    This question plays into simular territory that one that came just a week ago [slashdot.org]. And, as you can tell from the subject, it really gets me going. If you are of the kind who posts questions on slashdot, then you at least are somewhat tech-savy enough to judge fairly quickly after talking to a handfull of developers if you're plattform is rubbish or not.
    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 .Net it doesn't really matter for this part) and, so I strongly suspect, were paying your main "maid for everything" dev with a shoestring budget who then probalby left on his own when the farce became more than his self-respect could bare. You didn't train him on the technology, you didn't give him air to breathe, you didn't let him run his mind, you didn't space (not to speak of pay) the enviroment, pipeline and toolset needed for the product you wanted and you most certainly didn't plan *or* stick to your calls you made four weeks before. The usual stuff everybody with real developement experience here on slashdot has seen time and time again. (Watch them mod me way up to Jupiter to see what I mean)

    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 .Net because of some hair-brained idea back in the day, he'll tell you he can continue with that for an extra 20 000$ per year to compensate for learning a hermetic skill or you give him free reighn and he'll implement on whatever buzzword draws the highest line in OSS technologies on trends.google.com. Or he'll maybe just dive into the system you're running and come out on top after half a year.

    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)

    by cyberfunkr (591238) on Thursday March 06, 2008 @08:00PM (#22670488)
    Roll a d20 and consult the correct chart.
  • by rmerry72 (934528) on Thursday March 06, 2008 @11:45PM (#22672152) Homepage

    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.

Happiness is a positive cash flow.

Working...