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.

2 of 67 comments (clear)

  1. If you look at the Linux kernel... by fozzy1015 · · 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.

  2. Re:I remember him by chipschap · · Score: 4, 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.