Skip to content
Hallway
0:00 / 0:00

#softwareengineering#agile#heuristics

Software Art Thou: Glenn Vanderburg - Real Software Engineering

Zendesk

55K subscribers • 1 video on Hallway

YouTube
  • Recommended by 5 people: 3 on Hacker News, 1 on Lobsters and 1 curated list.
  • A classic. People kept recommending it from 2020 to 2026.
  • Presented by Glenn Vanderburg, VP of Engineering at First
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

34K views8 years ago5 recommendations

Software designTools and practiceSoftware architectureDesign patternsCode review and teamwork

Glenn Vanderburg compares software development with other engineering disciplines to define what a true software engineering discipline should look like.

The idea is spreading that perhaps software development is simply incompatible with engineering; that software developers are not, and never will be, real engineers. Glenn Vanderburg, VP of Engineering at First, takes a fresh look at what that really should mean for this field. With an extra 45 years of experience about the task of programming, and a broad survey of the varied different engineering disciplines, can we envision a future for a field of “software engineering” that is worthy of the name?

Why it's here

5 people recommend this

What people say. Highly recommended for its deep exploration of whether software development is engineering and how to apply real engineering principles to code.

Moments people linked to

hwayneon Lobsters • Recommends

Real Software Engineering
29View on Lobsters

awesome-talkscurated list on GitHubRecommends

Under “Software Development”

Real Software Engineering by **Glenn Vanderburg** (Software Art Thou 2018) 1:07:57
View the list

kmstouton Hacker News • Recommends

On “Why are we so bad at software engineering?”

This discussion reminds me of a talk given by Glenn Vanderburg ( link to this video ), wherein he explores the question of whether "software engineering" is or can really be engineering. Around the 27 minute mark, he quotes Billy Vaughn Koen, a nuclear engineer, as follows: "The Engineering Method is the use of heuristics to cause the best change in a poorly understood or uncertain situation within the available resources." That's hardly the end of the debate, and I'm still undecided, but it seemed worth lobbing in before hitting the rack.
View on Hacker News

modal-soulon Hacker News • Recommends

On “Old box, dumb code, few thousand connections, no big deal”

Saw an interesting talk just about this topic 1 The gist of it was: Other engineering disciplines use the techniques you've mentioned because of the the costs, both time and money, associated with getting it wrong. Software engineering lends itself to different methods of development and construction, as the costs associated with getting it wrong or making changes after the fact are much lower. (For most applications, anyways). As such, (this definition would be another sticking point) these less rigid methods should still be considered engineering, with engineering being a balancing of resources with outcomes, not fixation on mathematical models. 1: link to this video
View on Hacker News

ozimon Hacker News • Recommends

On “My 1992 view of the problems of computer programming in 1992”

…round like chickens without head, can’t even bother to learn how to use Excel properly. We have GIT, whole testing approach from unit to integration, team organization etc. Most of the world runs on software as is now and it works and there is much more software in the world than any other structures we built as a species. Bonus watching material: link to this video…
View on Hacker News

charles_fon Hacker News • Mentions

On “Agile's early evangelists wouldn't mind watching Agile die”

Agile is not a methodology or a process, it is literally1 a set of values and principles which can be summarized by "stop being stupid and trying to reproduce what they do in construction engineering, and start discussing about the why and collaborate, doing things that matter, and being flexible, since after all, we're doing _soft_ware. The set of methodologies and processes that ensued, as well as the entire industry of coaches, consultants, evangelists and "practitioners" was probably coming from a good place - trying to propose an implementation for how to put in place those abstract values and principles, or to help with that. The commercialization, envy and corruption that followed i…
View on Hacker News

ozimon Hacker News • Mentions

On “Formal methods: Just good engineering practice?”

Just wanted to post this video link in this discussion: Glenn Vanderburg - Real Software Engineering link to this video
View on Hacker News

u/SgtLionCobrain r/functionalprogramming • Mentions

On “is the functional/imperative divide real?”

In the later part of this video, Glenn Vanderburg delineated the divide between "platform" and "application" programming. If you haven't yet, watch the whole thing. It's such an eye-opener. I think our industry is moving towards a consensus that declarative and imperative approaches are both valuable tools to have. If you need performance, go imperative. If you need the ability to reason about your code, go declarative. With some discipline, mixing both is totally fine. Often we need to start out having to reason about our code easily, and declarative paradigms such as the functional one are a great default to start out with.
2View on Reddit