We in the software development community like to think we’re special: that building software is uniquely difficult. As special snowflakes, we cannot be held to the business standards required of projects based on assembling boring old atoms; we cannot say what we will build, what effort it will take, or when it will be completed. For that matter, the word “completed” is rather distasteful and can ruin our mood after the company-provided foot massage.

Ed Yourdon’s book “Modern Structured Analysis,” published in 1989, presents a different view. Structured Analysis traces its heritage back to the massive logistical challenges of the Allies in World War II. It’s not interested in coddling the egos of workers.

(Related: Five essential rules of project management)

One of the defining characteristics of SA is that, no matter how small or large the project, everything about the system is included: nothing about the workers, hardware or software is taken as a given. On the other hand, this lives in tension with “the perfect technology assumption,” which allows for a classically American “We Can Do It!” attitude that limitations should not be allowed to dampen the analysis. If the perfect system requires a faster computation than any of today’s computers can perform, so be it—we can always build a faster or more capable machine. Most importantly, Structured Analysis was focused on the dynamics of the system and the people who used it, not the mystique of the technology itself. Yourdon’s book was where I learned that the job of software development was delivering value, not writing code.

The enthusiasms of the software development community swing on great pendulums, between absolutes that do not acknowledge the fundamentally human, fundamentally flawed problem of communicating user needs to developers and developers addressing those needs in software. There is no single perfect way of developing software, just as there is no single perfect way of talking to another person. Structured Analysis had flaws, both large and small. As a practical matter, it was difficult to balance the abstraction levels between different parts of a system properly.

Most significantly, it promoted a very front-loaded approach—when combined with the prevailing project-management approaches, it could consume vast amounts of time and money without producing even a minimal viable product. Shorter development cycles, with users seeing concrete iterations of the system under development, are far more likely to avoid “throw the whole system away” debacles. Software really does have a different kind of complexity from physical machines. Its elasticity creates both unique opportunities and unique challenges.

Having acknowledged its flaws, Structured Analysis promoted several values that seem to have fallen by the wayside. Viewing computer technology as a blank slate is not appropriate in a world of commodity cloud services and supercomputers in every pocket, but the pendulum has swung too far in terms of every aspect of a system being controlled by Yet Another Framework. It was very difficult to balance the abstraction level in Structured Analysis, but the emphasis on data transformations is part and parcel with the growth in functional programming approaches.

I kept my copy of “Modern Structured Analysis” on my bookshelf for many years after I stopped referring to it. It was one of those books that you keep as a talisman of your past, as if its mere presence will cause you to think a little deeper, work a little harder, do a little better job.

In the early 1990s, Ed Yourdon turned his analytical mind to the software development industry. He felt that American programmers were overconfident in their singular talents and were complacent about competition from Asian countries. This was, perhaps, a lingering bias from the view that manufacturing software and hardware were more alike than different. To his credit, Yourdon recognized his mistake and recanted in 1996’s “The Rise and Resurrection of the American Programmer,” a book which may have had its inaccuracies but was correctly breathless about the sweeping changes that the World Wide Web was about to have on the software development industry.

Yourdon was too pessimistic about Jan. 1, 2000, and his reputation suffered when the Y2K Bug fizzled. He continued to work, but was no longer seen as a colossus astride the industry, lighting the way.

Ed Yourdon died on Jan. 20, 2016, of post-surgical complications. It was my privilege to work with him for a few years in the early 1990s, and my luck to have counted him as a friend.