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.

Among the standard object oriented principles is favouring composition over inheritance, and there are plenty of design patterns that work along this line. However, one of the most useful day-to-day facets of the idea doesn't seem to get a lot of attention from PHP developers, namely dependency injection.

The general idea is, that if your class depends on some other object, that object should be passed in rather than generated internally or retrieved via a global variable or singleton.

One of the biggest benefits of PHP is how easy it is to find servers that run it. The near ubiquity of the LAMP stack among hosting providers does, however, lead to quite a common problem with inappropriate setups.

PHP programmers generally know what a good systems architecture should look like, but it is often a reality of development that they will have little input on the system itself until the last minute. In fact, it's far from uncommon for a developer to be faced with an off-the-shelf dedicated LAMP server, and left up to their own devices.

Recently, I've been working with a client as part of a major platform change they're making. It's the third time I've been involved with a big architecture shift, each at a different company, and each larger than the last, but there seem to be some observations that apply whether you've got five servers or five hundred.

1. Business carries on

It can be easy to get somewhat myopic when in the middle of an exciting architectural change. Major platform transitions tend to occur when there has been a realisation high up in the company that something needs to be done, so teams often have a fair degree of scope and freedom. However, it is even more likely that other parts of the business will need to continue to work on the existing system. If a new feature is required then it's going to get developed, even if that involves duplicating, or worse conflicting, with work that's being done as part of the platform change.