Click here to monitor SSC

Simple-Talk columnist

Methodology Agnostic

Published 12 September 2013 4:42 pm

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.

15 Responses to “Methodology Agnostic”

  1. Robert Young says:

    I wonder: have you ever been told, by the hiring agent, “we only do, at least, 3NF database systems, and let the client side code however it desires”? Doubt it, but being a Database Oriented site, I had to ask.

  2. amr.attia says:

    I believe the methodology totally depends on how much the business requirements are stable and deterministic. In case of clear and minimal change of requirements the water fall will be the better choice but in case of rapidly changing requirements based on prototypes feedback then you must go for Agile.

  3. ilias says:

    I notice that the choice of methodologies roughly translates to –

    Agile = “We do not really plan anything”
    Waterfall = “We mess about in Microsoft Word for a bit before we start coding”

    In the end, if you distill it all down to the basics, its all about planning well, executing those plans well and testing thoroughly, with a huge dollop of common sense at every stage, irrespective of the stated process.

  4. willliebago says:

    I wonder which one of those software houses in the east end of London it is? :)

  5. sfkleach says:

    Although I agree with the sentiment of ‘the jobbing programmer’ being flexible and working within the established conventions of their employer, I don’t agree that ‘waterfall’ has become merely a pejorative term. The better reading is a synonym for ‘phased-gateway’ development, where the transition between distinct activities is marked by a ‘gateway’ event. To interleave the activities is a challenge and usually requires a new set of tools and skills, not to mention a good deal of initial trust that the effort and expense of tooling-up will pay off. So I would contend that it is not so much a matter of belief as not wanting to take on the costly change resistance of a new employee who may be (not unnaturally) skeptical. To paraphrase, it’s not religion, it’s business.

  6. gmccarrolle21 says:

    I love it! Why do interviewers continue to use the same old questions when the world has moved on? I like you realize that waterfall in the true sense never really was, maybe on paper. But, in the real world programmers and development staff adapted and used tools and methods that best fit their needs. Thanks for exposing this for everyone.

  7. jkeefe says:

    Surely “agnostic” is the proper term to use here. The truth statements of any organized methodology will almost always involve the blind acceptance of some external authority (the “higher power” if you will) while carefully ignoring any and all evidence to the contrary.

    My personal favorite interview question of all time was “How do you eat an elephant?” Of course, the correct answer is “one bite at a time” although I carefully added “with horseradish and and a nice side salad.” I didn’t get that job and I’m really glad I didn’t since that company was no more within 18 months of my interview.

  8. paschott says:

    Done well, I really prefer the Agile methodologies because they get relatively rapid feedback from the end users (or at least the product owner/manager). I’ve worked on too many projects where the requirements were set up front, we disappeared to deliver those requirements, then when we finally presented them after many months of work the actual needs had changed or perhaps even passed. Even worse was working on a waterfall-style data warehouse project. Months to spec out the project, more months to work on it, then when it’s finally presented we realize that we’ve been working on the wrong metrics even though they were what the business said they wanted. Had we done that in a more agile style, we would have been able to develop the smaller dimensions and a fact table or two then present and adapt.

    Admittedly, those show more of a business problem than a problem with the methodology chosen. If the business truly understands their needs and can communicate those well, then it doesn’t matter what methodology is used to deliver.

    I tend to agree that some sort of design up front is still essential for any methodology. Knowing where we’re going drives a lot of decisions in database design, storage, coding, etc. Sometimes it even drives a conversation to point out that the desired design isn’t realistic given current technological constraints. I know I’ve seen several presented designs that would have resulted in a lot of problems had we tried to implement them. That time spent in design is well worth any perceived delay.

  9. jerryhung says:

    I’m glad I’m a DBA and not Developing anymore.
    I don’t understand all the “fancy keywords” or how they actually help on the productivity.
    If you can develop/produce, you just can;
    If you cannot, then you cannot

    I’ve seen Agile at web start-up and after a while it just doesn’t go anywhere or do anything, as everyone is back to do whatever he wants to do, while the company waits for everyone anyway

  10. Patrick Index says:

    I have to say that I do miss the older methodologies as they used to produce something called a “specification”. We also had people called “business analysts”. I don’t know about you but I haven’t seen the slightest trace of either of these things for probably 20 years. Seen plenty of project managers and program managers though, hundreds of them in fact all talking drivel of course…..

    • Patrick Index says:

      Is KISS a methodology? If it isn’t it should be. I do see it adopted in its alternative form very often however i.e. keep it stupid simple.

    • paschott says:

      We still have specs and BA’s when using Scrum, but the specs are often broken down into smaller pieces so we can deliver about every 2-3 weeks. (Even if not enabled for our customers yet.) We had some pretty detailed requirements from our BA’s for the specs and those covered a lot of possible scenarios. It all depends on the environment. If people just think Agile means get stuff done faster, they’re missing the point. A main benefit is to be able to make better software through more frequent feedback. The same could be done in “waterfall” methodologies, but I rarely saw that happen.

  11. Patrick Index says:

    My preferred methodology is of course JUSCSFCS which hardly ever seems to be used now and it stands for JUST USE SOME COMMON SENSE FOR CHRIST’S SAKE.

  12. aleonard763 says:

    I believe methodologies are a tool. Programming languages are also a tool. Tools, in the hands of those who know how best to use them, can be used to produce great works. And that is the key: Ask any programmer proficient with a set of tools to develop a solution and they will use the tools they know to do so. It is a combination of programmer and tools and skill that accomplishes this.

    :{>

  13. Keith Rowley says:

    But programming methodologies are treated like religion by some people. Who are we to say they are wrong and life really isn’t all about Agile programming? JK :-)

Leave a Reply