My instructor told us that some programmers are not using SDLC methodologies for making a system. Because in our project, we used one of the methodologies. If we do not use one of them, maybe our system will not work.

How does what I'm learning now relate to what I can expect in my future life as a programmer? How common are SDLC methodologies in the industry?

  • This is a question for programmers, not for computer scientists, so I'm migrating it to a site where the audience is programmers. – Gilles 'SO- stop being evil' Dec 17 '14 at 23:29

What a big-M Methodology buys you is that you can ensure the following things:

  • You understand what the customer wants. (Remember, customers don't always know what they want.)
  • The customer knows exactly what you have promised to deliver and when.
  • You know what you will be able to deliver and when.
  • The customer will be able to see progress as it happens.
  • Neither the stuff that the customer cares about (e.g. features), nor the stuff that you care about (e.g. quality), are neglected.
  • You can see as early as possible if something will prevent you from delivering what you promised and when, and gives you options as to you can do about it before it's too late.
  • The system stays in a reasonably high-quality state most of the time, even if not all of the features are there.

These are the things which separate a coder from an engineer. An engineer builds things to order with high-quality, with respect to time and budget constraints. Adhering to a Methodology keeps the customer in the loop, and keeps you honest and on track.

Now here's the dirty secret.

Student projects are the best time to follow one of these Methodologies to the letter, because they are one of the very few real-world situations where they work exactly as advertised. The actual practice of software development has always been messy and always will be messy, because the demands are messy.

I'm going to refer you to the classic paper on this topic by David L. Parnas (who else?) and Paul Clement, A Rational Design Process: How and Why to Fake It. This should be required reading for every software engineering student right after they have tried applying a SDLC methodology to a project. The world has changed a lot since 1986, but the advice has not.

You see, the real world is on a continuum. Some projects are so small, so low-risk, or so skunkwork-like that Methodology-free "cowboy coding" is a realistic option. At the other end, with safety-critical or mission-critical systems, the risk of failure is so high that methodologies are rigidly adhered to or else.

Most software development is somewhere in the middle. So the idea is to develop as you need to, but make it look as if you followed a Methodology. No, that doesn't mean doing all the fakery at the end, you must do it as you go. If you're being agile-like, for example, once per sprint is common.

The process of faking it forces you to do the dotting-of-i's and crossing-of-t's that the Methodology demands. In return, you get the best of both worlds: the flexibility of cowboy coding and the quality of a Methodology.

| improve this answer | |
  • 2
    Your claims about coder vs engineer are at odds with reality, even under strictly defined procedures software has all kinds of issues, see programmers.stackexchange.com/questions/158640/… for some examples. No methodology can replace the good judgment of a skilled developer. – whatsisname Dec 18 '14 at 4:03
  • It's absolutely true that no methodology can replace the judgment of a good developer. A good methodology complements developer judgement. But, of course, this is just the ideal. There are no good methodologies. – Pseudonym Dec 18 '14 at 5:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.