Nowadays, as an old fogey, young developers spot my grey muzzle and like to sit me down and explain in detail how Agile and development practices speed and empower development teams, and that DevOps processes are revolutionizing the speed and quality of application delivery.

"Not so fast..." I start. "Oh sorry. Do we need to explain it a bit more, slowly?", they ask, solicitously.

"Thanks, but no. I meant 'not so fast as it used to be'. Projects take longer than they did. The functionality is delivered more frequently, but in smaller packages."

This is a test to see whether the scientific approach has lapsed into dogma. Have I uttered a heresy? If so, are we, as software developers, scientists or priests? I could be entirely wrong in challenging the current orthodoxy, but that is not the point. My concern is that we've lost the science of software engineering, and for improving team productivity in development. Instead, it has become an act of faith that we have somehow, by evolving a particular 'modus operandi', broken through all the blocking factors in application development that have held up the delivery of applications.

That's not enough. Like any scientific, engineering, or technical idea, it needs to be tested against reality. It needs to be constantly challenged. It is not enough for marketing people to wave their arms around and insist that it's the ideal way. If that was the case, we'd see, across the whole industry, a noticeable fall in the number of humiliating failures in technology, or a rise in the delivery of innovation. More than that, we'd be somehow able to measure it objectively, and prove the point.

It is wrong to assume that all Software engineering used to be slow. In fact, some took very little time by our current standards. Curiously, some of the most rapid innovations Information Technology so far have been done by small core groups of very clever people, given unique opportunities at the perfect moment. All these factors must be in place. The results come fast. The Xerox Star, Unix, Lotus 123, Sybase, Wordstar, Microsoft Word, CP/M, Postscript, Pascal…the list is a long one, and I mention these only because I know about their history. They were all designed and written, originally, by fewer than a handful of very clever people very quickly and informally. Sure, they mostly support teams for specific tasks, but the core development team was small.

Although I love to examine the detail of IT initiatives that went well to find out why, my interest is in project autopsies. In engineering and construction, for example, failure is examined in forensic detail to determine the lessons to be learned, even if nobody dies. If we want to claim maturity as a profession, we need to be more assiduous in looking at IT disasters in detail, with the same objectivity, and build a bank of evidence-based best practices, learned in the school of hard knocks. In short, we need to act as scientists, not a priesthood.