Software engineering as it’s taught in universities simply doesn’t work. It doesn’t produce software systems of high quality, and it doesn’t produce them for low cost. Sometimes, even when practiced rigorously, it doesn’t produce systems at all. That’s odd, because in every other field, the term “engineering” is reserved for methods that work. What then, does real software engineering look like? How can we consistently deliver high-quality systems to our customers and employers in a timely fashion and for a reasonable cost? In this talk, we’ll discuss where software engineering went wrong, and build the case that disciplined Agile methods, far from being “anti-engineering” (as they are often described), actually represent the best of engineering principles applied to the task of software development.
Real Software Engineering
One comment
Comments are closed.
Great presentation.
The Boeing 777 engineers verified their models by actually stressing a 777 airframe until it broke. I assume that their models were implemented in software and that they did not have models of those models.
One colleague of mine, who was a nuclear engineer turned software engineer, said that large software projects are more like commissioning the Lewis and Clark expedition that like building a bridge.
Inability to model is one of the differences between software development and physics-based engineering. Another difference is the amount of pure discovery that has to be done in just about any software project.
Do Agile projects actually have higher success rates than projects that follow other methods (or no method at all)? I’d like to see some real data on that point.
It’s not clear to me that Agile projects succeed often enough to deserve the title of engineering.