Commentary by Chris Pressey

This work is distributed under a CC-BY-ND-4.0 license, with the following explicit exception: the ratings may be freely used for any purpose with no limitations.

Software Engineering

The Mythical Man-Month

• rating: 3

.

Object-Oriented Modelling and Design

• rating: 3

.

Advanced Programming in the Unix Environment

• rating: classic

.

Programming as Theory Building

• rating: classic

It's worth reading. It's hard to disagree with the main premise, that programmers form mental models of the programs they work on.

But it's worth remembering this was written 35 years ago. We don't say "computer programmer" anymore, we say "software developer", and sometimes they even call themselves "craftspeople" or whatever.

So one would hope that few people seriously think that the primary task of a software developer is to semi-mechanically churn out a program text.

(One would hope. One might of course be quite disappointed.)

And it's also limiting to think that the theory of a program can only be transmitted by the programmer who built it, explaining something face-to-face. Or that the theory of the program is even the most important thing. The program can only tell you what the program actually does, not what it is supposed to do. For that, you need a specification, which is its own theory.

One would hope, in the 2020's, that developers at least try to make the theory of the specification that their programs intend to meet, explicit, in their automated test suites and where-ever else.

(Again, one would hope.)

Why software jewels are rare

• rating: 3

Parnas paints a rather bleak picture, then gives some advice for those attempting to avoid that picture: Design before implementing; document the design; review and analyze the design; review the implementation against that design.

Send-Receive Considered Harmful

• rating: 1

My own experience is that the actor model removes potentials for data races while it introduces potentials for deadlocks. You have to know what your communication patterns are, at a higher level, before implementing them with message-passing. That's the basic message of this paper too.

Computer Science Education: Where Are the Software Engineers of Tomorrow?

• rating: 1

Position paper lamenting the state of CS education

Use of Formal Methods at Amazon Web Services

• rating: 3

Re-read this after a long time - I had forgotten how much good stuff there was in it. In particular: formal system description is useful even if you don't model-check the description; the very act of formalizing it helps engineers understand the design, and results in definitive documentation of the design. They also raise the interesting angle of formalizing a proposed data schema, with data relationships that are more complex than what can be captured by DB integrity constraints.

It's also a useful counterexample to the claim that one sometimes hears that "formal methods are all well and good, but no one in industry actually uses them".

They note that they evaluated Alloy for this purpose but found it came up short, not because of its conceptual model, but because of its analysis approach; it did not support a practical way to describe rich data structures such as nested records. This looks like it has likely changed in recent versions of Alloy, see e.g. https://www.hillelwayne.com/post/alloy6/

1968 NATO Software Engineering Conference

• rating: 2

A historical perspective, dredging up the concerns at the conference where the phrase "software crisis" was arguably coined, and looking at them through a modern lens. With links to similarly interesting articles on this subject.

language agnostic - What is the difference between concurrency and parallelism? - Stack Overflow

• rating: 1

.

c# - Exceptions, error codes and discriminated unions - Software Engineering Stack Exchange

• rating: 1

.

safety - How deep is redundancy on avionics computers? - Aviation Stack Exchange

• rating: 1

.

onion architecture - Is it really possible to decouple the UI from the business logic? - Software Engineering Stack Exchange

• rating: 1

.

Is it typical for there to be no real design prior to someone being assigned a task? - Software Engineering Stack Exchange

• rating: 1

.

How do we get a tech team to make a big technical change? - Stack Overflow Blog

• rating: 1

.

Classic SE Mistakes by Steve McConnell • Jonathan Cook

• rating: 2

Classic mistakes are always interesting to read about, although I wonder also if there isn't an element of schadenfreude in that.

Making Wrong Code Look Wrong -- Joel on Software

• rating: 3

Read this mainly for the metaphor about the dirty oven. The stuff about naming conventions, like Hungarian notation, is valid, but is much better handled with flow typing and type-and-effect systems. You can out-and-out ignore the opinions about exceptions.

Things You Should Never Do, Part I -- Joel on Software

• rating: 3

.

The Twelve-Factor App

• rating: 1
• useful: true

.

Use One Big Server - Speculative Branches

• rating: 1

This is worth reading, but it is really more system architecture or cloud computing than software engineering.