Category: Patterns

Pitfall: Not recognizing the politics of architecture »

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]
CATEGORIES: political, architectural, managerial
While discussing the challenges of software development with Taligent trainer Tom Affinito back in the mid-1990s, I mentioned — citing Fred Brooks — the need for a chief architect. Tom immediately responded, “Yes, and ultimately architecture is a political act.”
That observation has [...]

Shades of Denver »

The opening of Terminal 5 at London Heathrow Airport has not been without problems, to say the least. And one of the specific problems appears to be the automated baggage handling system:
…the computer-operated baggage system has crashed and luggage is now being sorted manually before being loaded on to planes.
Twelve return flights to short-haul destinations [...]

Speaking of never-ending stories… »

…this IT project out of Sydney appears to fit the bill:
Ten years after it was first announced and almost $100 million later, Sydney is no closer to a cashless public transport ticketing system after the NSW Government was forced to terminate its contract for the troubled Tcard.
Transport Minister John Watkins announced the contract with Integrated [...]

Why projects slip: commercial games »

From CVG comes an interesting (if brief) article on why so many commercial computer game projects are late:
PC gamers waited with bated breath, to the point of asphyxiation, for Half-Life 2, but the game took an eternity to complete. Likewise, Half-Life 2: Episode 2 teased us with expectation until its eventual release, alongside Team [...]

Pattern: Lost Champion/Buyer’s Remorse »

This is a new pattern, one not explicitly called out in my original white paper (though hinted at in a few places).
Summary: A client starts a large IT project that involves one or more outside firms (consultants, vendors, developers, manufacturers). Within the client organization, a champion arises (or is appointed) for this project. The project [...]

Systems Failure Litigation: Lessons Learned »

[Adapted from Patterns in IT Litigation: Systems Failure (1976-2000)]
Having reviewed these cases and the patterns they exhibit, some practical suggestions come to mind.

Pattern: Unintended Consequences »

[Adapted from Patterns in IT Litigation: Systems Failure (1976-2000)]
Summary: The manufacturer makes some change in the functionality or configuration of the system, which is already in use. The change results in unpleasant or unintended consequences for one or more clients.

Pattern: Unplanned Obsolescence »

[Adapted from Patterns in IT Litigation: Systems Failure (1976-2000)]
Summary: The client buys a system from the vendor. Some time later, the client discovers that the system either no longer meet its needs or that the vendor/manufacturer will no longer support it.

Pattern: The Never-Ending Story »

[Adapted from Patterns in IT Litigation: Systems Failure (1976-2000)]
Summary: The client contracts with the manufacturer to develop and install a system. The project starts. The completion date slips. It keeps slipping. Each time the adjusted delivery date approaches, the project slips yet again. At some point, one of three things happens: the manufacturer/vendor abandons [...]

Pattern: Three’s a Crowd »

[Adapted from Patterns in IT Litigation: Systems Failure (1976-2000)]
Summary: This pattern actually lumps together two sub-patterns. In the first, the client purchases an IT system from the vendor by way of a leasing firm. The client is dissatisfied with the system and stops payment, whereupon the leasing firm sues the client. In the second [...]