On Fri, 09 Jun 2006 07:02:50 -0500, Eric Faurot <eric.faurot@gmail.com> wrote:

Hi all,

Hi Eric, let's see if we can provide you with some ammunition...

I will probably have a chance to be in charge of a (commercial) project that consists in developping a platform for handling distributed content, with XML-flavored chips and webby services. I am also confident that my voice will be heard concerning the technical aspects of the project. My wish is of course to use twisted for that. But I will have to convince people with the tie and the money, who tragically are also the ones who are most sensible to buzzwords.

How true. I've worked for a few large corporations, in the energy and pharmaceutical sectors, and management is always more comfortable contemplating so-called "best-of-breed solutions", where said term really means "whatever is popular in the media, supported by large companies, and used by the competition".

The LAMP case will be rather easy to deal with. I'll show no mercy. My concern is that the dreadful J2EE acronym has already been uttered. I have programmed a bit in java already, and I never liked it. I find it cumbersome and boring. Although I can certainly do that if I am forced to, I want to avoid it at (nearly) all cost. But I don't have enough experience to plead effectively against it. I doubt that intuition and aesthetic inclinations are really convincing arguments.

That's correct; management is already relying on subjective criteria masquerading as objective requirements, so adding more subjectivity to the discussion will only hurt you.

So, I'd like to ask twisted enthiusiasts with better knowledge and experience of J2EE than I have, if they could provide meaningful points for advocating python/twisted over J2EE, pro and cons for each.

My experience, which is based on a number of projects for the corporations I mentioned above, is as follows: - Case 1 - A web-service application was written in Python, using twisted and the SGMLOP parser (needed because it can parse non-xml markup). This application was used by a search engine, to allow users to search for portlets that might be useful in solving a problem. When the user clicked on a search result, the twisted service would connect to the chosen portlet, perform URL rewriting on the portlet's markup, and present a preview of the portlet UI to the user, from within the search results UI. - Application was developed to a working state in 2 weeks. - Bug fixes, refinements, etc, took another 2 weeks. - Management decided to contract a large offshore J2EE firm to rewrite the application in Java, so as to be compliant with "best-practices". - Development of a working prototype took 1 month. - Application was completed after 3 months, with slightly reduced functionality. - Cost was roughly twice that of the original application, despite the reduced hourly rate of the offshore developers. I've got more such cases, but not the time to type them all up for you. Hopefully this one real-world example will give you some idea what kind of advantages python and twisted can provide your management.

My main argument so far is that I am *way* more fluent in python, so I am more likely to come up with a prototype quickly. Also, the flexibility of python makes early refactoring much easier, and it is always possible to reimplement things in another language once the architecture stabilizes. I also think python is more portable than java, but that would sound a bit anecdotal.

Fluency isn't a great argument, in that management will counter by pointing out that there are a bazillion more J2EE developers than Python developers, and therefore choosing J2EE would make it easier/cheaper to find developers to support and maintain the application. Stick with reduced development time and increased developer productivity as your main points: Make it clear to them that 1 developer using python and twisted can do more work, in less time. That's efficient for the business, and management should see that as a viable alternative to the "throw bodies at the problem" approach.

Thanks for your input. Eric.

Hope this helps, L. Daniel Burr