Methodology Fundamentals
From Mp
Contents |
The Problem
The design of a software development methodology is typically something that is done by experts, documented within a book, made part of a commercial product, explained on a website, or otherwise discussed, tweaked, followed, tailored, evangelized, hated, etc. However, it's unfortunate that many software developers don't spend more time understanding the process they follow, giving them the basic understanding of how it works, why it works, and how to make it better.
It's unfortunate that there are not more experts. Technologists are too busy learning a new language, a new library or framework, or upgrading their IDE, OS, or hardware. Part of the problem is that it is not considered a problem: that is, the fact that the software development methodology that most developers use is probably not appropriate for the project they use it on. And they don't realize that it makes much of a difference.
Methodologies get created by experts who poke their head up, find they don't like the methodology they're currently using, and set about to think of a better way. They may even test some of their ideas on projects. Then, it's put into practice, written in a book, put on a website, and they start convincing others of what they find.
Typically, it's reactionary to what's been done before. They take the common sense approach. Not all is wrong with what was done before, so they remove what they don't like and add what they do.
First Principles
The problem with this is that it doesn't approach the "first principles" of what they're really trying to do. What truly are the fundamentals of a software development methodology? Where do you really start? Upon what foundation should a process be defined?
It is The Core Process. This process (and model) is the basis for any development methodology, as it defines both what is necessary and what is sufficient. It is enough, but no more.
Motivations
With The Core Process defining the fundamental aspects of a methodology (Requirements, Build, and Publish), why is there a need to add anything to that? No one is going to build software following only those three aspects. They're going to have to add more, such as design, testing, etc. What's the real motivation behind adding?
Obviously, it's the need for some acceptable level of quality. The lack of quality comes from human error. Understanding the types of human error helps to define what needs to be added to "make up" for those errors. In software development, human errors fall into a number of broad categories:
- Communication (whether human-to-human or human-to-computer)
- Memory failures (I forgot to do this or that)
- Lack of understanding/capability (I don't know how to fix the problem)
- Human limitations (I can't do that fast enough)
Practices are designed to target these types of errors. For example, requirements elicitation is designed to ensure that what is wanted is what is built. Requirements traceability also helps with the communication issue. Defined processes helps with memory failures, with technology solutions providing help in making up for a lack of understanding or capability.
Understanding these errors means you have the ability to target them. Different cultures may experience different errors within those categories, and hence, would need different practices to target them. Much of process improvement is about identifying "error types" that are occurring and adjusting the process to "fix" the problem.
When practices are followed that "solve" a particular error that doesn't need solved, then efficiency goes down. In other words, you're fixing a problem that doesn't need fixed. Some would argue that all errors can happen, and that's correct. However, quality is only half of the driving motivation. Quality adds to the methodology (to the core process). Cost removes from the methodology, taking out those things that, though they may improve the quality of the end product, don't justify their value because of their cost. Adding anything to The Core Process adds cost (or, more specifically, it's "candidate cost"). It's fair game to remove. The "fine line" is between quality and cost. Part of the art in software development is identifying those things that, in your particular circumstances, cost more than the value they provide (or, identifying cheap ways of adding more process to improve quality but still justifying the cost).
Current Methodologies
There is a difference between a methodology's practices (i.e. pair programming, an artifact's template, review process, etc.) and the methodology itself. In fact, a methodology is really only the grouping of its practices around its core process model, with defined principles (i.e. goals, values, etc.) and parameters (i.e. particular constraints that are assumed, etc.) thrown in to justify it. In some cases, a methodology is consistent within itself, and provides value for the particular project types it's used upon. In some cases, however, it's not consistent within itself (meaning, it has practices that don't relate to the principles and parameters it defines), which causes inefficiencies and problems, regardless of the project types it's used upon.
Since no one methodology can be applied to any project, why use an off-the-shelf methodology on all projects? Certainly, a little tailoring may occur, but is that really sufficient? One of the problems with this has to do with the problem of not understanding the underlying structure of the chosen methodology, with "tailoring" done that could potentially create an inconsistent methodology, causing problems.
If the methodology is designed in the first place, then the underlying structure will be understood and taken into account during tailoring and process improvements. However, process improvements outside the context of understanding the existing underlying structure or without an understanding of how to design methodologies in general, even though based upon accurate and interesting metrics or facts, are fraught with danger.
In most cases, the danger is minimal, because the damage to efficiencies is small. For example, putting an incorrectly sized and designed luggage rack on a car (i.e. it's mismatched with the car it's being mounted on) will cause damage, because it will effect the airflow around the car. However, the damage is minimal, and will mostly effect the gas mileage of the car. Start putting the wrong kind of engine parts in, and the damage begins to increase.
