Calling the PHP cowboys in from the range

Agile is 'perfect for PHP programmers'

Now that PHP is taking that big step from popular webhead scripter to serious enterprise tech, PHP coders need to add a new word to their vocabularies: methodology. Of course, there’s no quicker way to send cowboy coders stampeding for the hills than to say that word. (“Process” would do it, too, and there would be screaming.)

But Eddo Rotman says the change doesn’t have to hurt - much. His solution: agile development methodologies.

“Agile is a buzzword, if you want the truth about it,” Rotman tells The Register. “But a lot of people know what it is, and therefore maybe we can change the world a little and get people to use it. Also, it’s perfect for PHP programmers.”

Rotman is a senior PHP engineer at Zend Technologies, the Cupertino, California-based creator and commercial maintainer of PHP. He led a session at last week's Zend/PHP conference (October 8-11), held in nearby Burlingame, entitled “PHP & Agile Development Methodologies.”

Unlike traditional software development methodologies (such as the waterfall method), agile methods (also known as lightweight methods) have few rules and practices, all of which are relatively easy to follow. They emphasis individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. (There's an actual agile manifesto and more information at: http://agilemanifesto.org.)

All of which makes agile methods perfect for PHP programmers, says Rotman.

“With agile, they get their hands dirty very quickly, and they’re part of the process all the way,” he says. “They are stake holders in the whole process, and it’s easier for them to switch.”

But why should they make that switch? One of PHP’s best qualities is its accessibility. Basically, you can just log on to PHP.net and start programming. It’s fast, it’s fun to use, and you don’t have to be an engineer to get good at it. Why complicate it with process? "Within the PHP community, you have two factions," observes Gartner analyst Mark Driver. "You have one group that loves the simplicity of PHP and doesn't want that to change at all. And you have another group that wants PHP to be more robust, to compete better with technologies like .NET and Java, and to attract an enterprise-class developer. Zend is clearly in this latter camp, and really wants to push PHP to become a tier-one deployment technology, and not just a hobbyist tool."

“A lot who start coding with PHP never think about the bigger processes around it, and that just doesn’t work in the enterprise,” Rotman says. “Marketing managers love PHP, because they get results, fast, but they don’t see the code in the background. They don’t think about the fact that in two years or even less, when they want to make a change, they’ll have such spaghetti code that the programmers will have to go through hell to change anything. The programmers need to think about this. If you want to plan for the long run, you have to some process.

Agile development methodologies have been around for a while now, and the list of them is long. It includes:

Extreme Programming (XP): Developed by Kent Beck, Ward Cunningham, and Ron Jeffries, XP is probably the best-known lightweight methodology. With its roots in the Smalltalk community, it is a relatively complex system of practices, and Highsmith warned potential XP users to think carefully before picking and choosing among individual components.
The New Methodology: Developed by Martin Fowler, this approach emphasizes adaptation over prediction, people over practices, with an additional emphasis on what works in the real world.
The Crystal family of methodologies (sometimes called "the Crystals): Developed by Alistair Cockburn, who believes that different kinds of projects require different kinds of methodologies. He looks into this variation along two axes: the number of people in the project, and the consequences of errors. Each methodology fits into a different part of the grid, so a 40-person project that can lose discretionary money has a different methodology from a six-person, life-critical project.
SCRUM: Developed by Ken Schwaber and Jeff Sutherland, this methodology focuses on the idea that defined and repeatable processes only work for defined and repeatable problems, with defined and repeatable people in defined and repeatable environments. The process divides a project into iterations (called "sprints") of 30 days. Before developers begin a sprint, they define the functionality required for it, and then leave the team to deliver it. The point is to stabilize the requirements during the sprint.
The Dynamic System Development Method (DSDM): Developed in the UK. in the mid-1990s, DSDM has the best-supported training and documentation of any agile process in Europe, Highsmith said. Its principles include active user involvement, frequent delivery, team decision-making, integrated testing throughout the project life cycle, and reversible changes in development.
Lean Development: Highsmith said that Bob Charette's approach was the most strategic-oriented lightweight process, and the least known. It is derived from the principles of Lean Production, Taiichi Ohno's revolutionary restructuring of the Japanese automobile manufacturing process, Highsmith said. Lean Development practices subvert traditional methodologies’ view of change as risk, to be controlled with restrictive management. This method welcomes change as an opportunity to practice "risk entrepreneurship."
Peter Coad’s minimalist five-step approach to software engineering focuses on developing an overall model, building a features list, and planning by feature and design, with short, iterative cycles using object models of more shape than detail.
Adaptive Software Development (ASD): Developed by Highsmith himself, at the heart of ASD are three non-linear, overlapping phases: speculation, collaboration, and learning. Highsmith views planning as a paradox in an adaptive environment, since outcomes are naturally unpredictable. In traditional planning, deviations from plans are mistakes that should be corrected. In an adaptive environment, deviations guide developers towards the correct solution.

Which agile method does Rotman recommend? “I use a mix,” he says. “I go for the principles.”

Source: John K Waters