Progress is slow if you ignore the past

I have just returned from spending my Sunday at the 1st day of the 21st Danish GOTO conference (not all of them were named GOTO, there has been some name changes over the years).

As expected, it was a great day, with some great talks - if you want to see my running commentary on those talks, go look at my Twitter stream @kriswager

Most of the talks I attended were great, but I especially enjoyed the keynote Engineering You by Martin Thompson, and Dan North's talk Beyond Developer, both of which focused on how software engineers/developers should expand their knowledge and become better programmers.

Both of these talks started out by looking back at the roots of the field. Dan North took us all the way back to Ada Lovelace:

Taking us back to the roots. @tastapod starts his talk with going back to Ada Lovelace #Gotocph pic.twitter.com/exmt9OcroE

— Kristjan Wager (@kriswager) October 1, 2017

Martin Thompson, on the other hand, only took us back to 1967, where "software engineer" was coined. He spent some time on the 1968 Software Engineering conference sponsored by the NATO Science Committee, where many of the issues raised, and experiences expressed, would fit well into a conference today.

It is interesting how little we have learned in 50 years. Words on slide is from meeting in 1968 #Gotocph pic.twitter.com/XV1AxclpmQ

— Kristjan Wager (@kriswager) October 1, 2017

The above tweet only shows one of Martin Thompson's examples from the conference.

While it is easy to despair over how little progress that has been over the last 50 years, I think it is probably better to think about it this way: while our methodologies change, the problems we face are the same, and it makes sense to look at what people did in the past, to see if they have solved problems we face today.

A lot of people tend to think of pre-Agile days as a period of endless, mostly failing, waterfall projects, but the truth is, that this generally wasn't the case in the early days, and probably wasn't as common later, as legend makes it sound.

It is worth remembering that back in the early days of the field, people were not only building programs, they were also building the tools (e.g. compilers) they needed in order to build programs. These tools have evolved since then, but they are still based on the same solutions that we base our tools on today. Why should solutions to organizational problems be any different?

Disclosure: This blogpost mentions the GOTO Copenhagen 2017 conference. As a blogger who blogs about that conference, I get a free ticket from the organizers. The organizers don't dictate what I write about, and don't have any say about the content of the posts.