My first programming job was for a print company. One of the original founders quickly ripped out an entire ERP system for them that enabled them to have a leg up on the competition. They were in startup mode, so he did it in something that would allow it to get up ‘quickly.’ They chose FoxPro for Dos.
There I stood, 4 years and many, many employees later watching in horror as the company grew despite the software. They were now spread across 16 countries, all of their sales had become decentralized and the business was shifting underneath them rapidly. Here they were with a FoxPro for Dos ERP system, with full replication. They had tried the ‘big rewrite’ and it failed miserably. I do not blame them for that, they were the unfortunate victims of a great sales person for a company that could not deliver.
What it did show was just how important cost of change is. The ability to take a system and let it grow is huge.
I have since worked in many, many companies. Since founding EdgeCase four years ago, we have done projects of every different size. I can say without a doubt that every single project ended up in a very different place than where it started. As soon as startups see what’s possible or get the first bit of feedback they think of new directions.
Every single time, cost of change has been a major deciding factor in success or failure. This is why we use Ruby on Rails. This is why I think something like PHP is not a good business decision.
Are there many examples of companies that have thrived using PHP? Sure. Are there examples of companies who have chosen Ruby and Rails and ended up with a big pile of mud? Sure.
In the end though, I prefer to choose a language with a web framework built on it so I can move in a different direction if I need. I prefer a language that is expressive and tells just the essence of the business story that helps me build the application. I prefer a language that adopts and promotes unit testing to sometimes excessive levels (yes, anyone who was at Mountain.rb knows that I would rather have too many tests than none).
I’m not saying that you cannot unit test in PHP. Just like Objective-C, you CAN do it, but it is not baked into the language and culture. I do not see the same dedication to agile methodologies as I do in the Ruby community. Yes, barrier of entry is low, but I don’t like to throw bodies at a solution.
Yes, I’m making lots of assumptions here. Yes you are getting a slanted view point. I’m not trying to start a flame war, I’m simply stating what I see as vital when choosing technologies.
So your business case against PHP really isn’t against PHP, but rather the PHP culture. I’m certain that if EdgeCase wrote a PHP app, it would be just as expressive, elegant, and well tested as a Ruby app would be. The vital ingredient is not the language, it is the people using the language. This almost seems like a Target vs Walmart debate: they are really the same store, fundamentally, but those “Target” people are hipper and smarter, even though they are buying the same friggin milk.
I am a rubyist and recovering perler. I now work for a startup that is 2 years in and has a giant pile of PHP, and it’s painted into a nasty corner. No matter how good your intentions are, your app gets messy. Doesn’t it generally seem to go this way?
If you start with something that has a higher standard then are generally better off when you get to that point where you realize you’ve accumulated too much technical debt.
So yes, culture is important. It’s like the meta-framework that makes everything work better.
I would not deny that there are a lot of junk PHP apps. But is the language itself the cause? I say no. PHP is accessible to non-developers, which is a double-edged sword.
The cost of change is really not so much about language choice as it is about choice. You see, with PHP you have too much choice and with Ruby your choice is rather limited since you use Rails for web apps.
I think that because of this limited choice it allows a business to be more focused on problems and solutions.
So the cost isn’t really about change as it about how entropy affects our efficiency and about how we are more efficient when we focus on problems and solutions rather than which framework we are going to use.