I once went for an interview at one of those software houses in the east end of London, serving the many financial institutions around the City. It wasn’t an easy interview. I’ve forgotten all of the questions except one.

“Have you ever used the Waterfall Methodology?”

“As I take my shoes from the shoemaker, and my coat from the tailor, so I take my methodology from the project manager.” I replied, with a smile. I’d assumed that he was joking and I’d replied in kind, paraphrasing Oliver Goldsmith’s famous saying.

He looked at me pityingly, as if he was thinking of Samuel Johnson’s retort, “Sir, he knows nothing; he has made up his mind about nothing.”

“Call me an old fool,” I added, “but surely Waterfall is just a pejorative term for all the standard non-RAD methodologies that predate Agile. There never was a Waterfall system. I reckon I’ve used all the major ones, at one time or another and they required neither a surrounding belief-system, nor special human characteristics to participate. They all had their strengths and weaknesses.”

He regarded me, silently. After a few moments, I realized that what I’d said had whizzed past his ear, and for all I know, embedded itself in the wall behind.

“Be that as it may,” he said, finally, mentally marking me down as not a team player, “we’re an Agile shop, and we develop lean applications in response to the rapidly changing requirements of our clients”.

I shrugged. I imagine that the Gadarene swine took their final leap whilst thinking “well, at least we’re getting somewhere with this project”.

Throughout my career, I’ve always learned to adapt to whatever methodology is around, be it Prince, SSADM, SDM, CSC Catalyst or whatever. It is part of the job. As a jobbing programmer, one could not draw oneself up to one’s full height and say, “I’m an Agile developer”, if one wanted the work. Hence, in the same way that Goldsmith shunned any controversy or debate over religion, so the seasoned developer avoided picking sides in the debate over methodologies.

All the classic approaches to commercial software development were ‘predictive’, in that by fleshing out the design as much as possible they sought to ensure that there weren’t any nasty surprises once development started. The young computer industry adopted many of its techniques from existing, well-tried methodologies used for the design and development of complex machines, structures, aircraft and automobiles.

Design-first seemed common sense then, hence the ‘waterfall’, and instinctively I’m still a BDUF (Big-Design-Up-Front) guy. However, if someone discovers a quicker way to deliver good maintainable software, I’m keen to give it a go, remembering that this ain’t religion, it’s science.