Glenn Vanderburg argues at Lone Star Ruby Conference 2010 that university-style software engineering does not work, and asks what real software engineering would look like. He revisits the waterfall model and what engineering means in other fields.
Why Hacker News points people here: HN recommends it for changing minds about whether programmers can be called engineers, and for its take on how waterfall was misread.
“I always thought calling programmers engineers was very weird until I watched this great talk”HN comment, 2020
“I always thought calling programmers engineers was very weird until I watched this great talk”
Explains what engineers actually do and why programmers qualify.
Full comment
I always thought calling programmers engineers was very weird until I watched this great talk: Real Software Engineering , Glenn Vanderburg, Lone Star Ruby 2010 this video which explains what various kinds of engineers actually do. Not at all dry and boring like it might sound! From the YouTube blurb: 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?
RecommendsKaeseEsApr 2013
“a very good exploration of how some of the common beliefs in the field of software”
Explores where software engineering went wrong and what real engineering looks like.
Full comment
Real Software Engineering, by Glenn Vandenburg. Not a perfect talk (especially the conclusions IMO), but a very good exploration of how some of the common beliefs in the field of software "engineering" came to be, and how something resembling actual engineering practice might be beneficial and practical. Link: this video Abstract: "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 session, 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."
RecommendsgcandalJan 2016
“which is a pretty decent analysis on how people misinterpreted the original concept.”
Analysis of how the waterfall paper was misinterpreted.
Full comment
I first came into contact with this article via this video , which is a pretty decent analysis on how people misinterpreted the original concept.
RecommendsyesenadamMay 2021
“until I saw this great talk”
Changed commenter's view on calling programmers engineers.
Full comment
I thought calling programmers "engineers" was very odd until I saw this great talk: Real Software Engineering by Glenn Vanderburg Lone Star Ruby Conference 2010 this video 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 session, 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.
Cites itnayukiJun 2020
“This talks about the same topic”
Talk on the same topic.
Full comment
This talks about the same topic: Lone Star Ruby Conference 2010: "Real Software Engineering" by Glenn Vanderburg: this video
Cites itnayukiApr 2021
“This talk describes how the waterfall development model was a caricature that got accidentally turned into reality”
Waterfall was a caricature accidentally turned into reality.
Full comment
This talk describes how the waterfall development model was a caricature that got accidentally turned into reality: this video "Lone Star Ruby Conference 2010 Real Software Engineering by Glenn Vanderburg"
Cites itnayukiJan 2025
Linked in context of engineering software discussion.
Full comment
I would say that this blog post is half right. The half that's not right is glaring. > the pyramids have had 100% up-time with no human maintenance It helps that there is hardly any rain in the desert. Water would foul up the structure in a matter of years. > dependencies are added like seasoning. Hundreds of packages. Thousands of foreign lines of code make their way onto your software routinely True, and I think NPM JavaScript exhibits the worst of this behavior. > Problems are expected and fixed on the fly, somewhat haphazardly: ... push a patch ... code scanning ... dependa-bot ... DevOps True, and I remember when software releases were treated with much more care and quality because it costs a lot to ship a CD or game cartridge rather than a download. > More waterfall-y. That's not a good thing. Having a short feedback cycle from implementation back to design is a big win for software development. Waterfall is the dark ages when we didn't know better. > This is where minimalist software is built. Agreed. > No build process That doesn't make any sense, unless you're writing machine code directly in hexadecimal. > no outside dependencies I agree with minimizing dependencies, but there's no such thing as no dependencies. I dare you to avoid any of these libraries: HTTP (especially HTTP/2 and 3 which are much harder than HTTP/1), TLS/SSL, TCP/IP, hardware drivers, compilers, data codecs like DEFLATE, multimedia codecs like AVC and AAC. > There's no need to be constantly refa
