Lone Star Ruby Conference 2010 Real Software Engineering by Glenn Vanderburg

Confreaks · 30K views · 2011 · 51:57

Open on YouTube

Software practice, open source & careersPython, Ruby & scripting languagestalk

Why Hacker News recommends it

HN recommends it for changing minds about whether programmers can be called engineers, and for its take on how waterfall was misread.

What it is

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.

Recommended by 3 HN commenters across 4 different months, 2013 to 2025.

What Hacker News said

Strong rec yesenadam · 2020-05 · on “The most prized degree in India became the most worthless”

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?

Recommends KaeseEs · 2013-04 · on “Ask HN: What's the best technical talk you've heard?”

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 so

Recommends gcandal · 2016-01 · on “Managing the Development of Large Software Systems (1970) [pdf]”

I first came into contact with this article via [this video] , which is a pretty decent analysis on how people misinterpreted the original concept.

Recommends yesenadam · 2021-05 · on “Programmers: Stop Calling Yourselves Engineers (2015)”

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? I

Cites nayuki · 2020-06 · on “Are We Engineers?”

This talks about the same topic: Lone Star Ruby Conference 2010: "Real Software Engineering" by Glenn Vanderburg: [this video]

Cites nayuki · 2021-04 · on “The Myth of the 'Waterfall' SDLC (2019)”

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 nayuki · 2025-01 · on “Engineering "home-cooked" software”

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