Slashdot Mirror
Software Hall of Fame Member Ed Yourdon Dies (wikipedia.org)
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.
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!?!?!?
10 GOTO 10
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
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.
Ed Yourdon
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.
I'm a C programmer and I can use them safely :P
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 ... took about 10h until someone noticed that the super market was open by accident
Background: "what day of the week is it" miscalculated due to an Y2K bug that lead to a wrong judgement of the day in the year/week.
There are literally 100 bad bad bad situations I could reiterate from my mind that involves Y2K bugs.
And yes, I worked in Y2K reengineering. If people like Ed Yourdon and others had not demanded awareness plenty of people had died in silly accidents. E.g. in elevators that don't work on days where the building is supposed to be shut down. (Oh, sunday: who needs an elevator? No one, so if one hits the button it must be a burglar, switch of the elevator. Oh: one enters 23:59 on Saturday and travels down, elevator stops mid way because it is Sunday ... Oh bad luck, elevator would work on Monday again, but it is a holiday (e.g eastern). Passenger dies from thirst. However: it is not Sunday!!! the stupid Y2K/leap year bug caused this problem on friday)
You know, bugs are as silly as they can get. Luckily the F16 flight simulators ran the same software as the real plane. So what happened? Test pilot goes over the equator. Plane turns on its back. Pilot can not turn it back. Well, he can, pretending to fly upside down ... which leads to other errors: most sensors tell the plane: "well, you think you are upside down, but in fact we are not"
Why? Because plenty of the planes stuff is controlled by software and it is difficult to fly maneuvers the software does not allow.
Reason? Normal vector, determining if the upper side of the plane shows to earth or into space had a sign error. So on the southern hemisphere it thought it would be upside down.
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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. 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..
Bruce F. Webster (brucefwebster.com)
A bit of satire from the 70's https://www.fortran.com/come_f...
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.
A diabetic, when the insulin's up in his apartment?
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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.
... to break out of a Lodash forEach loop, but that should have only grazed him.
If you post it, they will read.
You are a moron. "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." really? WHO CARES? A supermarket opened its doors? Wow. The world does not end. There are bugs in software all the time. The problem with people like Yourdon is the exaggerated everything to sell books. This causes hysteria and more trouble than the actual problem. Scumbag.
People get trapped in elevators every day. Give me a break. Y2K bug? What about BUGS that happen every damn day?
Thank you.
One by one, they leave our lives,
leaving us with loss that we never expected.
(R)ule in Hell or (S)erve in Heaven [R]?
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 fellow commenters here vote comments as the one above up and it is classified as 'Insightful'.
What great contributor? Read the reviews of his books on Amazon. He is widely described as a "charlatan". His followup books were of a similar nature, and equally bogus.
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 preach to the enterprise, the other couldn't.
Did you ever read one of his books. I made the mistake of shelling out $70 for the first hardcover edition of Yourdon System Method in the early 90s. After reading it, I thought "I must be missing something!" So, I read it again. And again. Then I figured out the thing I was missing was $70. Ended up putting it in the charity bin along with some clothing.
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
I haven't use GOTO since 1982. Must be someone else.
"I have the attention span of a strobe lit goldfish, please get to the point quickly!"
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 are easier to visualize due to indentation than go-to's, and thus aide in the visual identification of flow. There is no known visual equivalent for go-to's at this time, at least not practical ones.
That's important because the symbolists waste time and resources looking for or promoting some special math to guide software design when it's really mostly about the human mind. Just because something is easy to measure or process mathematically does NOT mean it's easy for the human mind to digest.
They accused me of promoting mediocrity and I accused them of trying to inflate the value of their profession, graduate-level university teaching, by inflating the value of minor ideas. Interesting debates, regardless.
Table-ized A.I.
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.
If I had a DeLorean... I would probably only drive it from time to time.
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 about the severity of the problem. Hence, you should stop commenting on Y2K problems and stop insulting dead computer/software pioneers.
In my culture it is an insult no one really wants to commit, to insult dead people. Families easy get upset ... plenty of vendettas got fought the last 2000 years about such simple issues ;D
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
"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 be in a mess the next day. There were indeed many $ spent on fixing such bugs, and I'm sure it paid off in some way (certainly consultants benefited from the spending); but in the end there was no catastrophe, not even a little one.
I had exactly one experience with a Y2K bug. My checks were printed some time in the 90s with "19" in the date (so I didn't have to write that part of the date). Yes, my paper checks. I dealt with the bug quite easily, thank you, until I used up that supply of checks. (Maybe I should have kept them as antiques.)
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?)
French bot?
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 paying out in quantity to 20 year old students.
The attitude: "see nothing has happened" is a pretty silly one considering what had happened if those bugs would no have been fixed.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
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.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I didn't know him, but I read two of his books.
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 observations about our profession.