What colour is your toolbox?
Earlier in the week an interesting thread about the recent Mintshot debacle came up on the NZ 2.0 mailing list about how the world at large has moved on from PHP and that those staying with PHP without bothering to explore or check out some of the newer languages/frameworks are doing themselves, and their clients a major disservice:
PHP had its time in the limelight but we've moved on enormously since then. Nobody should be building new web apps in PHP unless they're brutally constrained by the need to host on a $7.95/mn server.
Wake up call for anyone who has been sitting happy on PHP, you're missing an entire *world* of modern platforms and strategies for building apps faster and better, of a level equivalent to the leap we had from cgi-bin to PHP in the first place.
The last time I ever used or saw any PHP code was back in the PHP3 days and my memories of it are far from pleasant, however I'm sure the language and its available frameworks have progressed since then to be somewhat acceptable (for instance Caucho provide a pure java implementation of PHP5 which can deploy to any Java application server providing major performance and scalability benefits).
Whilst the NZ 2.0 thread quickly fell into a PHP vs TheRest debate, Richard's main point of contention was the number of PHP developers who sit in their stone towers without any awareness of the world around them. They're not choosing to stick with PHP - they're simply ignorant that there might be something better.
It wouldn't surprise me if a lot of those PHP programmers already knew of their ignorance, but like a lot of Java developers find themselves stuck with projects that should now be classed as "legacy" with no breathing room for learning an endless stream of new technology. This unfortunately leads those developers to starting new projects with "what they know" - which is not always a bad thing as Reg Braithwaite points out:
What indeed? What if programming conventions and closures and meta-programming and expressive type systems and annotations and all of the other tools that give us the power to build powerful abstractions actually don't scale to larger teams?
Perhaps we have somehow confused the cart with the horse. Teams exist to deliver working software. So, shouldn't we choose the tools and processes proven to produce working software and build the team around them, rather than choosing the team and then dumbing the tools down to the level of whomever we hired last Tuesday?
- What if powerful languages and idioms only work for small teams?
When we do actually find the time to start learning or creating new frameworks to solve our problems better we can easily fall into the tweak-trap: spending all our time hacking the internals, writing endless test cases and usage docs, improving code coverage and abstracting and then refactoring everything to point our code can look like "do_what_the_client_wants();" that we forget that we actually need to write that last line of code and make value for our clients and users.
The client (for the most part) doesn't care HOW the projects written - only that it works and is on time. Ben Collins-Sussman also reminds us:
There are two "classes" of programmers in the world of software development: I'm going to call them the 20% and the 80%. The 20% folks are what many would call "alpha" programmers - the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90's; the people who write lisp compilers and learn Haskell on weekends "just for fun"; they actively participate in open source projects; they're always aware of the latest, coolest new trends in programming and tools. The 80% folks make up the bulk of the software development industry. They're not stupid; they're merely vocational.
Back in the day I was a Delphi guy and I had my fair share of flamewars mocking those "The VB Guys" whilst they mocked back about "that pascal thing no one uses outside uni", and more recently I became known around the office as "That Smalltalk Guy". I don't see these arguments and platform taunts going away anytime soon and I actually find them a healthy exercise.
At the end of the day, it doesn't matter if you're using PHP or Ruby, Java or Erlang, Z X or Y - if you're chosen platform keeps you productive enough to provide benefit to the client - you're doing better than most IT projects and don't need to change.
If you can justify why you're using platform X over platform Y - even better.
I have to admit that getting my team to focus on solving the customer's
problem rather than solving some "cool" problem would make my company much
more profitable!