Yes there was a time when software development meandered through more structured paths. In the seventies, seventy kilobytes of code was excessive. Even in the early eighties, I remember coding a real-time sonar positioning system based around the ubiquitous 8086/87 Intel chip-set with just 128KB of Eprom and 16KB of Ram. It even boasted 8 colour (yes 3 bit) graphics but with 512x512 pixels surpassed the early CGA standard set by IBM’s PC. In those days structured programming had more to do with pretty indented code listings. I remember one UK software house’s interview procedure involved asking candidates to bring with them a sample of code they had recently written. With expectations of line-by-line critique, the interviewee would watch as the interviewer would hold up the listing against a window and look for a sinuous pattern of Begins and Ends or { and }. Candidate suitability had more to do with pattern than complexities of procedure. It took another 10 years for the GOF’s software patterns to find favour and create a new movement. But at Yourdon in the mid eighties, I taught the work of Christopher Alexander and patterns as part of Yourdon’s real-time structured analysis and design seminars.

Structured is a powerful word. But it soon became tarnished and replaced with a new silver bullet – the object. Not long after the stock market crash of ’87 OO became a focus of the Yourdon office and many methodologies. Two camps had evolved, those that felt safe with structured and those that embraced the new wave. Smalltalk and Ada, Eifel and C++. OO languages demanded a new way of organising and the structure was the object. Soon OO design replaced structured design and then OO analysis did the same for SA. Ed Yourdon jumped ship and co-authored one of the first books about OOA with ex Yourdonite Peter Coad. But the UK market was a few years behind and more reactionary to these new approached. Investments by large companies like Rolls Royce, STC and Philips in structured techniques made it difficult to peddle a new wonder. Investment in both training and the CASE tools slowed OO adoption for many except the more nimble SMEs.

The methods wars of the early nineties did little to help foster OO. CEOs were not convinced by the arguments and OO became used from the ground up. OOP demonstrated progress and reuse decreased build time wining over project managers. With a shameless U turn, Ed Yourdon published his American Programmer as a vehicle for budding articles on OO. Ed would go on jumping the waves up until Y2K when his proclamations for doomsday proved him a soothsayer. Moore’s law underpinned OOPs success as it consumed ever more expansive memory and processor capacities. Class libraries moved from a few kilobytes to megabytes. Processor speed allowed code interpretation rather than compilation. GUIs like NextStep and Windows created yet more complexity and it soon became impossible for one developer to build and keep a complete understanding of all but the most trivial application. By ’95 when Java came on the scene the OO backlash had begun. Byte magazine proclaimed the end of OO and long live the component who was now king. By the time the three amigos had kissed and made up to back UML, OO had itself become tarnished just like structured only seven years before.

No surprises then that a replacement was waiting in the wings. The agile movement surfaced out of increasing frustration with IT projects grappling with the complexities of ever increasing code and business expectation. CEOs had been promised technological silver bullets for their business for over a decade and the ROI was still zilch. Why was this? No worries, the agile manifesto cried, we’ll deliver. And they did. Enlightened execs, exasperated at increasing budgets and missed release dates, tore up the process manuals and embraced pair programming. Niche consultancies flourished. IT symposiums hailed agile as the brave new world. Some may argue that an agile approach has more to do with people than process and I believe this to be so. Marketing hype oversold and under delivered the role technology could play in building itself. Case being the most obvious exemplar. If you strip away bureaucratic procedures, empower development teams with business expertise and are driven with belief it’s difficult to see how competent teams could fail. Many without these qualities did fail. I remember, as many will, IBM’s ill-fated San Francisco project and the demise of Taligent. Which will be next?