Monday, September 14, 2009

A CTOs IT CHALLENGE - Do it in 7 Days

At Zend, I am lucky to meet and talk to a lot of innovative people who take technology such as PHP into imaginative ways in their business. I had such a conversation recently with a CTO from a large Bank who had called us for advice. During the conversation he and his team were really excited to share the details of a new PHP project that they were just about ready to release out of development, but had a problem with it. It turns out this project was the first public PHP application at the Bank, and they were typically doing everything in Java in the past. So I got curious and I asked them, What made you pick PHP for this?

The CTO said that its because PHP had proven itself to be a faster way of getting web ideas out the door. He was already a big Open Source proponent and bet big on Java at the bank. His firm had built most of its systems in Java technologies but when the projects started to pile up on his desk he got creative. He wanted to see if there was a better way to get some of this work done faster on his desk. So back in the beginning of this year, after last years books were closed, he decided to run an internal coding contest with his team. He selected one of the more common requests on his desk with a list of requirements and he sent an email out to his IT staff with a simple challenge. You have 7 days, use any technology or software in the bank even open source and proprietary applications were allowed, but you could only have three team members max on the project working on the requirements (an average size for them.) There were three submissions, one from a JAVA team who wrote everything on a Java/JBOSS platform, one from a team that used sharepoint, and a final winning team who used PHP and met most of the requirements of the project in the time alloted. They started with a popular open source PHP CMS and some custom coding to deliver on what the CTO had requested, and in turn helped him prove something important out during the contest. That it doesnt have to take months to rollout an idea or prototype at the bank. A small team can put an idea together in a just a few days to a few weeks, and then keep evolving it over time. And it doesnt have to take months to get his team upto speed either, most of his JAVA developer have now become very addicted to working on ZendFramework projects, just by initially prototyping in it. They already have many intranet PHP apps developed since the the contest. And as this most recent new project moves from the internal labs and enters public beta, the CTO was interested in sharing more details behind his early success with PHP. So an upcoming customer case study is bound to happen, but I did think his idea on how he jumpstarted PHP development at the bank (with a contest) was something that needed to be shared.

A different approach was used by another fortune 50 firm CTO I work with, he measured productivity of web projects during certain stages in the development cycle for both PHP and Java projects. Although the process used was a bit less fun then the first, the results also showed that PHP projects were more then 30% more productive then the Java way. He will be presenting the details at ZendCon.

So have you measured how much more productive PHP makes your business?, if so, drop me a line and let me know how you measure it for your firm. Also let me know what else you're doing to improve that productivity with PHP.

14 comments:

Michael Kimsal said...

I think this demonstrates the value of listening to your developers more than it does the specific value of PHP. PHP is fine, and great for rapidly prototyping stuff. That particular team might have been ever more productive using Grails, as they'd be building on top of their current Java knowledge rather than learning many new ways of thinking. I'm betting that they'd have had good luck with Rails as well.

Yes, trying out new ideas and prototypes should take days (or maybe a couple weeks), not months. If it takes PHP to help people see that, great. However, I think many more smaller businesses have realized that ideas can be prototyped and trialled in a matter of days vs months a long time ago, and have been moving to more rapid/agile cycles a long time ago. PHP certainly fits in there, as does Rails, Grails, and dare I say even ASP.NET MVC.

The philosophy and skills of the team, familiarity with tools and support of the organization is far more important than any one particular tech.

Johnny said...

I disgree with your analysis. First PHP is a language and not a framework... Which is what you are compairing it to when you listed grails, rails, and .NET. Those frameworks have steep learning curves, and often times require you to manipulate the framework to achieve your desired result.

Secondly, I would venture to say that there is more documentaion on PHP.... More then any of the framworks listed above.... And on top of that ... A larger user community to support any issues or questions that developers have.

Another advantge to using PHP is the amount of open source code available for developers to modify and utilize for their needs.

There is also the issue of debugging which can be rather cryptic when working in frameworks like ruby on rails.

I do think that frameworks are valuable assests when coding large applications due to their ability to maintain a consistant code base and something that abstracts certain pieces out for you.

If starting from scratch... Php is definitly the easiest way to get from point a to b without the steep learning curve of a language + framework

Michael Kimsal said...

@johnny - for starting 'a' project, perhaps. If you're going to be starting a project that will be working with large enterprise-level stuff (like bank data, as in the example), just starting with 'raw' PHP and just going out and reading docs from around the web is a sure way to wind up with poor software that paints you in a corner.

I'd hazard to say most supporters of PHP "in the enterprise" would suggest using a tried and tested framework of some sort for projects of any importance or size/scale. Doing otherwise is going to seriously hamper your ability to adapt to changing needs. Whether a framework that's chosen is a popular public one, or something smaller developed 'in house' over years, there's a whole other degree of 'stuff' that accompanies understanding how to use the various pieces beyond the syntax of the language and 'hello world'-level examples.

Yes, there's loads of documentation out there for PHP, and *much* of it is utter garbage.

$conn = mysql_connect() or die();

type stuff doesn't belong anywhere near a server inside of a bank, but that's the level of much of the PHP documentation out there.

There *is* a lot of good stuff out there, but it's overshadowed by the junk, and it takes years of experience to be able to separate the good from the bad. Yes, there's less documentation for Rails than for PHP as a language. The consequence of that is there's less to sift through, it's generally in agreement with itself, and more accurate because it's more recent and therefore likely up to date.

Go look at the Rails Rumble contest, and see what passionate people can develop in 48 hours (let alone 7 days). Any motivated team of PHP people should be able to replicate most or all of those apps in the same 48 hour period. Likewise with Grails, ASP.NET, CF and other platforms.


The forward-thinking Java community (as distinct from the entirety of the Java community) is embracing dynamic languages like Groovy, JRuby, Jython and others to enable the sort of 'rapid development' traditionally associated with Ruby, PHP and others. Some of the PHP frameworks out there (Zend Framework, Symfony, etc) are emphasizing structure, class libraries and general 'heaviness' traditionally associated with earlier Java web stacks. All parties seem to be learning from each other, and the winners are developers who use these new tools (languages, frameworks, etc) to deliver value faster than previously thought possible, while still providing quality and maintainability.


Again, I maintain the lessons to draw from this have less to do with the specific language and more about adopting new processes and ways of thinking and approaching problems.

Johnny said...

Poor code and documentation exists across all Languages.. its the nature of every profession.

In my experience, code is never written with 100% abstractness, and getting to that point is independent of the language and lands more so in the ballpark of the developers mind... most likely... a developer that uses spaghetti code... will do so no matter what language or framework they are using... if your not familiar with .NET you could still write out your data connector in every method, is that not true? A good developer would abstract out that code no matter what environment they were using.

The case study we are talking about utilized an open source CMS... most likely Drupal.. to achieve their goals. Were not talking about a Bank ERP that was coded in 7 days... we are talking about a simple CMS... probably for a new product or mini site that was sitting on the back burner for a few months.

I do not know of any other language where you could deploy a CMS as rapidly... with little to no knowledge of a framework.

Edward Kietlinski said...

Its good to have a dialog about how a company can be more productive with Web development.
And in my article it was hard to talk about this first example without going into the specific details about the contest.

Why neither one of these firms used RAILS I can only guess it was resources, but they both do use frameworks and best practices as you would expect at a bank. I often run into PHP/JAVA/.NET as the most popular web environments as I did in both cases. And indeed better practices and improved process was important also with web development at these firms.

I've since added another paragraph at end of article with another example financial firm that measured productivity differently.

Both examples in my article of a bank and a fortune 50 firm are big Java shops that measured productivity of PHP .vs. JAVA. They both are using a PHP Framework and utilizing best practices with Zend solutions. Here's a bit more detail that I can share about the second firm. I think you will enjoy how they utilize best practices and measure success with web development at ZendCon2009:

=============== added to article==

A different approach was used by another fortune 50 firm CTO I work with, he measured productivity of web projects during certain stages in the development cycle for both PHP and Java projects. Although the process used was a bit less fun then the first, the results also showed that PHP projects were more then 30% more productive then the Java way. He will be presenting the details at ZendCon. We'll have a podcast audio on Zend DevZone sometime after the show if you missed it and a case study.

So have you measured how much more productive PHP makes your business?, if so, drop me a line and let me know how you measure it for your firm. Also let me know what else youre doing to improve that productivity with PHP.

Michael Kimsal said...

@johnny - "poor code and documentation..." In my experience, it's far more prevalent in the PHP world. Nothing's perfect, but there's such a glut of bad PHP books/sites/examples/tutorials that it's *extremely* hard for beginners to know what to trust and believe. Less of a problem with newer platforms like Rails.

Drupal *is* a framework - there are numerous books about how to develop with it, it's got a huge API, training and support contracts. It's a huge ecosystem. Yes, it's simple to get started, but it's also able to handle complex stuff lately.

Just because you're not aware of competing CMS in other languages doesn't mean they don't exist. mojoportal & graffiti cms come to mind for .net - other platforms have their share.

The article also mentioned that many other internal projects were all being built with PHP. That's great, but they could most likely get the same rapid development benefits with almost any language out there (provided they had the knowledge).

The client in question is probably not using the same base CMS for every single one of their internal projects. If they are, they have an extremely limited/narrow set of business problems to address. They are likely now using a mix of PHP code, projects, libraries and such (ZF was mentioned, so they're probably using a lot of that). They're having to *LEARN* ZF. They could spend the same time LEARNING ASP.NET & applying rapid dev techniques with that (or CF, or Rails, or Grails, or something else). The 'rapid' aspect isn't just a technical one - it's a business culture mindset, and the person in charge at this bank challenged the old ways of doing stuff and is reaping rewards.

Wild guess - they had people on staff with some knowledge of PHP which got leveraged. If those people didn't know PHP, but already knew Rails, the outcome would have been different, yet FUNDAMENTALLY THE SAME.

Again, no disrespect to PHP, but just because they weren't aware of (or didn't try) alternate platforms doesn't mean they aren't valid or viable options for delivering rapid business value.

Quick story). I took over a project recently that a previous developer had put together using PHP. No framework, just layer on layer of bad code. None of it probably *seemed* bad at the time. It was built to do one small thing early on, and it kept getting hammered with scope/feature creep, and the original developer had *no* idea how to architect something for any growth at all.

I maintained it for several months, then rewrote it in Grails. I've been doing PHP for 13 years, and I managed (in this case) to be *more* productive in Grails, primarily because of the GORM/Hibernate combination. GORM inside Grails allows me to simply write classes (and relations), from which the db schema is created (for any JDBC db I point it at).

I rewrote the entire app & added in new functionality, in about 100 hours. The previous developer had clocked 3-4 times that over his tenure barely keeping up with bug reports.

Sure, I could have redone it in PHP. I probably would have clocked about the same number of hours (I think it would have been slightly more, but I'll never know). I know I was able to have basic functionality up *much* quicker than I would in PHP, using a framework or writing from scratch. "Right tool for the right job" comes to mind here. If I was needing mostly CMS functionality that I could extend, I'd probably consider Drupal or something similar - it's mostly predone, and makes a lot of sense for those types of projects. I wouldn't start an ecommerce project with Drupal, and many projects I wouldn't start with any prebuilt projects (frameworks yes, systems no).

Wrapup: PHP is great, but it's not the only option out there capable of delivering rapid dev benefits. Change the business culture to encourage and expect quick results, allow developers to choose appropriate tools, and reap the rewards.

Johnny said...

I think you are confusing software (CMS, E-Commerce) with framework (GRAILS, ZF, RAILS). They are 2 different things.

Johnny said...

and you actually could start an ecommerce project with Drupal.. FYI

Michael Kimsal said...

I could start an ecommerce project with Wordpress too, but it's not the best tool for the job, and it wasn't designed with ecommerce in mind.

"I think you are confusing software (CMS, E-Commerce) with framework (GRAILS, ZF, RAILS). They are 2 different things."

Johnny, I think you're confusing changing a business culture with changing a programming language. More to the point, the benefits the company in the article are getting aren't from PHP as a language, but from pre-existing stacks ("frameworks", if you will) - an open source CMS, and Zend Framework as mentioned in the article (and likely others too).

Skaag Argonius said...

As a person who used Rails, Symfony, Cake and Zend, I can tell you they are all quite different.

I totally disagree with Michael Kimsal, who seems to assume that the Java team did not know about Grails when they selected PHP.

What I like about the Zend Framework is how everything is loosely coupled. You can mix any technique or development philosophy you want. When you work with Rails, your brain is automatically heavily bogged down with the complexity of the structure and philosophy that come with Rails.

Maybe if you had a very well defined project from the start (quite rare I have to say), you could maybe use Rails, and it would still take you longer to implement than if you used PHP & Zend Framework.

Zend Framework + PHP = Freedom, Speed, and infinite Flexibility.

On the other hand, and as much as I absolutely adore PHP, let's not forget PHP is a weakly typed, over-flexible language, without support for threads, and unless you know what you're doing, also quite lacking in security in the default form that most distributions provide (quite unfortunate, that...)

You can see how weak typing manifests when you use Zend_Soap and Zend_Auto_Discover -- it requires docblock comments to correctly build the WSDL.

Skaag Argonius said...

By the way, I also adore Ruby, Java, C++ and even Bash Scripting :-) They all have their rightful place.

But hey this is a post about PHP & Zend, it's probably silly to deviate from the subject and maybe start a flame war about what language is best?

Michael Kimsal said...

@skaag - not sure what there is to disagree about, but people seem to want to disagree. For some reason people want to turn this in to a 'my language is better than yours', and I really just see this blog post as a win for "let's rethink how we work" rather than "let's choose one language over the other".

For someone expertly skilled in Rails, they *will* smoke *most* PHP developers in productivity, regardless of whether they're using Zend Framework, Symfony, etc. Likewise, someone expertly skilled in ZF will smoke *most* Rails developers in productivity.

People who are passionate about their tools (like you seem to be with ZF) will almost always be more productive than others who treat dev work as "just a job", or worse, are in a corporate culture that rewards mediocrity.

Why do people insist on trying to make this in to a language or platform war, when it's a mindset shift or perhaps a 'culture war' at best?

Skaag - a downside of doing it 'whatever way you want' (your 'freedom' in ZF) is that other people on your team might not understand the way *you* chose to assemble all your ZF building blocks. In a more 'opinionated' framework (like Rails or perhaps even Symfony), many others find freedom in the rigidity of having to do certain things 'the standard way'. MS has made a good living off providing a number of 'defaults' and 'standard approaches' for app development. *everyone* in the MS app world has used the northwind database at some point - there's no analog in the PHP/LAMP world to point to. As such, MS developers, by and large, are more able to move between projects, because the underlying plumbing is the same. They get to save their creativity for problems closer to the business layer, not in figuring out how best to create an error template for an MVC system.

ZF itself seems to recognize this, and seems to be slowly moving towards a more complete 'out of the box' experience, to let people be more productive with defaults rather than worrying about how to wire the pieces together first.

Yes, certainly having the freedom to wire everything together however you want is great, but the burden of having to know *how* to do that first before you can express your app logic tends to be a net loss for most people at the outset (not specifically talking ZF here, but many frameworks in general).

Michael Kimsal said...

@skaag - I guess I never took it as a post specifically about PHP (though that was the example used). I took it more as a lesson other companies can learn about letting their employees try other tools and approach projects differently (giving people short deadlines for prototypes vs doing 6 month project planning at the outset). The same types of stories are being written with Rails instead of PHP in other blogs and magazines and such, and I just pointed out the bigger lesson is not the language, but the approach.

Others seemingly want to turn this in to "PHP is the best" type bashing.

Amitabh said...

The cost of a project is mostly incurred during the post implementation (operational) phase. Maintaining and enhancing the code is far more important than the initial time taken to get the code out the door.
Projects that are based on frameworks are far easier to maintain and enhance.