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

Posted in history | Tagged | Leave a comment

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

Posted in history | Tagged | Leave a comment

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

Posted in books, history | Tagged | 2 Comments

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