This week I gave a two-days power workshop "PHP in big projects" ("PHP in Großprojekten", as it was in German) on the conference "Entwicklertage", organized by the Software & Support publishing house. One of the topics was to tell how companies save millions of Euros by choosing PHP (like E.ON, for example) instead of Java.
With the advent of the discussion of PHP being in the Enterprise (in fact, it has been there for years, at least we know of mission-critical enterprise PHP applications since 2000), I think it’s time to post my point of view of PHP being in the Enterprise (being a result of my experience with our enterprise projects for companies like Telefónica, Sixt, HypoVereinsbank, Vaillant, Siemens and others; over 300 people that I’ve taught PHP in large companies like Cap Gemini, Deutsche Telekom, Bundeskriminalamt, E.ON and others).
PHP’s main USP was always "getting things done fast". I remember a situation in one of our current projects (a 15-country international project with more than 1.000 mandays of PHP work that will go on for years) where I had to present a graphing solution including some complex XML stuff in two hours for the group marketing head. I think this is only possible with a language like PHP which makes it so easy to get your things done.
So, if you go and have a look at the PHP poster, you see several additions to the new object orientated model. There are plenty of new extensions that make the life of a programmer easier, including sqlite, mysqli, htmltidy, iterators and such.
In my power workshop, people were astonished that in the >1.000 mandays project we haven’t used any kind of UML diagram. Nor do we have complex nets of classes – we like to have a flat class hierarchy with a maximum level of 2 or 3. Overall, we prefer principles like KISS, some rules from eXtreme Programming and Scrum in favour of having everything in complex structures.
The customer doesn’t want beautiful code with the latest design patterns hype!
Instead the customer wants to have code that gets things done fast and that is easy (means: for less money) extensible in the future. For German readers: please consider Kristian Köhntopp’s excellent posting about this topic.
Don’t misunderstand me: we also use object-orientated code (about 80 classes in the aforementioned project), but we care for a pragmatic way of programming. Yes, we do use ER-designers like DBDesigner and such. Yes, PHPUnit does make sense but only in special cases. Of course we document our code according to the PHPDoc standard.
But our customers love that PHP is not like Java or at least we don’t program with PHP like in Java. And that’s why more and more big companies discover PHP as a valuable alternative in the web area.
The globalisation changed the markets. Companies have to react in shorter timeframes to changing markets. The companies want to get things done fast for their websites. More and more companies discover PHP as a great alternative that backs their needs in this area.
If you want to know more about how to deploy PHP even in the most complex IT infrastructure, don’t hesitate to write a mail.
Just for the records: I regard the recent DevShed article „Conflict PHP“ as some kind of Zend-bashing. All PHP core developers, from Zeev, Andi, Derick, Georg, Marcus Börger (only to mention a few) have done a great work by releasing PHP5 (a big thanks to all of you). And of course the new object model is great – if you know how and when to use it.
Es ist einfach unseriös PHP als eine ernsthafte Alternative zu Java oder anderen Scriptsprachen (Python, Ruby) zu betrachen, wenn man bedenkt, dass PHP
* immer noch nicht richtig OOP kann
* immer noch nicht Unicodesupport hat
* keine Namescpaces hat
* eine chaotische API hat
* Sicherheitslöcher enthält
Es ist ein Eigentor den Beitrag von Kristian zu verlinken. Denn wenn man das befolgt, was Kristian in seinem Posting empfiehlt (Lernen von Smalltalk, Objective-C, Lisp usw.), dann wird man nie zu PHP zurückkehren wollen, eher zu Ruby.
Hi Alex,
die chaotische – weil gewachsene und beibehaltene – API und die fehlenden Namespaces sind in der Tat sehr nervig.
Die Sicherheitslöcher würde man vermutlich – wenn man 3000 Funktionen in Ruby untersuchen würde, die direkt c-Libraries aufrufen – auch finden können. Der Unserialize-Bug war ein bischen dämlich, aber auch das passiert woanders.
Zwei Anmerkungen aber trotzdem:
– IMHO ist es ein Missverständnis, Enterprise in der Technik suchen zu wollen. Eine Sprache wird dadurch zu Enterprise, dass sie sich betriebswirtschaftlich bei Anwendung in komplexen Systemen auszahlt.
– wie soll man so ein Statement bewerten, wenn Deine PHP-Flame-Seite
http://knaub.info/index.php?id_kat=22
durch falsche Funktionsbenutzung und nicht gelesene Manuals glänzt, und das dann als Beweis genommen wird.
Welche Funktionen habe ich denn falsch benutzt? Ich habe nur versucht ein Idiom, das in Ruby oder Objective-C sehr elegant realisierbar ist, in PHP zu implementieren. Das geht aber nicht, weil die Behandlung von statischen Methoden in Verbindung mit Vererbung in PHP kaputt ist. Auf der internals Mailingliste gab es zu dem Thema mehrere Diskussionen und die Eintragungen auf bugs.php.net sprechen für sich.
Ian Felton has hit it right on the head on „Conflict PHP“. He says
—–
PHP is a hypertext preprocessor. A hypertext preprocessor doesn’t require an object model as complex as Java, especially when hardly any members of the community use Java and the vast majority use the product because it’s simple.
—–
I wrote about that in http://blog.koehntopp.de/archives/406-Was-machen-wir-morgen-abend,-Pinky.html, where I quoted http://www.kuro5hin.org/story/2004/7/14/232752/474:
—–
It probably isn’t putting it too strongly to state that PHP v5 represents a concerted attempt to break away from the role of ‚easy-server-side-scripter‘, with competing in the role of an all-purpose, easy-to-program, generalized, cross-platform interpreted language being the ultimate aim.
—–
PHP5 is just that: Positioning the language in a position where it covers a lot of ground. You can use PHP5 like you used PHP3 and PHP4, the language is suprisingly compatible considering the number of things changed and improved in version 5. No complexities added, by the way.
But PHP5 is a lot more than that, and judging version 5 by what was common knowledge about version 3 and 4 is a severe mistake. Sebastian does an excellent job in hist book (http://www.amazon.de/exec/obidos/ASIN/3898642291/) showing of the capabilities of PHP5 as a serious language. And the project successes with PHP, at Yahoo!, by thinkphp.de and in other places, shows that the language and the platform are up to par with what is required in large and very large setups.
It is not single features such as „Namespaces“ or „the API is beautiful“ that make languages successful – look at Perl and Python.
There is hardly a language that is more „ugly“, has more idesyndicracies and illogical and magic constructs than Perl. Perl has no OOP built in, but the parts to model any OOP model you can conceive – you just have to roll it yourself.
Compare with Python. A beautiful language, with OO designed in from ground up. Python is clean – there is one single way to do things, and that is The Right Way.
Yet, Perl has a higher market share and is in more places than Python. No person in system administration or development can ignore Perl, but most people live just fine in these places without having ever heard of Python.
But back to PHP. PHP started as a homepage toolkit for the resume of Rasmus, but it didn’t stop there. PHP3 was a solid language for small to medium web applications, and in that time many interesting new technologies were tried and learned by the community. Sessions, database abstraction, and templating were being explored during the reign of PHP3.
PHP4 consolidated what we learned in that time, and positioned PHP well in the web applications market. It was PHP4 that drove Yahoo!s front page, and it was PHP4 that was the foundation for many thinkphp.de projects and products.
PHP5 again takes the language out into new areas, areas outside of the web. It is surprisingly successful in these contexts, and it is surprisingly efficient and easy to use – at least for these that haven’t seen it in a web context before. PHP5 again is an „exploration release“, where the language enters new realms of application, and I’m certain we will see many enhancements where appropriate in a 5.1 release.
PHP projects often start out using PHP as a glue language, because PHP is extremely good at aquiring and integrating foreign libraries and tools, and making them part of the language, and with PHP5 this became even easier. Often, PHP outgrows its nice in these projects and becomes a vital part of the project or the project itself becomes a PHP project.
PHP coders often describe the language as the Borg. Like them, it is not beautiful, nor is it complete. But like them, it strives for perfection, it assimilates, it adapts, and it gets the job done with frightening efficiency. And like them it is destined to one day rule the galaxy.
We use PHP for an early childhood tracking application. We just had a reviewer come in and look over our child care programs (with a microscope). She would ask for some crazy reports and in 10-15 minutes I was able to have php create fancy tables, charts and graphs, in excel format. Can’t imagine doing this with any other language/platform. MySQL and PHP are great. Makes me look like some sort of tech genius to the people I work for.
Java is expensive because of
* large API. You pay lots of money for programmers who can explain every detail of it while they are sleeping. They will tell you why the IO-Package holds lots of decorator patterns, too, while brushing their teeth.
* scalability is expensive: Getting Java faster means basically investing in expensive hardware
* no-one-man-projects: When using Java, you won’t use it for writing a counter or a guestbook. Try find a Java developer among students or self-employees for a reasonable price. Good luck.
PHP is cheap because of
* no API. RTFM, that’s it. Use a fopen here, fgets there. This is how you do your file operations. At the end, you will ask yourself why you’re having encoding problems.
* scalability is cheap (as long as you don’t whore with your code) -> no app server.
* everyone does PHP. Students will code a guestbook within an hour for 15 Euros. As long as you dont ask for quality… Got a big project? Try look around for people knowing design patterns, are qualified for developing in a team that consists of more than two people…good luck.
Basically, I do not agree with Bjoerns statement. I agree that PHP is ready for enterpise (even if the missing namespace suck big time). But programming an enterpise application means OO Abstraction all the way to me – as long as you don’t want to take care of the project all your lifetime. Reusable API all the way, baby.
I’m not sure if PHP will catch up to the role of Java when it comes to enterpise application builiding in the near future, allthough Zend is doing a great job out there.
In my power workshop, people were astonished that in the >1.000 mandays project we haven’t used any kind of UML diagram.
I like that. ;) What kind of customers do you have? Do they even take care of the time and the money they will spend on new employees for „getting into the code“ if your company stops working on those projects?
Hi Thorsten,
> But programming an enterpise application means OO Abstraction all the way to me
I didn’t say that. Yes, OO is neccessary. But know how and when to use OO. That’s all.
Our customers take care of the time and money. Of course they get a documentation and an overview of the architecture. But we don’t use UML for code generation (which is intended behaviour when discussing about UML).
Well there are different kind of Enterprise projects. There are the kind where its clear you need a few tenthousand man hours in a year. Here you will have to employ large numbers of developers. Here I can see a benefit in using UML and then you have a clear benefit in using Java since UML2PHP intgration is still a far way off.
Now one of the key advantages of PHP is that it cuts down the number of required man hours because it allows you to stay practical.
But where PHP really shines and where you can throw out UML is when you have a project with a few tousand man hours a team of less than half a dozen top PHP developers and a client that actually cares about the end result versus caring that some kind of initial list of requirements is met.
What I am talking about here is the fact that with PHP you can integrate the customer into the development process by showing him prototypes pretty much as often as you need (daily if necessary) to get the interface, the workflow etc just right. You simply cant realistically do the same with Java and certainly not if you are doing UML diagrams. The end result is an application that is equal to version 2 or 3 in the more traditional approach. UML is nice to get the internal APIs just right. But the real challenge is in getting the interface between the user and the application just right. And there onky prototypes will help, because your users are unable to think about their application in abstract terms.
So this development only works if you get along with your client well. Traditionally alot of Java people might find this odd in the Java space. Afterall they see their client at the kickoff and the fuckoff (err I meant the meeting where they celebrate the successful project completion) meeting. But isnt the enterprise market more about producing highquality solutions for mission critical tasks?
Another point to consider is that alot of projects fail because they end up with a monolithic design. These are exactly the type of projects with tens of tousands of man hours I mentioned above. Often separating this one giant project into several smaller ones will give you a more scalable design, will give you proper reality checks during the project and more importantly it will give you the opportunity to get to know the quality your coding team is able to provide.
Hi Bjoern,
I think I might have gotten you wrong here – not using UML sounded to me like not providing this sort of documentation to the customer. Nevermind.
„Know how and when to use OO“ is difficult, specially when it comes to the advanced OO features of PHP5. This is a point that has been discussed lots of times in the era of PHP4, and will be even more discussed in the upcoming (productive) use of PHP5. For myself I think that you cannot do much wrong keeping your code OO abstracted if you are a good programmer. Since PHP5 gives you much more opportunities in writing your code OO, people may want to re-think the „old“ way to code PHP and stick to a new way of programming. This comes to the cost of performance, but yes, it will shine through in the reusability of code and gives people who come from the „traditional“ OO languages the opportunity to get faster used to PHP-scriptping.
PHP5 started a kind of new trend among the core PHP programmers, which is: Porting Java-Frameworks to PHP (php4struts, PHPUnit, I myself port parts of the Java-Api to PHP5). And all this is not only done because people have too much time, it is done because people want to take full use of the new features.
I have no idea if PHP5 will be called „little“ brother of Java sometime (allthough I got the feeling Zend tries to bring both languages together in a way I don’t like – Java as the backoffice, PHP as a presentaion layer) and if the cost of developing PHP will catch up to Java (both languages compared to one and the same project). The fact is, that the new OO features provide a way to develope more cost-intensive. Which way to chose (traditional PHP-style – iterative programming mixed with OO – vs PHP5-style – strong use of OO with very small amount of iterative scripts) will still be up to the programmer himself and to his abilities in convincing his client about using „his way“ to do things.
@Lukas
You are right in several points – developing with PHP(5) can be done quicker, results can show up in a shorter intervall. However, I have made the experience that when it comes to good projectleading and planning the development process, you can even achieve this goal with Java.
php4struts = struts4php
just for the protocoll ;)
As I’ve said, PHP’s USP No. 1 was always getting things done fast. Of course we do use object-oriented programming, of course we sometimes use design patterns (if applicable at *no cost* in terms of time and performance). This leads to code that is living in a long-term way. The main goal the customers want to use PHP is because they want to get their applications in a shorter timeframe than in Java.
The problem with things that get ported from Java to PHP is: although sometimes it might be useful (for example, PHPUnit), there are many programmers out there that want to use it just because it’s *cool* or *hip*.
Customers don’t want to have cool or hip things if it is counterproductive to the money they want to invest. And that’s a thing we try to say: know how to use OO and know when it’s applicable. It’s not just because your professor would like the code, it’s because the customer spends a lot less money than with languages like Java.
And that’s why more and more big companies want to use PHP in favour of Java.
You totally got a point here and it would be dumb to argue against this.
However, future comments from me on this topic would be all based on „personal“ taste – developers tend to plan and build their application in different ways, allways with the goal in mind to satisfy their clients with the most useful architecture.
One last word:
I don’t think programmers port Java-stuff to PHP just because it’s *cool* or *hip*, since one can do better things with his time than to waste it on *cool* (after all *useless*?) things. Means: The Java-world has some great frameworks. Using some of them makes sense in a PHP-driven environment. Others, however, don’t fit in our world…