Karl Katzke

First, read this: The Answer is No @ The Big Contrarian.

In response: At least part of the problem is that we STILL haven’t defined the question. Is it that we develop a web application to solve problems in the most efficient and graceful way? Or is it that we develop a web application in the most maintainable and understandable way?

To extend Jack’s metaphor of hammers and nails, the former would involve using a different hammer every time we need to drive a hammer into different wood. But you could quickly build up an environment where you had many different nails driven into boards at different depths and angles due to the blows of so many hammers. If you’ve driven the nail too deep for the wood, you may not be able to get it out at some point in the future without destroying the wood completely — aka one of those oft-talked-about failed development projects.

The discussion of how to develop web applications and what technology to use isn’t just a computer science decision, it’s a business decision. As someone who approaches computer problems from a utility and maintainability perspective, I want three things from a development tool. First, I want it to set (but not force) a style so that all programmers can code in a similar fashion, and programmers who are new to the project can walk in and get a feel for things within a few minutes. Second, I want it to be maintained and maintainable into the future as the language and development methods change. Third, I want it to be based on a stable technology that scales well. These are all utility things, considered at a much more abstract level than the computer science problems that Jack talks about.

If programmers didn’t search for new tools, the web would still look like it did in 1995, and we’d all still be developing CGI applications in C. Be thankful that the world moves on and that there are people and companies willing to develop and pursue new ways of doing things. The dogmatic approach some developers take towards their favorite technology isn’t bad, per say. It’s just part of the darwinian selection of the platforms and technologies that will move on. And in some cases, the programmers who won’t, ground beneath the ceaseless ever-rolling wheels of progress.

It’s fine to allow people to search for new tools and to be evangelists of their favorite tools and processes. On their own time. When they come to work at a job (be it consulting or other), someone needs to be laying down guidelines of how to do a project, and someone needs to enforce that all projects within one cone of perception use the same technologies, or use technologies that will be compatible in the future.

Standardization is the only way to maintain a high level of support. Corporate development jobs regularly fail because someone had to do it their way. (I’m guilty of this too, but I’ve learned my lesson.) It’s the responsibility of the lead programmers to make sure that this doesn’t happen. Even if Zend Framework or Symfony or Ruby on Rails or some other technology is the most elegant and fastest way to solve a problem, don’t do it unless that’s what your group has standardized on, supports, and knows. If you’re a PHP shop, don’t write a webapp in Python. If you’re a MySQL shop, don’t use Postgres for this one project to “try it out.” Don’t. Just don’t. Pick one thing that’s good at many areas and just use it.

That isn’t to say that you shouldn’t improve your chosen one. Doctrine exists because some developers wanted an ActiveRecord implementation in PHP that was as easy to use as Rails’ is. So they wrote one. Symfony came from nearly the same place. Zend Framework’s rapidly arriving ajax integration is a direct outgrowth of what Symfony did with theirs. Just keep in mind that it’s not features from the programmer’s point of view that matter, it’s features from the point of view of the downstream developers that will support the application in the future and the systems administrators who have to maintain the platform that you’re on. If you keep it simple and just pick one for your particular shop, they can keep it simple too. And simple means stable. Stable, maintainable, and understandable means happy users, and are considered features by your users.

Make sure you deliver those features, or your project too will fail.