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.