APPropriate Behaviour
The book about all the things software writers do that aren't writing software.
FSF
Tag Archives: History of Software Engineering
Non-standard components
Another day, another exercise from Software: A Technical History… A software engineering project might include both standard and nonstandard engineering components. Give an example of a software engineering project where this would be appropriate. Kim W. Tracy, Software: A Technical History (p. … Continue reading
Specific physical phenomena
Continuing the theme of exploring the exercises in Software: A Technical History: Give an example of a specific physical phenomenon that software dependson in order to run. Can a different physical phenomenon be used? If so, giveanother example phenomenon. If … Continue reading
Related methods and tools
The book Software: A Technical History has plenty of exercises and projects at the end of each chapter, to get readers thinking about software and its history and to motivate additional research. For example, here’s exercise 1 (of 27 exercises … Continue reading
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
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
