Software Hall of Fame Member Ed Yourdon Dies (wikipedia.org) 67
New submitter andyjl writes: The software industry lost one of its pioneers on Tuesday, January 20, 2016 when Ed Yourdon died from post-operative complications. Ed was a pioneer of Structured Programming methodologies, and was a prodigious author of software-related books, including topics such as "death march" projects, and the problems of Y2K. He was also a personal friend and fellow forensic software analyst specializing in the analysis of failed software development projects and the lack of software development disciplines. He once told me that he read a item on the Internet (which I cannot find) that said, "whenever a programmer writes a GOTO statement, somewhere a Yourdon dies." I am forced to conclude that one of you programmers out there did indeed write a GOTO statement on Tuesday and I want to know who it was. Look at what you did! Did you really have to use a GOTO?
Adds reader theodp: Yourdon was a successful author, whose Slashdot-reviewed books included Rise and Resurrection of the American Programmer, Death March: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects, Byte Wars: The Impact of September 11 on Information Technology, and Outsourcing: Competing in the Global Productivity Race. Yourdon's Time Bomb 2000!: What the Year 2000 Computer Crisis Means to You!, written with daughter Jennifer, was a Y2K best-seller.
Use of GOTO (Score:4, Insightful)
It was the f'ing compiler!
I swear, it keeps insisting on emitting all these conditional and unconditional branch instructions in assembly!
It's as if you couldn't write functional code in assembly without GOTO's or something!?!?!?
Re: (Score:1)
Edgar P. Yourdon or "Edmeister", as he liked to be called, taught us that a man can triumph over adversity. And even though Ed's agonizing struggle through life was tragically cut short, I'm sure he'll make great worm food.
It's my fault (Score:2)
10 GOTO 10
Structure (Score:1)
GOTO, used properly, does not produce unstructured code. All the world's code would be a lot better if all programmers took a good class in compilers (and got a good grade) -- in this case to learn what "structure" means. I'm not arguing in favor of GOTO; it just serves to make my point.
Re: (Score:2)
In languages without a goto I've implemented shit like:
One time someone made a fuss. After half a day of trying to rewrite it more cleanly (with more flags than the UN and cascading control levels that ran off the screen) he gave up.
Pretty avid photographer, too (Score:4, Interesting)
Ed Yourdon [flickr.com]
Re: (Score:2)
Sorry, but this is not what I would call "pretty avid". Most shots are quite plain and boring.
Re: (Score:2)
What does the quality of the shots have to do with how avid the photographer was?
Re: (Score:2)
I have to say that I had to look up the exact meaning of "avid" (I am not a native English speaker). And you are correct. I was in the understanding "avid" meant that you are not only enthousiastic about something, but also good (or at least better than average) at it. Like "admirable" (in fact I am looking for the translation of the Dutch word "verdienstelijk").
That being said, it would mean always everybody nowadays is an avid photographer, considering the millions of selfies, food-shots and other mundane
Re: (Score:1)
Oh yeah, I remember him. Stupid methodologies that in many cases made problems harder to solve because they added a whole layer of "methodology" that you had to do first, that made changes a nightmare, and were the silver bullet that didn't fix anything - when process becomes more important than solving a problem, GOTO TFO.
Rank it right down there with design patterns as a piece of sh*t.
Re: (Score:1)
Re:I remember him (Score:5, Insightful)
Methodologies and structured methods were never really the problem. The way they were rigidly applied by untutored fools was the problem. Thinking a methodology would make up for poor coding and design skills was the problem. Using a methodology to choke projects was the problem.
I've seen full-blown structured treatments given to tiny, tiny projects, with zero understanding that only certain steps were required and the rest were needless delay and expense. The creators of the methodologies generally knew better, but some of their disciples did not. The methodology salesmen certainly didn't know better. Many a dumb IT manager didn't know better.
Don't blame Mr. Yourdon. He contributed thousands of times more than most of us ever will. If academics with no experience and managers with almost no experience misused his teachings, he's not responsible.
Re: (Score:1)
How would you describe Edisons contribution to the field of sound recording? I see, he was worthless since his method wasn't lossless and his records wasn't free.
How sad it is to read the comments here when great contributors to any field dies. Pioners who really contributed long before these sarcastic commenters where even born. If Yourdon et al hadn't alerted us to the Y2K problem (first article I read was in '85) we as an industry wouldn't have prepared and avoided those problems.
Even sader to see that f
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You are an idiot.
if (current_date < final_date)
pay_out_monthly_fee()
else
terminate_contract()
To what does that evaluate if
current_date = 00
and
finall_date = 99 ??
To what does it evaluate if
current_date=2000
and
final_date=1999 ??
The last year 2k bug was just a year or two ago, when a super market in the USA opened all its doors and switched on all its lights: but no worker was there.
Funny was, that there was "self paying terminals" and 50% of the "intruders" indeed payed
Re: (Score:2)
A diabetic, when the insulin's up in his apartment?
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I think the moron is you, especially for insulting one to be a moron.
The problem with people like Yourdon is the exaggerated everything to sell books. ...
Any proof for that? Actually, you need three proofs:
a) he exaggerated
b) be he wanted to sell books
c) he sold more books and made more money this way
Oh, makes probably no sense if the book you mention was about the Y2K problem, and was about how to address it and to emphasize that solving it is important.
From my point of view you are a kid that has no idea
Re: (Score:1)
Actually, (c) need not be true; it need only be true that he *thought* he would sell more books if he exaggerated. (BTW, (b) is almost certainly true. What author doesn't want his/her books to sell?)
Re: (Score:2)
That's an error alright, but it's not a computer bug, it's someone playing a vigilante. What the elevator should do is call the cops.
Re: (Score:2)
If the computer miscalculates if a day is a monday or a sunday or a sunday is a saturday due to the fact that the year 2000 was not a leap year, it is a computer bug. And related to the year 2000. 88, 92, 96 are leap years, 00 is not, it only is as 1900, but not as 2000.
Re: (Score:1)
"Y2K bugs where so many and in so many variations, people like me, who actually worked in that business, really wonder that basically nothing bad has happened." Which I have always thought of as the point: Y2K was seriously over-sold as virtually impossible to fix. There was an article in Scientific American (I swear, although I haven't been able to find it since then). The claim was that even if far more $ were spent fixing Y2K-related bugs by 31 Dec 1999 than anyone was planning, the world would still
Re: (Score:2)
As you don't know much about the problem, you should admit that you can't judge it.
In a typical business application you have a Y2K bug every 1000 - 10,000 lines.
So a million lines of code has about 100 to 1000 bugs. A single bug not fixed makes the application fail when that code gets executed.
Bottom line finding the bugs is easy, hence nearly all bugs got fixed.
No one knows what had happened if some majour banks had server errors left in automatic stock trading systems. Or if pension funds had starting pa
If you look at the Linux kernel... (Score:5, Informative)
Linus used gotos to a label at the end of some functions. It's a straightforward way to implement clean up that has to happen regardless if a failure occurs at some point in the function.
Re: (Score:2)
The article regarding goto's is named "GOTO's considered harmful", it is not named "GOTO's are the worst idea ever", it is also not called "GOTO's are to be avoided at all costs", it is also not named "GOTO's are an invention of the devil and all language designers using it should burn in hell".
Get a damn clue or switch your business. I consider attitudes like yours: harmful.
Re: (Score:3)
The article regarding goto's is named "GOTO's considered harmful", it is not named "GOTO's are the worst idea ever", it is also not called "GOTO's are to be avoided at all costs", it is also not named "GOTO's are an invention of the devil and all language designers using it should burn in hell".
No, no! That's systemd.
Re: (Score:2)
Four times you forgot to mention the thing that belongs to GOTO.
Re: (Score:1)
I am old enough to remember the flack that went around about GOTOs and such. Frankly, I don't remember Ed Yourdon being involved. The note "GOTO's Considered Harmful" was written by Edsger Dijkstra, not by Yourdon.
The resulting controversy had programmers confused about GOTOs for years, and it appears to still be going on. The point is NOT that every GOTO use is unutterably bad, but that in the day, programmers used them willy-nilly with not enough discipline, leading to very convoluted and less robust cod
Goto Debate [Re:If you look at the Linux kernel... (Score:2)
In a software engineering forum, I argued that software engineering was mostly about human perception and not "external" rules of logic and math (beyond fitting objective tool requirements). I'll call it "perceptionists" versus "symbolists" here.
As an example, we debated whether it could be proven "go-to's are objectively worse than blocks" as far as software creation resources, quality, and maintenance.
The perceptionist side won the debate (although it can come down to definition interpretation). Blocks a
Re: (Score:1)
Us nerds prefer the basement anyhow.
I admit it. (Score:1)
I'm a C programmer and I can use them safely :P
Stunned to hear this (Score:4, Insightful)
I had bought and read several of Ed's books before I met him; we became colleagues and then friends (albeit not close ones) about 15 years ago. It's been a year or two since we've swapped e-mails, but I continued to see his photography work show up on Facebook from time to time.
And I daresay many of those posting here have no idea how influential Ed was in software engineering developing as a discipline, starting nearly half a century ago [wikipedia.org]. He pioneered and championed many concepts and practices that we would take for granted today, both in technique and process. I am so sorry to hear this. ..bruce..
Anyone else remember the "COMEFROM" statement (Score:2)
IF (Yourdon) THEN GOTO Valhalla (Score:2)
Yourdon's book "Structured design: fundamentals of a discipline of computer program and systems design" was my first introduction to the idea of structure programming, and has continued to influence me simply by the idea that good design has a coherent rationale, and an overall structure. Sounds obvious? Not really.
Yeah, he got a little nutty with the TEOTWAWKI stuff about Y2K. Seems kind of quaint now.
Godspeed, Mr. Yourdon.
Re: (Score:2)
I'm trying to recollect if it was Yourdon's or DeMarco's methods I learned so many years ago while working at Inland Steel. The analysis based on DFDs has been a powerful tool I found useful all these years. Conservation of data - a powerful idea. ;)
Godspeed indeed!
Re: (Score:1)
I do not recollect the name of the book but I know the author's name because it was/is so unique. One of my programmers kept a copy in his office and I'd borrowed it, thumbed through it, and read parts of it. He swore by it and by the author. He was also the programmer who was very, very tough on me in my attempts to understand - I'd completely turned my code over to the team by that point but I still wanted to know what was going on under the hood and to be able to make small changes as needed without push
I did find a way (Score:2)
... to break out of a Lodash forEach loop, but that should have only grazed him.
Farewell Ed (Score:1)
Thank you.
One by one, they leave our lives,
leaving us with loss that we never expected.
enterprise gospel choir (Score:2)
I had at least one of his books in the nineties, and while I remember him as making constructive contributions, there was always the code-correction smell of over promotion.
I'm pretty sure I bought one or two of his books via strong recommendations by P. J. Plauger.
These books weren't harmful, and actually set the stage for real learning, which came like one lightening bolt after another from some obscure tome by Edsger W. Dijkstra.
The ultimate difference being that one of these men could successfully preac
Re: (Score:1)
French bot?
Re: (Score:2)
The GOTOs were fairly easy to follow in the code. A flavor of BASIC I used early on in my career also had a RETURN TO command, so you didn't have to return to where the GOSUB occurred, your subroutine could have multiple returns to different locations. That started to get messy to follow at times.
Wasn't me (Score:2)
I haven't use GOTO since 1982. Must be someone else.
Deline and Fall, then Rise and Resurrection (Score:1)
In The Decline and Fall of the American Programmer he predicted Japan would overtake the United States in software development due to their use of CASE tools and zero defect tolerance culture.
In The Rise and Resurrection of the American Programmer (which of course came later), Yourdon fessed up that his prediction was wrong. He attributed this to users being willing to put up with buggy software if they have benefit from new features.
Kind of bookend o