APPropriate Behaviour
The book about all the things software writers do that aren't writing software.
FSF
Tag Archives: History of Software Engineering
Type safety, undefined behaviour, and us
There appears to be a shift towards programming languages that improve safety by providing an expressive type system, automatic memory management, and no gaps in the specification that lead to “undefined behaviour”. If your program is consistent with the logic … Continue reading
The Image Model
I was reflecting on things that I know now, a couple of decades in to my career, that I wish I had been told at the beginning. Many things came to mind, but the most immediate from a technological perspective … Continue reading
Why mock objects aren’t popular this week
The field of software engineering doesn’t change particularly quickly. Tastes in software engineering change all the time: keeping up with them can quickly result in seasickness or even whiplash. For example, at the moment it’s popular to want to do … Continue reading
On the locations of the bullet holes on bombers that land successfully
Ken Kocienda (unwrapped twitter thread, link to first tweet): I see so many tweets about agile, epics, scrums, story points, etc. and none of it matters. We didn’t use any of that to ship the best products years ago at … Continue reading
On or Between
The new way to model concurrency is with coroutines (1963), i.e. the async/await dance or (building upon) call-with-concurrent-continuation. The new new way is with actors (1973), and the old and busted ways are with threads (1966), and promises (1976). As … Continue reading
Software design is refinement, not abstraction
James Koppel tells us that software engineers keep using the word “abstraction” and that he does not think it means what they think it means. I believe that he is correct, and that the confusion over the term abstraction comes … Continue reading
Unit test: you keep using this word.
There’s an idea doing the rounds that the “unit” in “unit test” means the unity of the test, rather than a test of a software unit. Moreover, that it originally meant this, and that anyone who says “unit test” to … Continue reading
When to “address” “technical debt”?
The phrase “technical debt” appears in scare quotes here because, as observed in The Unreasonable Ineffectiveness of Considering Things Harmful, technical debt has quite a specific meaning and I’m talking about something broader here. Quoting Ward Cunningham: Shipping first time … Continue reading
Having the right data
In the beginning there was the relational database, and it was…OK, I guess. It was based on the relational model, and allowed operations that were within the relational algebra. I mean it actually didn’t. The usual standard for relational databases … Continue reading
Aphorism Considered Harmful
Recently Dan North asked the origin of the software design aphorism “make it work, make it right, make it fast”. Before delving into that story, it’s important to note that I had already heard this phrase. I don’t know where, … Continue reading
