Methodologies at a High Level

[Part of the Cliffs Notes of Software Development Series]

Merriam-Webster's definition: a body of methods, rules, and postulates employed by a discipline : a particular procedure or set of procedures

So it's how we do things in this industry. Set aside the fact that our industry hasn't figured out a standardized set of methods and rules yet. While other disciplines have had thousands of years to mature, ours isn't even a generation old yet. Not for lack of trying though - we're cranking out new names of methodologies every few years. Sometimes it's just slapping a different label on an old trick, and sometimes it's a genuinely new idea.

These are the most popular methodologies used over the last couple decades:

90s: CMM (Capability Maturity Model), RUP (Rational Unified Process). These were document-oriented techniques that valued heavyweight specifications and processes over human interaction. Each cog in the wheel wrote down what they wanted in an isolated fashion and handed it off to the next party with the expectation that what came back was what they wanted.

late 90s and early 00s: The inception of the Agile movement and its name brands Scrum, eXtreme Programming threw out a lot of the heavyweight process, with an emphasis on the human factor. Their prescriptions are a much shorter list of project guidelines, with some or all of them marked as optional.

mid 00s to today: The above flavors of Agile are the current mainstream choice, along with the somewhat recent additions of Lean and Kanban. Lean and Kanban are direct translations of the auto-manufacturing process, where the goal is to not be wasteful and do what's needed just in time.

What I've said so far is mostly factual. Now for some contextual and subjective quick answers...

So these are the "formal" techniques for making software. You might then wonder how much a particular methodology choice can influence the success (or failure) of a project. In my opinion, not much.

What? How could it not matter much?!!

Before denouncing heresy or ignorance, remember that the software industry is still in an infantile state. We're constantly reinventing the wheel as we arrogantly proclaim the code we just re-wrote to provide the same business function for the last 40 years is once again completely obsolete and needs to be re-written from scratch. We're evolving, yes, and these methodology changes are improving our chances (usually). But the single most notable trait of the recent methodologies is to emphasize the human aspect of the software development process. To err is human. In other words, we know we're a bunch of screw-ups, and the best idea we have so far is to fail as early as possible. Not to scoff at that idea - it is an improvement...the trouble is that we're still failing when we get to the finish line far too often. Don't blame the methodology though, blame the people that didn't do the project right. To put it in kitschy terms: Methodologies don't screw up projects, people screw up projects. More on that in the "It's All About The People" article.

This opinion of methodology isn't anything new, although it's not the norm, especially among those that aren't master software builders, or have something to sell you. I'm sure many professional methodologists would have a problem with what I just said as well. But the funny thing is that the best ones wouldn't.

As an example, what's going to be the next evolution of methodology? Jeet Kune Do! "My style is no style."

Just kidding! Actually, I'm not. Alistair Cockburn (one of the world's best software guides) is starting to teach Shuhari. In layman's terms, when you're a master, you don't need the instruction manual. His Oath of Non-Allegiance request is another example that our trade doesn't yet have the maturity to define a standard on how to create software.

In summary, my advice on methodologies is that you shouldn't worry about any particular name brand. It doesn't really matter. There are definitely some very helpful and specific activities you can do during the process, and for that consult your local (or bring in) experts for guidance. I'll discuss how to find the right people in more detail in another article on this series. Just remember, it's all about having the best resources staff people.