In 2007, Nassim Nicholas Taleb wrote a very influential book called The Black Swan - the title referencing to the idea that no matter how many white swans you see, you can never infer from them the existence of a (much rarer) black swan. The book was concerned with extreme events, particularly in the realm of investing, and how their likelihoods are so commonly underestimated. Taleb argues, among other things, that investors work under a flawed assumption that stock prices movements are normally distributed, so extreme market movements are unlikely. They are unlikely, but much less than expected, because traders do not always act rationally, and outside events can have a huge impact. He describes these unexpected triggers as black swans - surprising events, with a large impact.

So what does this have to do with software development?

Plenty, when it comes to estimating, planning and delivering projects. Most people have an assumption that a software project is, at heart, a reasonably predictable thing, and to varying degrees they're correct - based on experience, seasoned developers and project managers can usually come up with fairly decent estimates of how long a project will take. However, they all attribute incorrectly low probabilities to 'extreme' events occurring, which makes software projects more risky than they need to be. This is exacerbated by the speed of web projects, which, particularly in languages like PHP, are shorter and faster moving than more traditional projects. This means absolutely smaller events can have relatively larger impacts on the schedule.

PHP and Java are both languages with reputations for getting things done, and there are plenty of reasons for combining the two, particularly in an Enterprise environment. The most common situation is for an organisation with an existing Java infrastructure to want to develop PHP projects, for all the reasons any enterprise would choose PHP, such as speed of development, cost, desire to use specific open source applications, or availability of staff. Often this is inspired by an internal group who has started using Drupal, MediaWiki, Wordpress or similar to great effect, but without the integration to the rest of the organisation's infrastructure that would be needed for a full scale roll out.

There are many reasons to want to integrate these new developments with Java rather than just creating a separate silo - existing libraries or systems that would be difficult or expensive to replicate, well-tested systems providing key functionality, and an existing team of developers are just a few. So, the best way is often to mix and match the two - which is easier than it might first appear.

It's not too hard to sell someone on agile, whether internally or between organisations. Almost every objection from a traditional project perspective can be countered by the flexible change process, and the potential for better results, and ultimately lower costs. However, at best this creates passive acceptance, which is just about enough for someone not directly involved in a project, but can cause a project to become massively unstuck if that person is a dependency. It is also a fragile acceptance - if a project goes awry, then the merely accepting person is likely to start pushing back towards traditional methods, to the detriment of the project. The eventual failure then reinforces any existing reservations towards agile.

What agile needs to succeed in is understanding and support, and that requires a difficult mental shift - viewing work in terms of business value. Even experienced agile practitioners can get bogged down in implementation, and forget the why of what they are doing. This is because our experience teaches us to think in terms of problems and solutions, and to prefer the better known to the unfamiliar. We get so focused on building software we don't stop to think whether it does what we really need. Ryan Shriver describes this as not knowing the difference between "delivering things right, and delivering the right thing".

Core site content management system projects are incredibly common, but they are also often drawn out and painful. They're complicated projects because they often have a large number of stakeholders across different parts of the company. They can be a key part of digital or broader strategies, but also used for the most minor parts of day-to-day business. This mix makes it very difficult to tease out the essential aspects of the site, leading to a series of disappointing upgrades and replacements.

A successful CMS project begins with a good vision for the end result, which is expressed as a good set of requirements. Where most projects fall down is not in gathering enough requirements, but in gathering the right ones - and that's all about finding the real business value.