8 ms·

Software developers describing their work in 1973 [video]

112 points by velmu 11y ago

y04nn 11y ago
Things seems to not have changed so much. We spend more time designing and planing things that it takes to implement them.
pcunite 11y ago
https://youtu.be/AxSdWhkMB_A?t=3m55s https://youtu.be/AxSdWhkMB_A?t=3m55s "Q: What are the cons of your profession? A: Almost every application that is being made ends up lagging in schedule, regrettably."
- smtddr 11y ago
  The more things change, the more they stay the same :)
madflame991 11y ago
"Almost every application that is being made ends up lagging in schedule, regrettably" I'm grateful, of course, for the technological progresses we've made since '73, but how come this is still an issue?
- tomschlick 11y ago
  Feature creep, over optimistic estimates, business needs changing, and misunderstanding the requirements would be at the top of my list.
- elros 11y ago
  > ... for the technological progresses ... You've answered it yourself :-) It's not a technical problem, it's a social issue.
- ghaff 11y ago
  This describes pretty much every type of project ever. Not saying everything lags 100% of the time but most significant projects miss initial schedules. Software has some unique characteristics to be sure, but it's not atypical. (And things like large construction projects tend to be even worse.)
- an0nym1ty 11y ago
  I once had a mentor who was fond of saying "Git doesn't solve human problems", in reference to git-conflicts while explaining the system to less technical team members. Technological advancements have, to this point, had fairly limited effect on mitigating error in human input.
- pcunite 11y ago
  Application creation (programming, design) are creative processes. If you want a brick wall, you sum up the materials, job size, and labor. Not so with software.
  - talles 11y ago
    And I'm really glad that it is. At the end of day that's precisely the joy of this field. Else it's just a job.
- laotzu 11y ago
  Because the high level business model remains the same. Seeking perpetually increasing short term profitability instead of long term sustainability. Carrot on a stick.
  - oldmanjay 11y ago
    This is such a popular misconception amongst the nerd set. Perhaps because there's a great us v. them narrative implicit in it. I suspect what initially birthed it was a basic misapprehension common to people who have great faith in their own intelligence and opinions - that of needing to ascribe stupidity to people who don't seem to share viewpoints. I won't bother citing because it's literally overwhelming, but it's pretty clear that there are many companies producing software with the long-term view in mind, and I bet every single one of them is subject to schedule issues. I've certainly been on teams with long-term thinking embedded in the process and spent time explaining delays, which is of course merely an anecdote, but rather suggestive of things not being as black and white as you'd like to present them. edit: minor wording cleanups
    - smaudet 11y ago
      'such a popular misconception amongst the nerd set' Um, maybe its just been the places I've worked at, but I've been repeatedly told "we should ship software rather than get everything perfect". I agree, at the same time, most if not all of the problems I've encountered (including ones I've built for myself) have been because of this impatience.
    - deleted 11y ago
      [deleted]
- ashark 11y ago
  No-one's willing to take the huge amount of time it takes to design a software system and accurately estimate how long it will take to build it. They're happy to pretend good estimates are possible without that, though, and complain endlessly about how bad estimates always are.
  - nightski 11y ago
    It's a self fulfilling prophecy. It's because this is not possible, since often software is a never ending journey. Today's requirements are not tomorrow's requirements. If only we could freeze time.
- Eridrus 11y ago
  a) Estimates are made when the least information is available. b) Developers are bad at estimating the unknown unknowns that will bite them. c) Padding estimates is somehow seen as a bad thing, probably due to... d) Business pressures that incentivize everyone to quote the earliest possible date something could be ready, rather than the date it will most likely be ready.
  - TeMPOraL 11y ago
    I really think d) is the most significant one here. It's pretty visible if you look at the problem structure. In a competitive environment, the first one to give a solution wins, at least initially. Since it's easy to hide bugs and unfinished features for the release, the ones who skip proper design will ship faster and thus win and preserve on the market. "Good solution today is better than perfect one tomorrow" turns into "worst solution that's still acceptable today is better than decent enough solution tomorrow".
- bkeroack 11y ago
  https://en.wikipedia.org/wiki/Planning_fallacy https://en.wikipedia.org/wiki/Planning_fallacy
- datashovel 11y ago
  Most of it is not a technology problem. Most of it is a human problem. Humans are not as good as we think we are at communicating in precise details with others.
sosuke 11y ago
"at least two natural languages" I'm half that good! It seems like our profession hasn't changed much at all. Makes me feel like I'll be well prepared for the workplace 40 years in the future.
- newjersey 11y ago
  My favorite part was when he answered he has a high school diploma. He mentions he has five years in university but all you really need is a high school diploma. As someone who spent five and a half years (first four for a BS mathematics degree and a year and half for BS computer science degree) as an undergraduate student, it makes me happy to hear professionals say that. K-12 school is just as important as ever. I just wish we started second language instruction at lower grades. It could be Spanish, French, German, Mandarin... It'd be nice if we started much earlier.
khoury 11y ago
Oh god... just as depressing as it is today.
drzaiusapelord 11y ago
"A negative side is that the work is extremely tiresome, and there are pressure problems all the time. Mental health problems are well known in this business." Is he suggesting this work is the cause of mental health issues? Seems to me almost every techie I know has below average mental health. Chicken-egg problem here.
- settings 11y ago
  I took that as his implication. In my experience there is also selection bias.
- smaudet 11y ago
  Hmm. If mental health precludes the ability to think logically, then what does that say about the supposed mental 'health'. If, conversely, healthier people are more logical, then maybe they should be programming instead? Conundrum.
lordnacho 11y ago
The guy makes it sound like he's just making whatever the designer tells him, like a robot. In reality there's a lot of back-and-forth. This is easy, this is hard, this is impossible, we should reorganize this or that, some development path requires more investigation, etc. If I was a kid watching this I'd conclude it was stressful and subservient.
johansch 11y ago
Because he's finnish it reminds me of this 1993 video of Future Crew making the PC demo "Second Reality": https://www.youtube.com/watch?v=LIIBRr31DIU?cc_load_policy=1 https://www.youtube.com/watch?v=LIIBRr31DIU?cc_load_policy=1 (There's high quality english subtitles there.) Finished product: http://www.pouet.net/prod.php?which=63 http://www.pouet.net/prod.php?which=63 https://www.youtube.com/watch?v=rFv7mHTf0nA https://www.youtube.com/watch?v=rFv7mHTf0nA
msarnoff 11y ago
The video was posted by an awesome demoscene dude named viznut. Check out the rest of his channel. Experimental music from very short C programs: https://www.youtube.com/watch?v=GtQdIYUtAHg https://www.youtube.com/watch?v=GtQdIYUtAHg Robotic Liberation (VIC-20 demo): https://www.youtube.com/watch?v=2SdGkkp1aq8 https://www.youtube.com/watch?v=2SdGkkp1aq8
nebulous1 11y ago
Bret the Hitman Hart gave some insight into the games industry in the 90s: https://www.youtube.com/watch?v=EfdIGG36GgU https://www.youtube.com/watch?v=EfdIGG36GgU
- kolanos 11y ago
  Hearing a wrestler say "you dereferenced a null pointer" made my day.
  - OJFord 11y ago
    (1:40)
- nickpsecurity 11y ago
  Dude that was great. I second the null dereference line. How the heck did I not see this back when I was enjoying how advanced and fun this game was? Note: Probably playing it and the other classics too much haha.
flurpitude 11y ago
Too much pressure, too many meetings, projects coming in behind schedule. Must have been awful in those days. Do all those people look like they actually hate their jobs, or is this just a Finnish manner?
edpichler 11y ago
This video is incredible! Many years later, and we are still struggling to solve the same software engineering problems, per example, project delays. The video also shows that, in 1973, the requirements changed all the time. People had a lot of meetings, and they think that programming is a lot about teamwork and collaboration. Requirements analysis, before it had this name.

112 points by velmu 11y ago

y04nn 11y ago

Things seems to not have changed so much. We spend more time designing and planing things that it takes to implement them.

pcunite 11y ago

https://youtu.be/AxSdWhkMB_A?t=3m55s https://youtu.be/AxSdWhkMB_A?t=3m55s "Q: What are the cons of your profession? A: Almost every application that is being made ends up lagging in schedule, regrettably."

smtddr 11y ago
The more things change, the more they stay the same :)

madflame991 11y ago

"Almost every application that is being made ends up lagging in schedule, regrettably" I'm grateful, of course, for the technological progresses we've made since '73, but how come this is still an issue?

tomschlick 11y ago
Feature creep, over optimistic estimates, business needs changing, and misunderstanding the requirements would be at the top of my list.
elros 11y ago
> ... for the technological progresses ... You've answered it yourself :-) It's not a technical problem, it's a social issue.
ghaff 11y ago
This describes pretty much every type of project ever. Not saying everything lags 100% of the time but most significant projects miss initial schedules. Software has some unique characteristics to be sure, but it's not atypical. (And things like large construction projects tend to be even worse.)
an0nym1ty 11y ago
I once had a mentor who was fond of saying "Git doesn't solve human problems", in reference to git-conflicts while explaining the system to less technical team members. Technological advancements have, to this point, had fairly limited effect on mitigating error in human input.
pcunite 11y ago
Application creation (programming, design) are creative processes. If you want a brick wall, you sum up the materials, job size, and labor. Not so with software.
- talles 11y ago
  And I'm really glad that it is. At the end of day that's precisely the joy of this field. Else it's just a job.
laotzu 11y ago
Because the high level business model remains the same. Seeking perpetually increasing short term profitability instead of long term sustainability. Carrot on a stick.
- oldmanjay 11y ago
  This is such a popular misconception amongst the nerd set. Perhaps because there's a great us v. them narrative implicit in it. I suspect what initially birthed it was a basic misapprehension common to people who have great faith in their own intelligence and opinions - that of needing to ascribe stupidity to people who don't seem to share viewpoints. I won't bother citing because it's literally overwhelming, but it's pretty clear that there are many companies producing software with the long-term view in mind, and I bet every single one of them is subject to schedule issues. I've certainly been on teams with long-term thinking embedded in the process and spent time explaining delays, which is of course merely an anecdote, but rather suggestive of things not being as black and white as you'd like to present them. edit: minor wording cleanups
  - smaudet 11y ago
    'such a popular misconception amongst the nerd set' Um, maybe its just been the places I've worked at, but I've been repeatedly told "we should ship software rather than get everything perfect". I agree, at the same time, most if not all of the problems I've encountered (including ones I've built for myself) have been because of this impatience.
  - deleted 11y ago
    [deleted]
ashark 11y ago
No-one's willing to take the huge amount of time it takes to design a software system and accurately estimate how long it will take to build it. They're happy to pretend good estimates are possible without that, though, and complain endlessly about how bad estimates always are.
- nightski 11y ago
  It's a self fulfilling prophecy. It's because this is not possible, since often software is a never ending journey. Today's requirements are not tomorrow's requirements. If only we could freeze time.
Eridrus 11y ago
a) Estimates are made when the least information is available. b) Developers are bad at estimating the unknown unknowns that will bite them. c) Padding estimates is somehow seen as a bad thing, probably due to... d) Business pressures that incentivize everyone to quote the earliest possible date something could be ready, rather than the date it will most likely be ready.
- TeMPOraL 11y ago
  I really think d) is the most significant one here. It's pretty visible if you look at the problem structure. In a competitive environment, the first one to give a solution wins, at least initially. Since it's easy to hide bugs and unfinished features for the release, the ones who skip proper design will ship faster and thus win and preserve on the market. "Good solution today is better than perfect one tomorrow" turns into "worst solution that's still acceptable today is better than decent enough solution tomorrow".
bkeroack 11y ago
https://en.wikipedia.org/wiki/Planning_fallacy https://en.wikipedia.org/wiki/Planning_fallacy
datashovel 11y ago
Most of it is not a technology problem. Most of it is a human problem. Humans are not as good as we think we are at communicating in precise details with others.

sosuke 11y ago

"at least two natural languages" I'm half that good! It seems like our profession hasn't changed much at all. Makes me feel like I'll be well prepared for the workplace 40 years in the future.

newjersey 11y ago
My favorite part was when he answered he has a high school diploma. He mentions he has five years in university but all you really need is a high school diploma. As someone who spent five and a half years (first four for a BS mathematics degree and a year and half for BS computer science degree) as an undergraduate student, it makes me happy to hear professionals say that. K-12 school is just as important as ever. I just wish we started second language instruction at lower grades. It could be Spanish, French, German, Mandarin... It'd be nice if we started much earlier.

khoury 11y ago

Oh god... just as depressing as it is today.

drzaiusapelord 11y ago

"A negative side is that the work is extremely tiresome, and there are pressure problems all the time. Mental health problems are well known in this business." Is he suggesting this work is the cause of mental health issues? Seems to me almost every techie I know has below average mental health. Chicken-egg problem here.

settings 11y ago
I took that as his implication. In my experience there is also selection bias.
smaudet 11y ago
Hmm. If mental health precludes the ability to think logically, then what does that say about the supposed mental 'health'. If, conversely, healthier people are more logical, then maybe they should be programming instead? Conundrum.

lordnacho 11y ago

The guy makes it sound like he's just making whatever the designer tells him, like a robot. In reality there's a lot of back-and-forth. This is easy, this is hard, this is impossible, we should reorganize this or that, some development path requires more investigation, etc. If I was a kid watching this I'd conclude it was stressful and subservient.

johansch 11y ago

Because he's finnish it reminds me of this 1993 video of Future Crew making the PC demo "Second Reality": https://www.youtube.com/watch?v=LIIBRr31DIU?cc_load_policy=1 https://www.youtube.com/watch?v=LIIBRr31DIU?cc_load_policy=1 (There's high quality english subtitles there.) Finished product: http://www.pouet.net/prod.php?which=63 http://www.pouet.net/prod.php?which=63 https://www.youtube.com/watch?v=rFv7mHTf0nA https://www.youtube.com/watch?v=rFv7mHTf0nA

msarnoff 11y ago

The video was posted by an awesome demoscene dude named viznut. Check out the rest of his channel. Experimental music from very short C programs: https://www.youtube.com/watch?v=GtQdIYUtAHg https://www.youtube.com/watch?v=GtQdIYUtAHg Robotic Liberation (VIC-20 demo): https://www.youtube.com/watch?v=2SdGkkp1aq8 https://www.youtube.com/watch?v=2SdGkkp1aq8

nebulous1 11y ago

Bret the Hitman Hart gave some insight into the games industry in the 90s: https://www.youtube.com/watch?v=EfdIGG36GgU https://www.youtube.com/watch?v=EfdIGG36GgU

kolanos 11y ago
Hearing a wrestler say "you dereferenced a null pointer" made my day.
- OJFord 11y ago
  (1:40)
nickpsecurity 11y ago
Dude that was great. I second the null dereference line. How the heck did I not see this back when I was enjoying how advanced and fun this game was? Note: Probably playing it and the other classics too much haha.

flurpitude 11y ago

Too much pressure, too many meetings, projects coming in behind schedule. Must have been awful in those days. Do all those people look like they actually hate their jobs, or is this just a Finnish manner?

edpichler 11y ago

This video is incredible! Many years later, and we are still struggling to solve the same software engineering problems, per example, project delays. The video also shows that, in 1973, the requirements changed all the time. People had a lot of meetings, and they think that programming is a lot about teamwork and collaboration. Requirements analysis, before it had this name.