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.