Tag Archives: software

Review: Structured Programming (Dahl, Dijkstra, and Hoare)

Structured Programming Structured Programming, by O.-J. Dahl, E.W. Dijkstra, and C.A.R. Hoare. Academic Press, 1972. 

This year (2012) is the 40th anniversary of this text, but it holds up well. It consists of three essays:

  • "Notes on Structured Programming" by E.W. Dijkstra
  • "Notes on Data Structuring" by C.A.R. Hoare
  • "Hierarchical Program Structures" by O.-J. Dahl and C.A.R. Hoare

If you've been led to think "Structured Programming = No GOTOs", the first essay will change your mind. It's much more a consideration of design in the small than a focus on surface form. 

"Data Structuring" considers how to structure types; Pascal's type structure (remember that?) of records, sets, enumerations etc. clearly embodies some of these ideas. You can see roots of the "object-based" approach (that never seemed to make it to the mainstream in the way object-oriented approaches did). 

The final essay describes mechanisms from SIMULA 67, an early (if not the original) object-oriented programming language. You can see the early consideration of objects and coroutines, classes and subclasses. 

There's definitely a "historical" air to these essays, but they hint at a path almost taken. Modern libraries and the modern rush to deliver let us ignore many ideas about software design, but they don't go away. These articles take a slower, more mathematical path than I've seen anybody apply in practice, but it brings clarity of thought about mapping problems and solutions that I'd like to imitate. 

Review – Structured Systems Analysis: Tools and Techniques

Structured Systems Analysis: Tools and Techniques. Chris Gane and Trish Sarson. Prentice Hall, 1979.
This is one of the classic books on systems analysis: data flow diagrams, data dictionary, and so on appear. It does a decent job explaining these (though heavier on the tools than the techniques). The description of a data dictionary is one of the better ones I’ve seen. There’s a nice distinction between system and organizational objectives. This is the earliest reference I’ve seen to the IRACIS model: that work is done because it will Increase Revenue, Avoid Costs, and/or Improve Service. Their explanation of decision tables is excellent. For those who trace the history of agile ideas, Gane and Sarson view systems development as following Boehm’s spiral model: “In each case and at each level we build a skeleton, first logical and then physical, see how well the skeleton works, and then go back to put the flesh on the bones.” (This is from 1979, and 30 years later we’re still working on it.)

Review – Structured Design

Structured Design. Edward Yourdon and Larry L. Constantine. Prentice-Hall, 1979.

This was one of the early structured "standard works" that I've only just gotten to for the first time. I'd learned things like coupling and cohesion, afferent and efferent flows, and the concept of factoring, but it's much stronger coming directly from this source. Not everything here is compatible with the way I think about design, but this is one of those books that deserve repeated study.

Review – Exploring Requirements

Exploring Requirements: Quality Before Design, Donald C. Gause and Gerald M. Weinberg. 1989, Dorset House.
This book is an exploration not just of gathering requirements, including the challenges of ambiguity. The authors describe how to clarify expectations by using functions, attributes, constraints, and preferences. They treat exploration of requirements as a human process, including discussion of how to facilitate different types of effective meetings. My favorite part is the set of context-free questions that apply to many situations. (Reviewed Aug., ’09)

Review – Clean Code

Clean Code, Bob Martin, Prentice-Hall, 2008.

Bob Martin tackles the challenges of making code sparkling clean. He provides numerous guidelines, and demonstrates their utility in action. I particularly appreciated some of the longer examples where he really works them over. You’ll especially find this book compelling if you’re interested in craftsmanship, refactoring, and/or concrete design. (Reviewed Feb., ’08)

Review – Current Trends in Programming Methodology, Vol. 4: Data Structuring

Current Trends in Programming Methodology, Volume 4: Data Structuring, Raymond T. Yeh, editor. Prentice-Hall, 1978.

In parallel with "structured programming," (which often focused on code structure), there was more esoteric work done on "structured data." A lot of this found fruition in things like container libraries. (Few people write their own hash tables any more.) But there was a deeper side of this that explores formal methods for data structures. This out-of-print collection of articles explores many aspects of the algebra of data structures. (Reviewed Dec., ’07)

Review – Design Patterns in Java

Design Patterns in Java. Steve Metsker and William C. Wake. Addison-Wesley, 2006. I won’t review my own book, but I will summarize:

This is a workbook-style book, updating Steve’s earlier Design Patterns Java Workbook and Design Patterns in C#. It covers the same 23 patterns as Design Patterns, but adds some different perspective and a number of challenges to help you make sure you understand the patterns. It’s targeted to intermediate programmers, though more advanced programmers who want to brush up on patterns might consider it also. (May, ’06)

Review – User Stories Applied

User Stories Applied, Mike Cohn. Addison-Wesley, 2004.
This book is all about user stories, focused on the XP-style customer or the Scrum-style product owner (although programmers and others should know this material as well). Mike describes what stories are, how to generate them, and how to estimate and plan with them. He contrasts them to use cases and IEEE-830 “The system shall” requirements, and includes a catalog of “story smells.” The book closes with an example of a system described with 30+ stories, and its tests.

A customer needs to know more than stories (including how to manage up-front analysis that might financially justify a product or feature,  linkages to outside groups, innovation, and more.) But those aren’t this book’s topic: this book sets out to provide a clear, very well-written, and concise guide to using stories with a software team. It does a great job: I’m seeding copies with several people! (Reviewed June, ’04)