Slashdot Mirror
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?"
Stop using FORTRAN. It really wasn't built for the web, you know.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
How do you expect Slashdot readers to tell you whether to ditch your platform unless they know whether it is Microsoft or not?
Fortran works better than anything else on punch cards.
Engineering is the art of compromise.
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.
Apocalypse Cancelled, Sorry, No Ticket Refunds
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...
Right now seems like the perfect time to get yourselves a new platform, preferably something easy to maintain.
I used to carry a bottle of whiskey for snake bite. And two snakes. -Nefarious Wheel
I like Noah's method when it comes to platforms...two of each.
Of course, that can get costly, but, when you work for the government...
Nothing interesting to say...MUST...NOT...REPLY...ohtheheckwithit.
If you are having trouble finding the skillset, then you probably are on a less mainstream platform. It might work for you, but if your goal is to have interchangable parts, stick to platforms that are "standard". Look through the job sites (Monster, Dice, what have you) and figure out the top three requested technologies in your area are and stick to them. If your field is real estate, make sure you weigh postings for work in that field a little heavier (since it is more likely that canned software supporting real estate will also lean that way) -- if it's health care, then weigh those heavier.
This won't ensure that you get anyone of any quality, but it will ensure that you have a platform that can be supported easily.
Layne
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.
How are folks out there determining when you've backed the wrong horse, and getting back on track?"
That line of thinking is dangerous. The thing to do with horses is to just shoot the horse and breed a new one. I STRONGLY ADVISE YOU NOT TO FIRE BUCKSHOT INTO YOUR SERVERS!! For one thing, electronics do not breed well. Of course there are others, but this is a big one.
I got a catholic block.
"When you stopped getting paid (a living wage) for it."
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.
You'll have that sometimes...
When it sucks. And since you chose to leave it nameless, I'd say it probably sucks.
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.
Any sufficiently well-organized community is indistinguishable from Government.
Jokes about Fortran might be funny, but without knowing what your platform is, we can only answer in very vague ways. If you can't find anybody to work on this platform, and can't train anybody, then you need to replace the platform now and you have no choice. But this probably isn't really true -- what's more likely is that people who know this platform are hard to find or want to be well paid and it becomes a tradeoff. How much is invested in the platform? How much work to move to something else? And what to move to? We need more details
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.
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.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
You should finish rewriting your site around the same time you start seeing articles extolling the latest and greatest language that some too-smart developer dug up from obscurity after becoming bored with the last obscure language they used and got other bored minds excited about.
Then again you could just write it in Sanscrit, a 5000 year old dead language, I'm sure lots of kids coming out of college majored in that.
-- taking over the world, we are.
If the system works, but you are just having an issue finding help, then the issue is not the platform it is the job pool. Perhaps you are setting your sights too high, or perhaps you are wording your help request poorly. I happen to be skilled in Linux admin, yet in my current job I am working with a mixed Solaris and zOS environment. The skill difference turned out to be very slight, and within 2 weeks I was up to speed for the most part.
Karma Whoring for Fun and Profit.
not the programming platform that is causing the issue.
we train monkeys to shout 1's and 0's at computers. The Monkeys are happy.
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.
But here are a few tips anyway, perhaps they can make your decision easier:
So, in a nutshell, I recommend Perl, Postgresql and FreeBSD. Plenty of experienced developers, and the tools Just Work.
I will gladly work for my weight in gold per year.
I estimate that to be about 2.2 mil USD per year.
Platform choice should come down to three things, IMHO:
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.
davejenkins.com |
Avoid the latest technology, use languages/tools/etc with a proven mainstream history. This might mean you need to skip having the fastest and flashiest, but in return you'll have code that people will know how to maintain five years from now.
Leveraging existing technologies to advance a new paradigm shift is important. You need to keep in mind that with the advance of Moore's law and the approach of the singularity, that you can't stay in old technology. You see, on one hand, we have programmers, and on the other, we have technology, and together...., wait, oops, what I meant to say was, on one hand we have technology, and on the other, programmers, and together, with synergy, profits will only increase. What concerns me most about your question is that you are only seeking one programmer. Using agile web development you will need at least two programmers, working in a team environment. If you only have one programmer, he is likely to get lonely, which is probably why your last programmer quit. Finally, do you love what you do? This is an important question. You see, if you don't love what you do, how can you expect to hire people that love what they do? Make sure that you love what you do, and if you haven't told your coworkers this lately, be sure that they know it. Before jumping ship to a new platform, keep that in mind.
Get rid of the PHB who is makeing the choices and replace him with someone who knowns what they are doing and has the power to put in a new web system that is better.
My guess is that you're talking about a Mac Server with Ruby on Rails, which despite being a hot buzzword and so much talk about it, really has very few experienced developers out there.
Most platforms are fully capable of dealing with average loads. If the solution is working fine, perfoming well, and just needs maintenance... then I'd suggest that maybe you just need to change your hiring practices. Maybe you really don't need someone with 3 years of experience in the technology. Maybe what you really need is someone with enough experience overall that he can learn or pickup the technology quickly and apply his experience in other technologies to that technology?
On the other hand, training someone in a technology that is in short supply is a sure bet that they'll go somewhere else that will pay them more as soon as they have the requisite experience.
You really need to do a Cost/Benefit analysis. How much will it cost you to convert your platform to something else? How much benefit will that give you?
If you need web hosting, you could do worse than here
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.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Sounds like you've been left out in the Cold... a Fusion of problems, it seems.
But seriously, it's worth mentioning that sometimes the word "platform" is confused with the word "framework" or some other level of organization. A perfectly good scripting language can be used to build up a web site with an intolerably obtuse nested include file strategery. The web site's platform could be a poor implementation of a perfectly usable technology - but with such momentum that it's hard to turn it into something fresher without putting a bullet in it. Yeah, we need a little more to go on here. The advice you need is, ultimately, going to be in the form of a cost/benefit analysis. And that's going to depend on the nature of your web content, who the authors/editors are and how well they can adapt to a new CMS, etc. Those group culture issues can have as much or more to do with the viability of a change than will the decision over whether you have an extra $5k/year to woo a better coder.
Don't disappoint your bird dog. Go to the range.
then you might want to look at a platform that can be maintained over many years(use 10 years a benchmark) with|without with incremental upgrades as needed.
I recommend any one of the Unix/Linux/BSD (with a maybe on Apples Mac's) as a platform, for running Apache for web applications. There is a long dependable history there. Look for yourself...
i highlighted "When Should We Ditch Our Platform?" but IntelliSense doesn't have any suggestions
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage 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.
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.
It seems this is more of a financial decision than a technical one. Most frameworks work, and with enough expertise can work well. Sure, there's crap out there, but by and large this is a function of profit.
1) Is your company currently profitable? If not, is a significant reason for that because of the cost to maintain your applications?
2) If you are currently profitable, are your forecasts showing continued profitability?
3) Is your IT budget forecast to increase, and if so is that due primarily to increased maintenance costs? If yes to both, then maybe.
There's no easy way to know for sure. Despite my previous jab against PHP, there are plenty of successful PHP applications about there. But assuming that it was a relatively unused technology, and you were having a hard time finding PHP coders, I still think this would boil down to a financial decision. If it turns out to be IMPOSSIBLE to find developers, then train the new hires.
* Amount of code behind of old coding solution on old platform
* Amount of coding needed to be done if old platform changes to platform P.
* Is platform P supporting the features you want to keep?
* Is platform P bringing the features you want to add?
It has to be purely business decision.
I do not believe in karma. "Funny"=-6. Do good and forbid evil. Yours, Oft-Offtopic Flamebaiting Troll.
My guess is that the guy that quit was actually kind of a superstar-level developer and was doing the amount of work you'd normally get from 3+ people. So your expectations are now so high that you can't find anyone that can slot into your expectations. That's *your* problem not PHP's or slashcode's or anybody else.
If the business is making money and needs to get things done, they will just have to pony up for 3 or more people to do the job this one guy was doing before. They won't all have the exact skill set you're looking for but maybe they will have overlapping 1/2 or 1/3 of the skills each and if you actually manage the project instead of playing office politics all day you can get things whipped into shape with their help.
Don't rely on the buzzword of the month to be truly the latest and greatest. It's better to go for solid stats - a bit of Googling should help you with that. In general, it is easy to realize what frameworks you can rely on once you see the numbers - say, if you're looking at Java Web frameworks, it's immediately obvious that Struts and Spring both have plenty of skilled developers and plenty of production code based on them and running fine, and it has been that way for a few years already - so there you have it. Now compare and contrast with Ruby on Rails for an example of something on the other end of the scale.
Hire someone to assess the cost of building the application on a modern platform. That's your due diligence - finding out the time and cost of the conversion.
Whatever estimate you get in terms of time, triple that then ask yourself, can we survive feature-freezing our app for that long while we spend money converting it to the new platform? If the answer is yes, do it. If not, then you've got to struggle on.
It would really help to know what platform this is though.
So .. you can't find someone with the right 'skill set'.
... go find some smart people and let them loose. They'll take care of it.
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
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.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
First of all, ask yourself these two questions:
1. Are we missing a feature in our platform?
2. Does our platform have a bug that cannot be fixed because of lack of maintainers?
If either can be responded with a yes, then you should indeed look for a new platform. If no solid yes can be given on either, stick to what you have.
That aside, I doubt this has to do with the platform you're using. You said it took quite some time to find someone with sufficient skills. But what kind of skills are those? If those skills are all about using a certain API, you are looking for the wrong coders. It's not hard to learn using a new API. Hell, it's not hard to learn a totally new language. As long as you've programmed before and the corresponding documentation is available. Just look for a good coder, not a coder who has dealt with this certain platform before.
I know several consultants who like the strange and unconventional. Job security.
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.
We all know what to do, but we don't know how to get re-elected once we have done it
when Microsoft "embraces" the platform.
Skot Nelson music is my saviour / i was maimed by rock and roll
I'm never sure exactly how companies define this, but generally - at least in the UK - a web developer is considered the 'cog' between programmer and graphics.
Having said that, the lines are blurred.
Can't help you with your question, but if one of our programmers left, we'd be completely scuppered for a while - very proprietry inhouse systems!
A slashdotting - you get the stick first and then the carrot !
This is one of the good reasons to build a network throughout your career. (Of people, such as developers/etc. that you know, not like the intarwebs.)
Over the years you've probably met or worked with some people who either:
A) Work somewhere else, in a business with some needs similar to yours or
B) Work somewhere else, with either the technology you're considering replacing or considering replacing that technology with.
Talk to some of those people, explain what your situation roughly is, the problems you're having, and why you're thinking of switching. Asking one person can be hit or miss, but across several qualified colleagues you'll at the very least understand what several of the wrong answers to your question would be. Maybe one developer you know will have done a very similar transition last year and can warn you of the gotchas they encountered on the way.
It sounds like you did find a developer for your nameless code platform. However, I am a sole developer at a company of 400 employees. We run PHP, PERL, some proprietary guck, and Cold Fusion (I want it gone). My old co-worker used PERL for XML filtering, etc and I am motivated to learn it myself. I will be attending a PERL class soon, just so I can maintain our current code base. My main strength is PHP, so learning PERL should not be a big leap. When hiring a new person, are they motivated or lazy? Are they willing to learn a new platform? I'm willing to do it, learning PERL will help me career wise, and help my employer, and it's (sort of) fun. I said it...PERL and fun in the same sentence, joy!
Over the long haul, we are phasing out a fleet of Cold Fusion properties we run and converting over to PHP. We had vendor lock in with the Cold Fusion, hosting is expensive, and the sites are 'vintage' to say the least. So, for redesigns and recode we are porting the sites over to a heavily customized version of Joomla. For us, it is cost and maintainability to ditch Cold Fusion. However, it really pushed us over the edge when it came to redesigning the sites, we thought 'why not just build from the ground up' on these. If these were enterprise level sites that would be different, they are independent smaller newspapers.
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.
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.
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
Like Java or .NET. Avoid poo like Ruby.
It's not about having backed the wrong horse. It's about having a tool that meets your needs, and will for the short+medium term.
Since your setup sounds modest, I'd say
- stick with well-represented, run-of the mill solutions (open or proprietary 'standards'), especially if they are widely used in your industry
- don't change anything unless your concurrent system starts to perform unsatisfactorily (features, reliability, speed..), or if you KNOW it will soon be insufficient/too expensive
- keep in mind that at one point you WILL need to change/overhaul your system, and/or your Web guy will leave: keep everything well structured and well documented. This does have a cost. It's well worth it.
The Cloud - because you don't care if your apps and data are up in the air.
If the maintenance/development cost (including the cost of finding people to support it) of your current platform is higher than the cost to switch to another one, then switch. If not, then stay where you are (assuming that the current platform meets your needs, etc).
Unix is user friendly, it's just selective about who its friends are.
Pick me! I weigh less!
- think of an add "wanted: lean, mean programmers, that are worth their weight in gold"
- We pick the small ones, they cost less.
As of Postgres v6.2, time travel is no longer supported.
Deleted
If developers are hard to find because it is very old stuff, it might help to look at older candidates too.
;-)
There is still a widespread and stupid assumption that a software developer is too old at 40. If your HR guys are guilty of that, chances are that you identified the problem right there.
On the other hand, sometimes old platforms need to be ditched because they lack the capability to handle modern hardware. As an example, the company I work for still has a DOS based device in the market. It does the job but I think it is no longer a reasonable choice for the next generation:
We are almost out of DOS base memory as the code has slowly grown over the years, and modern peripherals are out due to lack of drivers.
Lonewolf, hoping that management will understand the need to put some resources into porting to a better OS
C - the footgun of programming languages
When the developers in your area all say "Ewww, I'm not touching that! That's as bad as COBOL!" That's when I knew it was time to get away from VB6.
Its key to keep evolving. New technology is more flexible. That said, stick to what the web hosts are providing. Your average web developer is going to beable to develop in a Unix environment using PHP and MySql. On the UI side, it's standard compliant CSS and Javascript. .NET and ASP seems to either a niche or enterprise solution. Technologies only compatible with with IE will be your down fall.
You can graph the trend of platforms/frameworks using job postings. For example heres rails, jsf, wicket, struts. 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.
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?)
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
(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...)
"Not an actor, but he plays one on TV."
He said all the right words to point to Ruby or ROR as the platform they chose:
.NET/LAMP/Perl/Python in terms of available production man power.
- 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
--- I'm going sane in a crazy world.
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"
- I live the greatest adventure anyone could possibly desire. - Tosk the Hunted
Rich And Stupid is not so bad as Working For Rich And Stupid.
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.
I'm out of my mind right now, but feel free to leave a message.....
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.)
Yet another victim of job security by obscurity...
If you think the platform isn't that bad, and if you think you could retain a new developer for some time, then you could look into giving the dev a few days/weeks time to catch up with the platform. If the new hire is bright enough, he might be able to be productive in short order depending on the complexity of your system. Over all it might be more efficient than switching platforms.
Of course, if you had a single dev working on an obscure, complex system with no readily available backup personnel to take over if he leaves, that's a really big problem and you should do something about it.
You were being too cheap.
I would look closely at the person you hired. Why did they take the job? Obscure or outdated technical knowledge? New to the industry and will leave in 6 months?
The Kruger Dunning explains most post on
Before switching platforms, you need to consider this can imply a costly rewrite.
... the company went into serious trouble, but we fortunately recovered through the development of new applications, which were based on a more ubiquitous platform (while porting some libraries from the original code - see http://ivan.vecerina.com/code/delphi2cpp/ .
And this can be worse than you think:
http://www.joelonsoftware.com/articles/fog0000000069.html
But yes, sometimes a platform can doom your ability to hire, when there is a very limited community community supporting it in your application domain.
I once joined a company developing 3D graphics+physics simulations, which somehow chose to use Borland Delphi as a programming platform (a Pascal dialect, quite competitive in some contexts, but not a popular choice for this type of applications).
This choice made it very difficult to hire experienced and competent graphics developers - who would dislike switching to a different language, and see it as a bad career move in a C/C++-centric industry. And I wouldn't blame them.
So what do you do then?
Switching can be a painful job
just my 2 cents worth --Ivan
okay... lets skip the anonymity. David Barber, an American from Vicksburg, Michigan who has a hobby for traveling. He is using blogger as his blogging platform... any other info we can dig up... like where he works, or what companies are near Vicksburg population: you? The answer to his question depends on what platform he is using... so what company does he work for... and what platform is it using?
When it stops maturing and starts aging, time to come up with a strategy for replacing it. Just doing it to grab the leads favorite platform is not a strategy.
I get paid 250 dollars an hour for consulting on IT strategies, let me know when you need some help.
The Kruger Dunning explains most post on
Cold Fusion.
So you waited forever to find the perfect candidate who fit into the exact same combination of language and paradigm experience to match your previous employee. Why, because you're too damn cheap to hire someone who could learn it all on the job in less time than it took for you to find the absolute perfect replacement?
Your problem isn't that your platform is outdated or difficult. Your problem is that you want everything wrapped up with a bow for you.
I don't understand the cold calls I get from recruiters/HRs wanting me to code for a platform I haven't used in eight years, because they HAVE to have someone who's done it before despite how few people actually have the experience. Well, I got that experience by learning it on the job. So can someone else. Don't be dumb, Sparky.
Terrorists can attack freedom, but only Congress can destroy it.
I would venture a guess that the "Platform" you are referring to is Linux and Apache and you were raised on Microsoft. Keep the platform, hire somebody with the skills as they are a dime a dozen and learn something.
It seems to me the trouble is with your hiring process. You're looking for someone who has used your exact setup, when you should be searching for someone who excels at programming and web development.
Within the first 6 months, a quality developer who has to learn your platform from scratch is going to be more productive than a mediocre developer who happens to have experience on that specific platform. Hiring someone with a greater variety of experiences will probably also lead to new ideas and improvements to your way of doing things.
..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.
Weaselmancer
rediculous.
Go to Google Trends, plug in your technology and its competitors. Drill down to your region and the last 12 months. If your technology doesn't show up, then you're riding a dead horse. eg., out of Fortran, Java, C#, Lisp, COBOL in Florida, Google Trends says only C# and Java are viable choices. For any who doubt the science behind this method, I offer the following trend graph as proof: Slashdot, Kuro5hin, Digg, DZone. This clearly shows that only Digg and Slashdot are viable choices.
General rule is when the cost of maintaining the current solution approaches the cost of implementing and maintaining a new solution then it's time to consider a switch. Measuring maintenance, implementation, and opportunity costs is left as an exercise to the reader.
Thats also the first platform I thought of when I read his problem. Where have all the ColdFusion developers gone?
> 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.
No, that really is just PHP developers. The norm in every other environment is to use one or two layers inbetween. And a good abstraction layer is actually faster than hitting the db directly because it acts as a cache and batches updates.
I agree that your statement is 100% correct... but it's also not as easy as you make it out to be.
Indeed, you should switch when the cost of switching is less than the cost of continuing with your current platform... but realizing that is obviously not the tricky part.
The tricky part is knowing WHEN switching costs less than continuing with the current platform. That can be a very difficult question to answer, and involves looking at many, many factors.
-Vendal Thornheart
If you're too ashamed of your platform to name it when you're posting anonymously on Slashdot, then you should switch to something you wouldn't be ashamed of naming.
My amazing wife - Artist, Author, Philosopher - Laurie M
- Revenue / company savings from applications developed internally [the more the application makes or saves your company, the more migration probably makes sense]
- Size and average salary of telent pool
- Developer turnover rate
- Cost (time) to hire replacement [resently, it has been impossible to hire good Java talent in the valley, FYI]
- Cost of stability / performance of current platform [performance and stability come into this equation. Remember, Friendster sucked because it was sloooooww as hell, before they transitioned to PHP]
- Productivity gains of new platform to current platform [this is a guess, but, I people can agree, Ruby developers are generally more productive developing web applications than a C programmer]
- Available frameworks / maturity [the newest platforms aren't the most valuable IMHO
- How long will it take to migrate [this one is key, and probably impossible to get absolutely correct. Error on the high side, and software project ALWAYS takes longer than expected IMHO]
You should be able to mush these numbers together to get a better sense if migrating makes sense. A company of mine recently changed from a Perl to a Java implementation of a client product. It turned out to be the right call for many reasons: performance, talent pool, maintainability, available libraries, and client perception [a lot of people think a Java application is more "enterprise ready" than a Perl one] All that said, also consider:- Can you migrate to the new platform piecemeal [if you have 1 developer, you don't wan to lose all his time while he migrates your platform]
- You WILL have bugs [and probably the same bugs you worked out when you implemented the system the first time]
- Web Services, XML, and other standards that allow different code to talk to eachother is probably going to be your friend during this migration
Good luck! Hope this helped!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.
Like all pain, suffering is a signal that something isn't right
It isn't just the cost. You also have to consider the benefits and risks.
The decision to replace an aging software system is a business decision, driven by the numbers. When the (benefit - cost) of the new system exceed the (benefit - cost) of continuing the old system, then it's time to buy the new system. If both are negative, it's time to just shut it down. Part of the cost of the old system is the people you need to keep it running. If it requires unusual skills or high levels of expertise, those might be expensive people. If it requires lots of labor to maintain and operate, then the total payroll might be large even if the individuals are not expensive. Part of the cost of any new system also includes the people you need, both to implement it and to keep it running afterward. Business opportunity and business risk also must be estimated for each alternative. The list of costs and benefits might be extensive, and some of those numbers might be guesses, but ultimately the numbers will make the decision.
The manager who cries about not being able to find good people really just doesn't want to pay for them. There are plenty of highly skilled people in the world. But, the low bidder doesn't generally win the auction.
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.
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
The time to change is when the ROI goes negative. When it costs more to maintain the system than you will make from the system, it is time to scrap the system.
If the cost of changing the platform is less than the cost of maintaining the current platform.
And, really you shouldn't wait that long. If the cost of maintaining the current system is projected to continuously go up, you should be looking at biting the bullet and working to change platforms.
By projecting costs out a few years, you should be able to tell where it becomes more cost effective to change platforms.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
This is speaking from personal experience as a manager/CTO type that has worked on small and large scale web based projects in several cities in the US. Learn what resources you have in your area before choosing a platform/language.
I've found the north east and north west have an abundance of Microsoft platform people, Silicon Valley has a lot of Java and PHP people, Chicago has a good mix of MS Platform and PHP, and the southern end of California has a lot of Java but PHP devs seemed impossible to find.
Doesn't seem to matter where I go, PERL people are nigh impossible to find, but I know they're out there (in a basement somewhere?).
- I voted for Nintendo and against Bush
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...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
At the time I'm writing this, there are only 11 posts rated 4 or 5. That seems like a weak response. So I'll chime in.
Perl and Cold Fusion are languages that once were really hot & useful for the Web, but nowadays are not as prevalent. The languages still exist, people still make money off that skill set. However, the Web-based jobs for those are shrinking, while other languages are growing. This is just pie-chart stuff -- what's shrinking, what's getting bigger?
In such a case, you know you're running out of developers when you're running out of developers. (Oops! This may have happened to you already!)
Of course it's possible that a platform/system/language is so hot that all the developers are picked up, and your trouble stems from its success, rather than its failure. If that's the case, you should know it. You should see clearly that there are tons of job openings in that area, and everyone you call is interested but simply making more money elsewhere. It's very different from having people flee because your development environment makes them queasy. If success really is the problem you're facing, then you simply have unrealistic expectations. You expect top-notch work for bottom dollar. You offer no perks and/or no incentives for employee retention. If that's the case, then you're simply suffering the consequences of your decisions. Pay better, offer more perks, or live with it.
Assuming success is not the problem, you really are finding yourself in a dead-end. So now the true question is, "I know I have to change, but will it hurt?" The answer is, "Yeah, it's gonna hurt, but not as much as remaining at a standstill."
So find out where the developers are, and learn to entice them better. Find the big communities, communicate not only your needs but WHY a developer should choose your company over all the others. Then hire well, and then set them on the project. Good developers really can build things competently, and to a deadline. They may drop a feature or three as they march to the deadline, but they'll deliver a working system. Specify what you want, give them the lame-but-working system as a template to improve upon, and let them go for it. If you hired well, things will get done and your pain will diminish.
Now, as to the question, "How do I hire well?" I can only say, search Slashdot. That question has been asked repeatedly. Good luck.
My Greasemonkey scripts for Digg &
I know that a lot of people have been saying, "When the cost of maintaining it exceeds the cost of replacing it." That's nice and they're absolutely correct, but it may be helpful to have a few guidelines when trying to decide if you have reached that point.
A) How much money does it cost to hire someone skilled with the platform? How long does it take to find someone qualified?
B) How much money does it cost to train someone to become skilled with the platform? How long?
C) How easy is the platform to work with? Can changes be made easily? How easy is it to test changes?
D) How good is the support? Even free platforms can have good support. Think more in terms of "time to find an answer" if it helps. Obscure and old platforms can be a pain to maintain, because there is often a smaller community.
E) What is the cost (in time) to build your application/site in the new platform? Does this exceed the cost of bug squashing with the current platform?
F) If your developers are constantly having problems - is it really the platform, or do you have crappy developers? Usually it is the latter.
G) Are your developers going to be developing the new platform? If so, get new ones. In most circumstances, there is an existing platform than can be used or modified, saving tons of time in development and testing costs.
Hope that helps.
Love sees no species.
"What's making him think of switching platforms? "
/. decries so much with Microsoft, except the vendor happens to be their Web Developer.
He gave the answer to this question in the summary.
"It took us an extremely long time to find someone with the necessary skill set."
This can be unacceptable in just about any organization. Depending upon the definition of "extremely long time", which can vary from organization to organization, this is unacceptable. Most places want easily pluggable modules for positions, so that retirement, death, transfer or quitting doesn't break the organization.
This is the equivelent of "vendor lock in" that
There is an unacceptability in being held hostage to a singular developer. At this point, I usually recommend switching to one of the various CMS setups available. It is much easier to find people able to tweak and update using one of the available CMSes, than some proprietary hack that has less features and no other developers.
While this advice is not universal, it most likely would fit the kind of shop that has a single Web Developer on staff (or contract).
This is based upon the general problem presented, the general details, and my understaning of what is available in the market.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
rage, rage against the dying of the light
First of all, always assume Fate is against you; or at least that it's not a very reliable friend.
Secondly, now might be a good time to think about changing platforms; maybe not today; maybe not the day after you hire the new guy; but soon after.
My own experience is that the worst thing you can do his hire somebody bad. The best thing you can do is hire somebody good. If you're lucky you'll find somebody good who knows this oddball platform, but Fate probably doesn't have that in the cards for you.
Put this all together, I'd say look for the best person you can. That person should (a) know several well known platforms and (b) be smart enough to be able to handle any fires that erupt on your current platform, even though he doesn't know it very well. Then see what he makes of the existing code on the current platform. He should be able to put together a strategy either or maintaining the current software, or transitioning over to a new platform.
In no case should you hire somebody you don't feel is really good, just because he knows the platform. You might be letting him go in a year, but find yourself in an even deeper hole.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
I routinely coded network apps in JDK 1.1 that ran in 256K memory - including the JVM (no jit). That's K, not M. In comparison, the later Javas are stuffed turkeys. Even J2ME needs 512K. The two things that finally made Java 2 usable were the precompiled classlib for reasonable startup, and the fact that memory is now measured in Gigs instead of Megs.
Cold Fusion I presume?
Easy answer: both keep the old platform and get a new environment. I converted a massive app in Progress's Fourth Generation Language (Clearly from the pre-Google era) into PHP/Postgres using Antlr. This allows modern tools and programmers, but still carries forward the thousands of undocumented changes and mystery quirks that the customers have come to know and love.
What aspect of the platform is not working? Is this a content management system/portal issue, a programming language issue, an OS issue, an issue with a large special-purpose application, or something else entirely?
Is there an option to gradually phase out problematic code on the existing platform?
From a Venture Capitalist PoV - Never! Unless you gain something out of it (A competitive advantage, reduced cost, etc.) From a Dev PoV - If everytime you need to make a change you dread it because it means many sleepless night debugging some archaic code, you need to refactor the whole thing (Which may involve complete re-write if everything is so badly designed) From a QA PoV - Right on! More stuff to test, re-write every week! From a Management PoV - Somewhere between those lines, you will find your answer.
If you ditch your current platform, you are ditching the implementation, not the feature set right? If that is true, then the right answer is to ditch your current platform AFTER you've written (and implemented) test cases against it. This will ensure that the existing functionality is preserved on the new platform.
The question is then what platform is are the test cases in? This should be answered as "the same as the proposed new platform." This provides a warm-up period for developers and creates a good playground to work out kinks before you even switch for real. (Leaving plenty of opportunity to back out!)
Be warned: implementing in a new platform is rarely worth it. What are you expecting to achieve in the new platform? If it is just ability to fill developer chairs, then it is most likely not worth it. If those developers are being required for product growth, then you might have something. But for maintenance, get a consultant. You'll have way less headaches.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Well, typically when you start wondering and come up with questions like these there probably are already things that make you wonder. Maybe you can't exactly pin point the issues yet (although you had one or two already) but basically you already started the process already by wondering if you should ditch it.. You know that something is wrong. It has been around for a while. Not too many people are smiling anymore, problems finding people that can work on it etc etc.
I've worked in various companies who have migrated platforms for various reasons.
...just something to consider before scrapping an application, or entire platform, due to 'talent shortage'. Chances are, you're simply not looking in the right places to find the right people, imo.
I'll use 1 former employer as an example here...
This organization had taken-over another organization that had biology and computer science students and PHD graduates develop an application using X platform, for over 6 years. This application was rock-solid, covered all the requirements, but the CIO who was in charge of the take-over, had no skill or understanding of the platform it was developed on.
Instead of keeping the developers and enhancing this existing application, they decided it was cheaper to let them go, hire a whole team of (Y platform) developers, and begin to re-create the application in the new ("latest and greatest") platform.
When I started, the organization had been in this process for about 4 years, and still had yet to fully re-create the application that was originally developed on X platform (which they hired me to now maintain), and 2.5 years later when I left, they still hadn't made much progress. This was 6+ years, 30+ employees, and $20m+ (tax payer) dollars later. The original app could have easily been updated and maintained by 3-4 'skilled' X platform professionals, rather than 30+ not-so-skilled Y platform professionals, and would have saved at least $15m in expenses (of tax-payer funds).
Part of the motivation behind such ineffective decision making:
1) The justification to secure ridiculous amounts of funding so the CIO could pad his pocket
2) The inexperience in dealing with X platform
3) The false notion that hiring 30 Y platform developers to reinvent the wheel would be cheaper than hiring 5+ (harder to find, but far more skilled) X platform developers to simply wax the rims.
the only permanence in existence, is the impermanence of existence.
I figured they went with an antiquated webapp, and since most people can handle PERL, the likeliest candidate was Cold Fusion, which no one really practices/knows anymore.
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.
Vee have vays of making you talk!
Seriously it depends on what your company does. The platform you select for building...say Slashdot or Digg...would be different than the platform you'd select for spinning out internal sites for a different kind of business. Assuming you're not building a high volume web entertainment site, then speed and time to market are big considerations. You want a platform that's fast to develop and easy to maintain. There are only three platforms I'd use for building integrated systems to support medium to large companies that need sites stood up quickly to support different business units:
LAMP - Specifically PHP. If you need additional capacity, you just stand it up. No licensing hassles, no purchase requisitions, and support is pretty easy to find. All my own sites are built on a LAMP stack.
ColdFusion - Hard to beat for time to market. I have CF sites going on seven, eight years old that are still carrying a load and, once they're stable, hardly ever need updating. ColdFusion runs on Windows or Linux servers and the license costs are still fairly reasonable. It can be hard to find CF developers.
.NET - Though let me say .NET is the least favorite platform that I support. Keeping a .NET site stable is a pain in the ass. Security patches will cause things to stop working unexpectedly and MS keeps you on their upgrade treadmill. I had one customer that paid for upgrading the same application from 1.1 to 2.0, or you have to maintain both environments. I hate their kludgy, GUI-driven development environment, which I consider FrontPage on steroids. But if you run a MS environment and SQL Server, .NET does offer some advantages. It does web services really well, integrates with many portal products and it's generally pretty easy to find support. Hard core NBMers will argue that .NET is faster to develop sites but that's a big, fat lie. It's faster to develop half-functional prototypes, but fully tested systems it's slower and tracking down problems can be really, really time consuming.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Deciding on or changing a platform is fairly complex. Without knowing more about your particulars, all I can write about are general ideas. While they may be helpful, you will have to customize them to fit your organization and situation.
Since you've not really framed the technical particulars of your problem, I'm going to treat the system as a black box. The question then becomes, "how do you know when to change black boxes?"
I'll break up the ideas into three sections. Tnn will represent technical considerations, Bnn will represent business considerations, and Cnn will represent cultural considerations.
T1 - Standards Compliance
Are there openly developed, freely available industry-wide standards that your black box should implement? If so, does your current black box implement them? If your current black box does not implement them, or depends on proprietary extensions for the bulk of its interesting functionality, then it's time to look at a new black box. If your black box implements the standards but does not closely (6 months - 18 months) track significant changes to those standards, it's time to get a new black box.
T2 - Brittleness
Tight coupling or brittleness is a good reason to change your black box. I'm using this term in an object-oriented design pattern sense. If you change your black box (upgrade, improve, etc.), how many other systems do you have to change? Adding new functionality to other systems might be acceptable coupling. Changing an operating system to change a browser so you can interact with a server is probably not acceptable. If you find yourself in the second situation, then it's time to change your black box.
B1 - Support
Support can come in the form of in-house (hired), in-house (trained), community, consultants, or vendor. Sometimes finding and hiring people with the specific skill set is difficult. Consider hiring someone with experience in a similar skill set and then training that person through vendor or third-party classes. You can bridge immediate skill issues by using consultants, but make sure you get a complete knowledge transfer. If the classes don't exist, the consultants are sparce, the community for this black box not vibrant, or newer technologies are seen as replacing your black box, it's time to get a new black box.
B2 - Repair or Replace
This is the basic used car / new car question. If it's going to be very expensive (project costs, retraining costs) to replace your black box and you can find or train a suitable mechanic, then your black box has a little life left in it. If over the course of 18 months (single process black box) to 36 months (infrastructure black box), the repair bill will be larger than the project bill plus any new repair bills, it's time to get a new black box. Adjust your time frames according to your business model.
B3 - Fitness for Purpose
Does your black box sit in the corner, doing its job, and rarely needs a change? Then it might be a good idea to leave your black box in place until its brittleness impacts your business's requirements to innovate or change. If you are constantly having to rework business processes or projects to fit the idiosyncrasies, then it's time to replace the black box.
C1 - Change
Every business has a certain resistance to change. This must be factored in when you replace black boxes. A change-adverse organization might be more comfortable in living with the restrictions of the current black box. A change-neutral or a change-positive organization might actually benefit from changing the black box. The impacts of change are hard to measure, but mostly show up as soft dollar costs in productivity and team morale. Sometimes even change-adverse organizations must change their black boxes. However, in order to accomplish that change, an influential sponsor / stakeholder must lead the charge. Otherwise the change will fail.
That was a rather long first draft of my opinions about deciding on change in a business environment. Hopefully some people will find this useful as a place to start when considering change.
I look at the popularity of a development platform.
.. that being said, it also offers tools that show trends in industry based on what jobs are posted and the key words associated with them.
indeed.com is the greatest job search engine on earth. It polls data from loads of other job sites and compiles the information in one place
So, if I look at some trending data like this:
http://www.indeed.com/jobtrends?q=jsp%2C+cgi%2C+asp%2C+php&l=
I can determine which platforms are popular and which ones aren't. That information will also tell me which ones are more supported. The more jobs that are offered in a technology, the more people there are to support it. It's all market driven.
For Instance
http://www.indeed.com/jobtrends?q=java%2Cdelphi%2C+perl&l=
shows me that there are a tone of java positions out there, and very few delphi positions available. While Delphi may be great, you're going to have a difficult time finding someone to support it. It also tells me that Java is probably a better development language as a whole (*waits for flames from the delphi community*), because more people are using it. People tend to use good technologies.
err... he said an abstraction layer.
An abstraction layer does not need to criple anything. It can be as simple as calling a stored procedure on the SQL server. Oh wait.... MySQL doesn't do that... NOW THAT is what I call crippling!
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.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
Asking end-users if they're complying with regulatory requirements is not a sufficient test of regulatory compliance.
We can't you just ask "Do you have XYZ installed?" You have to sneak onto my computer with your uber-tool and spy for regulatory compliance? And for *THAT* reason we must run windows... so we can use a spying-tool. PARANOID.
Balmer appreciates whoever wrote that rule about regulatory compliance. It's a windows only one! Mwhahahahahaha
Balmer is wetting his pants. Lets hope his mood doesn't swing because I don't want to get hit by some urine covered chair.
Like all pain, suffering is a signal that something isn't right
By the tone of the question, it appears that the requestor has a Linux/FLOSS type solution, and is wondering if he should go ".net" or something. (though I could be wrong).
If you pull in the M$ A+ certified class, of course they will tell you it's easier to maintain and works better than Linux and Open solutions.
Actions speak louder than words though.. In a group of 100 A+ graduates, you may have one that actually knows what a HTML TAG is, and the rest know what "Front Page" and "Office" are.
Here is a question for you: Were you really not able to find anyone with the skill set? or just did not want to pay what they were asking to support your legacy application?
The reason I ask that, is that FLOSS is a very large community, full of talent and skill. I find it hard to believe you could find "no one" to support your stuff.. unless you were looking for the lowest end pay scale to match.
-The wise argue that there are few absolutes, the fool argues that there are no probabilities.
Incidentally, I can code you a new one for $250/hr.
http://www.coderoshi.com/
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.
The more I learn about science, the more my faith in God increases.
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.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
Just because you have an abstraction layer, doesn't mean that you can have a pass-through for limited cases where it's better to use a DBMS specific feature.
I've never personally used ruby on rails and never intend on it. I've seen fads like it before. Your question was that of platform for web apps and when to jump ship. I believe web applications should be platform independent ( so jump ship now ). The best web applications (custom or stock) on the net with the lowest cost for maintenance are currently PHP applications. PHP+Apache+MySQL is a favorite combo of web developers and it's widely used and supported. The software is free and the community supporting those apps is huge. You can install those three pieces of software on any platform so no need for a pre nup.
This question plays into simular territory that one that came just a week ago. 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.
.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)
.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.
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
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
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?
We suffer more in our imagination than in reality. - Seneca
Here's a problem I've seen time and time again:
1. Hot-shot long-tenured developer takes a hike for a higher-paying job (but that's not what he tells you)
2. Company goes headhunting for a turn-key hot-shot long-tenured developer to replace #1.
3. Months pass without any hopefuls, Company blames everything under the sun.
4. Company dies a slow torturous death.
The biggest problem is that most veteran developers aren't mobile. You used to have the one guy who knew and did everything under your roof. He's gone, and no one else has that same skill set, not until they've worked with you for a decade.
The other big mistake small businesses make is they think merely putting out job listings with all the staffing agencies will magically bring geniuses to their doorstep. Bzzt! Wrong! The one thing they will magically bring is more students, slackers and foreigners than you can count. There are lots of people looking for work, and lots of jobs looking for people to do them, but both parties tend to wait around expecting the other party to do all the legwork.
It's never easy to replace a veteran in any field, not just programmers. If you can't find the perfect candidate, maybe you'll have an easier time hiring two people with limited but complementary skill sets, e.g. a data guru and a code monkey. Depending on the business, maybe you could even do without a staff developer for a while by relaying some of the work to a consulting firm.
-Billco, Fnarg.com
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.
Blar.
That's an excellent answer. I'll attempt to give a more concrete answer although without details it is still too abstract.
If the selling point of your company is it's content then use whatever mainstream platform you like. If your platform is already mainstream stick with it. Some mainstream platforms:
ASP.NET. Older versions of ASP are too troublesome and deprecated so they aren't mainstream anymore)
Java. I wouldn't recommend it for new developments but it's not so bad that it needs to be ditched.
PHP. Maximum flexibility, performance, availability of expertise with near the best speed of adaptation to change.
Ruby on Rails. It has survived the hype and it's on the way to become mainstream, is easy to pick up if you are new and has the best speed of adaptation to change.
Soon you will see Air/Flex here but it is still too new and untested. I'd go for Turbogears or Django but I'm a Python fan.
If the selling point of your company is in it's service/software or at least it is an important part of it then the answer depends on you market position.
If you are the market leader or if you market share is increasing, stick with what you have.
If you are at the tail of the food chain or your market share is decreasing and it can be traced back to a software issue, switch to a mainstream platform, Chances are that a novel platform will be more of a hindrance to you than an advantage.
Finally if you are an at average point of the continuum and your market share is more or less stable you are in a good position to start experimenting listen to you developers here. If they complain about the limitations of the platform or are very exited about some new tool let them start small projects with it and if it works go for it.
But it seems you don't have any developers right now, then try to remember what the last developer used to feel about the system. If he/she felt good about the system keep it. Even if developers for this platform are rare they are probably exceptionally talented people and more than make for it.
If the last developer felt limited or dragged by the system then it depends. If the current platform is not mainstream switch to a mainstream one. If the current platform is mainstream then the rules above apply.
I'm done doing your job, back to mine...
But... the future refused to change.
At my company we just decided to resurrect an old application even though nobody knows how to operate/program for it anymore. Simply because putting a Jr developer on it and letting him/her figure it out is cheaper than the new shinny powerful solutions now being sold. (In fact its costs 4 months of his salary)
Thats what it all comes down to around here, which does the boss think will be cheaper.
A well designed abstraction layer should generally be able to take platform specific features into account and use them transparently if available. Of course, that takes a very sophisticated layer, and requires a lot of forethought and design before starting to work on it. Seems to me, though, that that's what makes the difference between an actual abstraction layer and just a simple code wrapper. Of course, it depends on the feature how easy (or nightmarishly difficult) it is to elegantly wrap it up in a transparent manner.
Well, that's my experience at least.
I recently had to help a client who based his web site on the Drupal Content Management System but then couldn't find a developer to finish the site after the original one stopped answering calls. There's a small but very active and vocal Drupal developer community here in Buenos Aires, but it's an error to assume that it's possible to find a developer based on the tool being popular, open source and quite easy to use.
... yet, Drupal evangelists make it sound like a no-issue... and it's not much different from getting a developer to mantain your propietary platform. In fact, I think the problem is based on looking for Drupal developers instead of looking for good PHP developers who could probably figure out Drupal in a weekend. Same for anyone using Ruby on Rails and looking for experienced RoR developers instead of an eager "cowboy programmer" who's willing to save the day.
To be fair, had the client not used Drupal and gone with a propietary PHP solution, the results would have probably been much worse... since the code would have been harder to modify, and the result would probably have less features, be less secure, not based on standards and good practices, and decent PHP coders are not THAT easy to come by.
As a Slashdot discussion grows longer, the probability of an analogy involving cars approaches one.
You have completely the wrong focus here. Hire someone with a broad range of experience across multiple platforms, languages and a generally open mind. Then ask them to help evaluate the system and whether you should migrate off it or not.
No. Web programming should be treated like all other programming, which means your abstraction layer should be properly encapsulated such that it is trivial to replace one implementation with another. If your current implementation of the abstraction layer does not support feature X, build it into the abstraction layer itself. At worst, you will have to find/replace calls to the function to add extra parameters to support the functionality where needed.
If you need to switch your DBMS from MySQL to Oracle, you just create a new implementation of the abstraction layer, from the stock version (yes you should start with a platform nonspecific version), and then add any Oracle specific stuff to the new implementation. The only caveat is that your stock abstraction layer have a standardized API that your client code can call.
The big problem with web programming is that developers are not following the basic tenets of computer science. They are writing tightly coupled code, instead of implementing basic programming paradigms (like OOP). This is not limited to database abstraction. You should always have your technologies properly separated, standards compliant (wherever possible), and your functionality encapsulated. If you do so, even a full platform switch is an achievable goal. And yes, my company spends 99% of their time implementing (and fixing other people's bad implementations) web based systems.
Firstly, backing the right horse comes with time and experience. The more people you have to feed into that decision, the more likely you'll get the right horse. This makes it easier for larger IT shops than small businesses.
However, larger enterprises also plan their IT investments. We provide strategic outlooks for key technologies over 5 years but also ensure everything goes through a Technical Architect. I have 20 years of technical experience in every aspect of IT and would like to think that I've never put any client on the wrong horse.
If Gartner says it's good, Forrester says it's good and the storage, network, database and server people says it's good we'll go with it. Otherwise, it's a risk and that is factored into the decision-making process.
If you do back the wrong horse and it's not heading in the right direction, jump off. The longer you leave it, the more painful it will be. All you should be thinking about now is damage limitation.
So try to plan, to be strategic and think about the long-term viability and sustainability. Review your decisions frequently and decide when to transition. You shouldn't wake up one day to find your decision was completely wrong, it takes time for these things to become apparent, review them when the first hiccup appears. It will save you a lot of grief and may even save your job, if you're the line manager.
Roll a d20 and consult the correct chart.
Also I think you should probably migrate to [Untitled product] due to better [features list]
I hope I've helped you as much as you've helped us understand your issue.
It was Drupal wasn't it?
Also, it's the difference between the old-fashioned table/row locks, and the newer MVCC/snapshots, which often bite you in the ass when switching database backends. A reasonably complex application written for one model simply cannot be easily ported to another.
Django comes with an adequate abstraction layer, right out of the box. It also comes with a URL mapping layer, so you could send some URLs to a legacy system and handle some with Django.
And I love Python.
Django for the win.
I think it's probably a terminology issue, but if a web developer came to me and said "I'm going to write a database abstraction layer for this website in case we want to switch databases one day", I would smack them round the head. It's a clear violation of the YAGNI principle - significantly extra work for something that probably won't ever be required.
On the other hand, I suspect you're not talking about a full-blown database abstraction layer, just a separation of data access code from business logic (like a Repository pattern). This I would view as simply good design, with more realistic benefits like easier testing, more understandable code, and better separation of concerns.
This sig is false.
It's great job security. Besides, haven't you been wanting to do something about that crappy code?
The thing that was cool about the
One thing that wasn't cool about the
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Even though we pay almost 60,000$ per month per LPAR we are still writing new applications to run on i-series. I told the team that is building it to do the math. You will have to fire yourself when we put it into production to pay for it. At least ibm is pricing themselves out of the marketplace by getting their final supporters whacked.
Really? I certainly wouldn't react that harshly. Fact is, its quite difficult to tell where your application is going to be headed in a couple of years, and a little bit of forethought can save a lot of hard work later on. Granted, I'd probably refuse the developer too, but I'd probably have to think about it first. I'd see what the chances are of having to incorporate this feature, and I'd try to do an informal cost-benefit analysis before shooting him down.
However, this might be because the application I worked on at my last job was written for Oracle, and our client was moving to MS-SQL and wanted our app to comply with the new database. Because the application wasn't designed with that sort of portability in mind, the refactoring was a lot harder than it ought to have been.
On the other hand, I suspect you're not talking about a full-blown database abstraction layer, just a separation of data access code from business logic (like a Repository pattern). This I would view as simply good design, with more realistic benefits like easier testing, more understandable code, and better separation of concerns.That is what I was talking about, but that doesn't mean that you should rule out a full abstraction layer offhand.
We all know what to do, but we don't know how to get re-elected once we have done it
Back it up?
It's possible to create great apps with just about any platform, and it's easy to create crappy ones. So I don't think you can quickly come to the solution by comparing the merits of the competing platforms themselves. That's been a painful lesson for me as well, since one of my favorite platforms lacks sufficient market support.
So if you're platform agnostic you can start from the supply of developers. An earlier reply recommended hitting monster.com or equivalent for some market research. That will not only give you some idea of what your new guys will cost you; it will also help your company put a dollar cost on keeping the existing platform versus deploying a new one.
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.
We do not inherit the Earth from our parents. We borrow it from our children.
From my point of view it simple anyways.
Go to the nearest job-search web site and search for your platform. then search for the current modern platforms (dot net and j2ee or whatever) and see what the results are like, if your job advert was the only result for your platform, you should be probably looking to switch platforms.
Thats a very broad brush approach, but at least it gives some idea of the general popularity.
I don't disagree with your statements, but... I get the sense that PHP is popular in the Internet start-up world because it's fast to prototype in and easier on the brain than other options. Most start-ups, from what I have seen, are interested in one thing: fast time to market, damn the consequences of not planning for scalability, porting, etc. I think they figure those are bridges they can cross IF they ever come to them.
I have built applications in Java, XSL/T, PHP, Perl, C, and countless other languages for numerous start-up companies and, no matter what my word of caution in terms of future planning, 9 times out of 10, the boss is insistent on a minimally functional proof-of-concept that gets migrated to the production environment without any further consideration. They don't care because it doesn't translate to revenue right now which is crucial for a business operating on angel funding.
I do see your point: put in the effort where its needed and only where its needed.
But then in tweleve months when you decide that paying for Oracle 9 is way too much and "Can't we just use MySQL instead - its significantly cheaper" I'd smack you around the head and say "Fat chance, we ain't every changing from Oracle. Suck it up like a big boy!" Agile code and agile technologies can be crippled buy non-agile businesses. Vendor lockin requires effort to be avoided, not much, but often much more than the quickest, cheapest, what-we-want-for-this-month-only business philosophy so prevalent in the real world.
We do not inherit the Earth from our parents. We borrow it from our children.
Tell your boss not to be so damn cheap. (and ask for a raise yourself)
Web developers are not exactly a rare breed, regardless of platform.
If you can read this... 01110101 01110010 00100000 01100001 00100000 01100111 01100101 01100101 01101011
Clean, well-separated code should be able to be ported to a new database platform at least three times before it starts to approach the break-even point that would have made building your own general purpose database abstraction layer worthwhile. This is the sort of false economy that you commonly find rearing its head with developers who are attempting to solve problems that don't exist yet.
If avoiding vendor lock-in is such an important requirement, it would generally be cheaper to buy a database abstraction framework (or, thinking outside the box here, sticking to standard SQL) rather than attempting to roll your own. However, in practice I think vendor lock-in on the database platform is less of a concern than vendor/technology lock-in on your web application framework, so to my mind it's questionable that you're getting a great deal of value by going down this path.
This sig is false.
sorry to say, but if you are not smart enough to pick the gems out of the mud your not worth you salt and should stick to developing "web applications". sorry, it just is that way. ever heard of wicket? no xml whatsoever. ever heard of ejb3? no xml whatsoever. ever heard of integration? like, with what the real (banking) world runs (and i'm not speaking of FIX)? mainframes and stuff? good luck with your python when it comes to qa and reliable long running transactions involving asynchronous communications plus friggin tight security. there actually IS a world outside the crud department, and for this world the word enterprise is used, rightly so. goddammit, you ruby/ python/ fotm guys do your nice lamp applications, play with web2.0 and what not, have fun, and be quiet.
On second thought, let's not go to Camelot. It is a silly place.
I has a summer job in college doing programming on an IBM System/34
;-)
If that's not a typo, perhaps a summer class in English would have done you more good
There are several reasons why current web programming skip the abstraction layer. A lot of web programmers think that MySQL is a RDBMS and that is all they program again. They also think that PHP is a real language. Finally they need it to run on their $5.99 a month value hosting account that they expect to build the next myspace on.
BTW, can you tell them how to make the next myspace on that shared server? Can it be installed with fantastico?
Even if they have actually worked with another DB server, they still wouldn't know what an abstraction layer is. If they managed to use an abstraction layer with their web app, the site performance would slow to a crawl because of the performance hit the abstraction layer incurrs. Not that it would matter in the end because their site is going to crash with a few concurrent requests.
Oh and before you MySQL and PHP defenders pipe up, MySQL with it's default install still isn't ACID compliant and is a stinking POS. PHP may be a language but barely. Any high level programming language that lets you declare variables on the fly and without a datatype is just plain stupid. And when's the last time you didn't get the result you expected because you had a typo in the variable name?
blincoln: I didn't know Lil Jon worked in the tech industry. I suddenly feel the need to crunk-enable all of my servers.
Lil John: Whaaat?
blincoln: I didn't know Lil Jon worked in the tech industry. I suddenly feel the need to crunk-enable all of my servers.
blincoln: I didn't know Lil Jon worked in the tech industry. I suddenly feel the need to crunk-enable all of my servers.Lil John: Whaaat?
Lil John: Whaaat?
blincoln: I didn't know Lil Jon worked in the tech industry. I suddenly feel the need to crunk-enable all of my servers.
Lil John: YEEEEAAAAAAH!
So does Anonymous Coward have good karma?
You may have been making a common mistake and listing your dream list of specific requirements for your next web developer which means that you narrowed your possible applicant pool down to 1, the developer that just left. Eventually you were able to find one that fit most of the requirements and hired that person.
Even if you were able to find someone that met all your requirements, that person would still need some time to get up to speed at your company because every environment is different. A good developer would be able to get up to speed at your company almost as quickly, maybe quicker if the person you did hire fulfilled the requirements but wasn't very good.
Hire the person that can best help your company in regards to the role you need them to fill, not the person that matches your punchlist of requirements the best. And how do you know when to ditch your platform? When it cannot fulfill your technical needs. When its product roadmap shows that it will not fill your technical needs in the near future. When the cost of continuing with the platform becomes prohibitive, etc.
Basically when the risks of staying with the platform are greater than the risks involved with moving to a new platform. I use risk as an inclusive term, it may mean costs, it may mean security, it may mean technical, etc.
The costs and risks of changing platforms depends on what you are using it for, your organizations actual code base, what you are switching to, etc.
Oh and paying for some expertise to help you decide based on examing your actual web platform, application, code and such might be better than asking slashdot a vague question with minimal information. Call me crazy...
"We should do the next project in Rails."
"Nonsense, we only have one engineer who knows Rails and would need ten."
"Hire them."
"Nonsense, they make 20% more than you do."
"I guess I should be doing Rails elsewhere, then."
Help poke pirates in the eyepatch, arr.
It is very difficult to give advice as you don't really say what your infrastructure is, but I would start by looking at how common your platform is and whether its use is increasing or decreasing. If it is increasing fast there could be a lag between people becoming trained in the technology and demand, but long term it could still be a good option. If it is decreasing then people might see it as a "dead end" technology, and not actively look for work in the area.
Also, try to find other companies who use the same technology, or have switched from it recently. See what their experiences are. Look at other possible reasons, are the salaries you are offering competitive, does the area you are in make recruitment difficult, etc.
OK.
bzzt! Illegal use of "more good".
His use of "more good" in this case is entirely legal English, perhaps you should book yourself in for a course too.
Oh, this is a result from Computer Science? So where's the experimental data that proves that this is the correct way of doing things? (I have this funny idea that dogamatic recitations of theory and vague anecdotal evidence isn't really what "science" is about.)
Even if I grant the importance of some form of encapsulation in the design of a software project -- which of course I do -- it does not follow that the right place to draw one of the boundaries is at the "database abstraction layer".
According to my experimental data, there's a high probably that you will get fucked by your database vendor first.
Not quite "science", but an objective study of development projects could very likely prove the value in a database abstraction layer.
Business. Numbers. Money. People. Computer World.
I think its syntax is butt-ugly, but its functionality is great. Maybe next time around I would use lua, but I'm not sure. What's awesome about Tcl is that while communicating with our equipment, I could create procedures on the fly for doing some things:
This kind of flexibility is awesome.So be nice to Tcl :-)
http://twitter.com/odoketa/statuses/497676232/
BTW, that platform was my first guess...
Let me summarize what the GP post meant:
"I am a programmer, I am your all mighty God, bow at me you simple mortals. I deserve all your admiration and respect".
I always find it funny how codemonkeys think so much of themseleves.
Yeah, and as you said, Watch them mod me way down to Uranus to see what I mean.
Ubuntu is an African word meaning 'I can't configure Debian'
Sorry, Matt!
-- @rjamestaylor on Ello
Let me summarize what the GP post meant:
... And there goes this lunch-breaks slashdot post.
"I am a programmer, I am your all mighty God, bow at me you simple mortals. I deserve all your admiration and respect".
I always find it funny how codemonkeys think so much of themseleves.
If you read carefully - which you evidently haven't - you'll see I didn't mean any of that at all. Curiously enough, it's "code monkeys" (I presume you're refering to regular programmers as opposed to lead programmers) that need a functioning enviroment to make any sense of their type of work. If a project lead *and* a working enviroment aren't in place a "code monkey" is less that worthless.
When the questioneer says he had to replaces their one (!) developer and had a difficult time in doing so it goes to show that exactly that kind of enviroment isn't in place. An issue which I stressed in the parent reply allready. Which in turn goes to show that you a) didn't read or understand the the situation the questioner described and b) didn't really fathom my reply or actually know squat about what it refers to.
Which leads to the question of wether you are the kind of guy who has a little agency-type shop and hands out assignments to code to what he refers to as "code monkeys" (maybe simular to the one of the questioner, who knows?) or if you are just a poser. Given you style of reply and the simple fact that you posted it I suspect the latter. *Bingo!* , correct?
We suffer more in our imagination than in reality. - Seneca
Rails is perhaps the biggest at the moment. Thousands of people are blogging/twittering about Rails. In reality, almost nobody is running a commercial app on it (except Twitter and the 37signals stuff).
Java and c# people mostly don't go making a lot of noise, yet there are far more of them around.
And experience does matter. Sure, I could pick up and start coding Java quite quickly, but I wouldn't have the in-depth experience that comes with use.
...it's infested by Randomly Puking Garbage II, III, IV, or MCMLXVII for that matter....
(spine shivers at memory of days spent doing what could even then be accomplished in a morning of COBOL, ALGOL or PL/I)
In my day, we shot rubber bands at the switches on the front panel. Much later, I remember the joyous transition to the IBM 029 keypunch (which would actually print the characters at the top of the column in which they were encoded) from the 026 (which didn't have such modern convenience or frippery, depending on your viewpoint). That effectively ended the days of farking with someone by randomly rearranging parts of their card decks (with several thousand instructions in 360 Assembler).
I bet there are a couple of hundred of us under 50 worldwide who can say things like that. :-P
(NT)
why the California State Government department I consulted to for 20 years just retired their last IBM 704 two years ago. For you young'uns, we used to think the 704 was designated that because that's when its technology had been developed (years CE, of course).
And I'll shoot an RPG into the next box I'm sat in front of that supports RPG. Either that or add at least two extra zeroes between my usual hourly rate and the decimal point. Wasn't RPG the language that measured productivity in femtometers per fortnight?
What version of MySQL are you using?
http://dev.mysql.com/doc/refman/5.0/en/stored-procedures.html
Huh? Its not that hard to have a create a proper abstraction layer. You can even just start out with basic wrapper functions for the native DB library calls. The main thing is to separate logic from I/O. That's the thing to start with. As you get more revenue and see the need to invest more, you can elaborate your abstraction layer to grow with your application.
Any high level programming language that lets you declare variables on the fly and without a datatype is just plain stupid. And when's the last time you didn't get the result you expected because you had a typo in the variable name?As far a criticisms of PHP go, that's a pretty dumb one, given that that's a feature shared by almost all web-programming languages. What would you do your server side work in? Java?
We all know what to do, but we don't know how to get re-elected once we have done it
... an earlier one, the last time I looked at it. ... but the point remains -- abstraction layers are easy with stored procedures and a couple of classes to wrap the calls to them.
The answer to that question is not easy. From your post, it sounds like the old web developer had full autonomy to do whatever they wanted as long as they got the job done. Now you're left with a mess that you had to hunt someone down to support. Your decision on the platform that you want should be based on your business needs, environment, and IT resources. I know it's not what you wanted to hear but it is the truth. For example, if you guys are a heavily web based business that needs to crank out a lot of pages for changes often, use Apache as your web server, and have the technical expertise to support java based solutions, then I would probably choose something like PHP. However, if you are a MS based shop that wants to integrate with products like Sharepoint, MS Office, and the technical expertise for such development can be spread to others that are not web developers full time, I would choose the .NET platform. Not pushing one or the other, just stating that you have to look at what you want to do and move ahead.
Ada is a wonderful language. You just need to make sure you get a strong type of developer to work on it.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
I sure hope you slipped a "big tits are the shit" somewhere in your post. If you didn't, you missed out big time, since nobody's gonna read all that in detail.
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
I would think that the actual app itself is what needs to improve more than the database back end. If you've got a good database architecture for your requirements, then you can switch front ends and just keep the back end with minor changes. Although in my case both were crap and I had to start from scratch basically... but now you could build a new front end with the same back end if you wanted to.
simple, fast homepage with your links: http://www.ngumbi.com/
oi - the gargantuan winchester disk, the 8" floppy disk magazines, twinax, synchronous modems... We had one of the fast line printers (can't remember the model, damn it all) - it had the print band and could rip through greenbar like there was no tomorrow. Operating it with the cover up for any length of time was sure to cause hearing loss, but it was fast. I can remember when a tech had to come out and replace the winchester disk - that was quite the experience. and then reinstalling the OS, our software, and restoring the data from our tape backup - a long weekend project.
I really liked the S/36. Not fast, but rock solid. I remember wanting to put it in my garage when we replaced it with a little IBM RISC box (running the S/36 software in emulation), but my wife at the time nixed that idea.
I think you'll lose that bet (or rather, I think you just lost that bet).
I would concur that you can hire any experienced web developer to fill any web development position. For enough money I'd re-learn Fortran and support the site posited earlier in the comments.
The trouble with that route is the time it takes to get someone up to speed. If you have a live website, and you want it to work -now-, hiring someone who will take six months to get up to speed is a difficult sell.
But what if hiring the right person is going to take more than six months?
In fact, we don't have a jack-of-all-trades setup. We have one OS, one DB, and one language the site is written in. The setup hasn't changed in eight years (not counting, of course, upgrades!)
And, thank the heavens, we don't have EZ Publish.
But pretend for a moment that I come from a (choose one: commercial / open source) background. And I find myself working with the opposite. How do I know if the people talking about this 'Ruby on Rails' thing, or this 'Silverlight' thing, or whatever, are talking about what will become (or is) a de facto standard, or are just fanatics supporting a dying religion?
I think you may have answered your own question. Is it quicker to get some new programmer "up to speed" or redo the site from scratch? (IMHO, redo from scratch is a reasonable assumption.)
-
Can't be .Net or Java (shake a tree to find your dev). C/Perl CGI, Perl, Python, PHP, too common to find coders for. Ruby. Hah. Too popular still.
Nobody's considered the real dead end technology of late: ColdFusion. Yes, sites still run it. No, its not quite dead yet. Yes, Adobe provides and has provided plenty of hype to fool managers into deploying things to it.
The best way I've found to get a gut feeling is to use a simple risk-analysis that fulfills the classic 2 of 3 issue. "Cheap, Fast, Good -- Pick 2."
This will let you do a quick determination of what is important and get a general direction for how to proceed.
If you need something more detailed, or need to sell something to management who typically is only looking at the money side of things, you need to structure your risk analysis to answer the question:
"If I choose to (A), what is the financial effect on the project?"
Then start filling in (A) with different options and develop your answers.
eg:
Q: If I choose to switch platforms, what is the financial effect on the project?
A: I will reduce the number of development staff by 1/3, but mulitply the development cycle by 2 and require 1 additional maintainer.
Risk Analysis -- Switching platforms reduces demands on labor pool, but increases development costs by 1/3 and maintenance costs as well.
Q: If I choose to add an additional developer, what is the financial effect on the project?
A: I will reduce the time by 45% without appreciable impact elsewhere.
Risk Analysis -- Hiring a second developer on a short-term contract for 90% of what the current developer is making
doesn't change my bottom line, but gets the product done sooner.
F.F
I really hope you are a developer. I make all of my money salvaging projects after they have been in the hands of people that do not understand the relationship between computer science and quality programming. And business is booming.
When I first started programming, all they asked you at a job is if you ever programmed *something*, they didn't care what. Of course, for the most part what they wanted was someone to do some programming in their proprietary language, most of which have all died out now. But they knew that if you could program in Fortran or whatever, you could learn to code in whatever obscure language they needed, and they weren't going to find someone with specific experience in their own proprietary language anyway.
Now things are different-- job listings claim to be looking for someone with 10 years experience in a technology that is only 5 years old, and consequently there's no reason to do anything but ignore the listed requirements on a job posting, providing you can get your way past HR.
But what you really want when looking for someone to take over a job in a language that is no longer "popular," is to find an old-timer. What you want is someone who is *willing* to do the work, and capable of handling the bad decisions the previous guy made, you don't need someone whose been working for the last 10 years coding web apps in COBOL just because that's what the previous guy had been doing, but you also don't want a young punk whose going to get too soon bored doing that even if he had the skillz. It's true, the old-timer will probably be more expensive-- but the good ones will be likely to care naught about what tools are being used and what things are written in, and be able to pick whatever it is up without complaint and get the job done.
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.
Swapping database vendors doesn't happen that often. Some books exaggerate the frequency of it for some reason. And, wrapping it doesn't necessarily reduce the change-over work much because different dialects of SQL are often not plug-and-play with other dialects. Wrapper or not, you still gotta rework them. If you know you are going to switch, then perhaps one can use lowest-common-denominator SQL. But, then you don't get to use the power and efficiency of vendor-specific shortcuts. You pay a "swap tax" up front whether you swap or not in the future.
"Abstraction layer" sounds great on paper, but the practice is messier.
Table-ized A.I.
Although there are people that write obscure code in any language, if you smart and want to get stuff done, you would write clean readable code. its really not that hard neither in php or perl, or in any other language outside of lisp, however now that perl is falling out of favor with new programming recruits, you will be seeing a lot more crappy php even as their "skill level" is skyrocketing. If you want to write clean php just make all your variables global and prepend 2 underscores in front of their name to make them look cool !!! :D
If you want to write clean perl just follow "Best Perl Practices" book by Damian Conway.
MOD PARENT UP! I totally agree with the abstraction layer strategy. It has saved my team from "improvements", deprecations, and basic changes in the development environment vendor's flavor of the week. Most of the time with commercial vendors these "improvements" are driven by the vendor's desire to sell more licenses and training.
SYS64738
I'm sure you do well in business -- a tone of absolute certainty always goes over well.
And I've been a developer long enough to see multiple different fads come and go, most of them based on (some interpretation or other) of "computer science".
As I mentioned at the outset, my personal opinion is that if you start off with postgresql, you are unlikely to need to switch later. Even if you're using a "vendor", if they screw you over, you can drop them and find support elsewhere. The miracle of open source software, you know?
(By the way, myself I don't have any problem with writing portable SQL and using things like DBI/DBD, but I have my doubts this is what is meant by "a database abstraction layer" in this discussion.)
... when you've backed the wrong horse?
When Clippy pops up, offering to help!
I'm not exactly sure what you mean. I would hardly call J2EE a 'fad', it is a technology which has been around for about 10 years now.
And I don't think you can equate an 'Oracle database cluster' to enterprise middleware. They aren't the same thing at all. Sure, you can move a LOT of business logic into SQL stored procedures. You still need to do all sorts of other things. At the very most minimal you need external logic to accept incoming data (SOAP calls, RPC, JMS messages, whatever) and invoke the proper procedures, and probably send data/results to other apps. That code is also going to have to potentially manage transactions, etc.
Mainly this is why Oracle itself is a major J2EE application server vendor. Databases are fine, and you can do a lot with them. For some types of applications you can basically build the whole app in the database and use a mostly dumb client, but that strategy is still pretty limited.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
The problem is that platforms always move on. There is always a better technology just around the corner. Some of the 'better' technologies aren't, but some are. Universities and veteran programmers have to spend a great deal of time teaching/learning the new technologies because that's what the marketroids are hiring for, even if they suck. At some point you _are_ going to have to migrate to a new platform because buying people who know the old platform becomes too expensive or too difficult. You just have to plan on migrating every 3 or 4 years, sometimes more often because you can't find people willing to work in the old platform who are any good. Fresh out of Uni programmers only know the new platform, (some universities have stopped teaching C altogether for pete's sake), and often good veterans are unwilling to work with the old clunky system when there are plenty of good jobs in the new system which is better (some of them truly are).
Everyone is living in a personal delusion, just some are more delusional than others.
In my professional non-php applications, I isolate all of my data access into methods in separate classes. The overhead is minimal, when paired with a simple O/R mapper.
The problem with PHP/MySQL is that it's too hard to isolate data access, because the MySQL API isn't abstract enough to be able to throw a simple O/R mapper into the mix. When I hack together stuff in PHP/MySQL, I end up reading my results directly from the reader objects with hard-coded numbers. It's just too time consuming to engineer anything more elegant.
No, I will not work for your startup