Ok, I'll go out on a limb and say no we don't. If you followup to the authors blog, he states: "At its core the theory relies on practices. Now there are goo

Ok, I'll go out on a limb and say no we don't. If you followup to the authors blog, he states: "At its core the theory relies on practices. Now there are good and bad practice concepts. The idea of practices has been around for fifty years, but these practices are loosely defined. We need a practice concept that is more precise." That doesn't seem to really drive home the need for a theory of software engineering to me. What we need is a better definition of what the craft of software requires (the practice of writing software) - not a theory of software engineering. Then we need to think about how we encapsulate those basics of software craftmanship in a way that we can communicate to each other and apprentice newbies into. There's still no silver bullet for managing software development. I recognize that in some ways, the author is pointing out that we tend to drop everything and reinvent the wheel every few years. But that's how the consultants make their money, right? Isn't incumbent on us (practitioners) to call BS when we see it? If the point of having a theory of software engineering is to stop the rush from one process to another, that's not going to stop the snake-oil salesmen. They'll just move on and talk about how the "theory" doesn't measure how much better the new process is because it is such a radical new process. I'm also curious about the number of successful software deliverables that are due to the software engineering process followed by the team that created the software. Anybody here feel like the most successful project you worked on was due to the specific software engineering process that was used?