Tag Archives: History of Software Engineering

I’ve vastly misunderstood the Single Responsibility Principle

So have a lot of other people; my understanding of it accords with much writing I’ve seen about the principle on the web, and elsewhere. For example, in Michael Feathers’ “Working Effectively with Legacy Code”: Every class should have a … Continue reading

Posted in architecture of sorts | Tagged | 7 Comments

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

Posted in software-engineering | Tagged | 1 Comment

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

Posted in advancement of the self, smalltalk | Tagged | Leave a comment

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

Posted in TDD | Tagged | 1 Comment

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

Posted in agile | Tagged | Leave a comment

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

Posted in architecture of sorts, code-level, design, performance, software-engineering | Tagged | Leave a comment

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

Posted in design, software-engineering | Tagged | Leave a comment

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

Posted in test, unittest | Tagged | Leave a comment

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

Posted in process | Tagged | 3 Comments

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

Posted in software-engineering | Tagged | Leave a comment