Start From The Past

After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. (Jerry Weinberg)

For a while now I’ve had a rule of thumb, heuristic, that I’ve followed when I’ve wanted to learn something new. I don’t actually remember if I learned it from somewhere or came up with it myself. Nevertheless, it’s been useful for me and I would like to share it with you.

Find Out Where It All Started From

If I want to learn something new, I will focus on the past and try to figure out where it all started from. This way I will lower the risk of being affected by Law of Raspberry Jam.

As for now, I think it’s most helpful if I share couple examples.

Case 1: Scrum

I wanted to know more about Scrum couple months ago. Considering the popularity of Scrum, its Wikipedia article is quite thorough. What’s most important, it has History section in it. Let me copy-paste the beginning of that section:

Scrum was first defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach” in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the “New New Product Development Game”.[1] Takeuchi and Nonaka later argued in “The Knowledge Creating Company”[2] that it is a form of “organizational knowledge creation, […] especially good at bringing about innovation continuously, incrementally and spirally”.

After learning that, I went and read the paper. What’s interesting, paper didn’t mention e.g. sprints, daily stand-ups or backlog. It focused more on identifying characteristics. Characteristics that leading companies showed (in 1986). Later, while learning about origins of Scrum, I ended up watching James Coplien’s talk at Youtube: Patterns: The New Defacto Scrum Standard. I’ve seen it several times since then. Perhaps the thing that strike me the most, was that James said how Scrum had been affected by Toyota Production System (a.k.a. Lean).

Learning about the work of James Coplien also led me to Scrum Pattern Community & their published patterns. Based on all the previous, my current understanding is that Scrum is about identified patterns & in the end: Kaizen. Successful teams have had patterns that has been part of their success. Those have been identified and came part of Scrum. It also reminds me that every team has its own context that they operate on. This needs to be considered when trying to apply a pattern (e.g. daily stand-up) to yours.

Case 2: Agile

I’ve also activated with Agile lately (this year). Sure, I’ve been familiar with Agile Manifesto & its principles. That’s though quite simplistic & therefore it makes you wonder how to interpret it. That’s why I wanted to understand what people behind the Manifesto thought about it, when it was published. I found one good article about it where Martin Fowler & Jim Highsmith explained their thinking behind every point & principles. Good to notice how the article is from year 2001, when the Manifesto was published.

There’s a lot more, if you have time, energy & curiosity. Martin Fowler has an interesting article on his website from July, 2000, where he describes the New Methodology. Then there’s also an updated version of the same article from year 2005. I haven’t yet read those. But that’s where I will go next. These are the people who were behind Agile Manifesto, they are the ones whose thinking I want to listen, when learning about Agile.

I would be naive though, if I would assume that agile software development came to life 13 years ago (2001). There’s one great article that reminds us how people were doing things smartly already in mid-1950s. Here’s one quotation (by Jerry Weinberg) from that article (Iterative and Incremental Development: A Brief History):

We were doing incremental development as early
as 1957, in Los Angeles, under the direction of
Bernie Dimsdale [at IBM’s Service Bureau
Corporation]. He was a colleague of John von
Neumann, so perhaps he learned it there, or
assumed it as totally natural. I do remember Herb
Jacobs (primarily, though we all participated)
developing a large simulation for Motorola, where
the technique used was, as far as I can tell, indis-
tinguishable from XP.​​
​​​​
When much of the same team was reassembled
in Washington, DC in 1958 to develop Project
Mercury, we had our own machine and the new
Share Operating System, whose symbolic modifi-
cation and assembly allowed us to build the system
incrementally, which we did, with great success.
Project Mercury was the seed bed out of which
grew the IBM Federal Systems Division. Thus, that
division started with a history and tradition of
incremental development.
 ​
All of us, as far as I can remember, thought
waterfalling of a huge project was rather stupid,
or at least ignorant of the realities… I think what
the waterfall description did for us was make
us realize that we were doing something else,
something unnamed except for “software devel-
opment.”
 ​
Case 3: Testing
 ​
On December, 2013,  I wrote a blog post about history of software testing and especially how first software testing teams were formed. It’s a good description of how testers were starting to came into software development 50 years ago. Because they concluded that it would help if there were people who were focusing more on testing than others.
It’s good to note though that I’m talking about software testing. Testing, the mental activity of questioning in order to evaluate – that goes far back. I haven’t put that much effort on tracking the history of that yet.
 ​
While exploring the history of software testing I ran into different kinds of papers. One particular (Evaluation of the Functional Testing of Control Programs from 1967) hinted where the demand for excessively structured testing came from.
 ​
Other way to learn about the history is to ask from people who remember far enough. I asked for example from Jerry Weinberg about origin of test cases.
 ​
JerryWeinberg_TestCases
This is a good reminder of the context behind birth of test cases. While it may be beneficial to use them in your context 60 years later, do note that access to machines is not that abominable these days anymore. If that’s the case, other reasons for using them need to be considered. This same thinking should apply to anything that you’re leaning into & haven’t invented by yourself.
​​​
Try It Yourself
 ​
Next time you want to learn about something new (e.g. BDD, Specification by Example, Exploratory Testing, Lean, Unit Tests), start from its history. If there are few people who are behind it, try to find what they have to say about it. Or perhaps you can even ask from them via email, Twitter or some other way. This way you’re increasing your chances of understanding the subject the same way as the people who came up with it.
 ​
Good luck!
 ​
To show that I’m not alone, I’d like to end this to Martin Fowler’s words:
 ​
In order to understand something, I often find it useful to know how it came about.
 ​
Advertisements

6 thoughts on “Start From The Past

  1. Pingback: Five Blogs – 1 August 2014 | 5blogs

  2. Pingback: Testing Bits – 7/27/14 – 8/2/14 | Testing Curator Blog

  3. Hey Aleksis.

    Thanks for re-posting this on Twitter a couple of weeks ago, I meant to write this comment then but life happened. I am pretty sure I read this blog post when you originally posted it, but at that time it did not resonate with me. I guess I was not “receptable” for the message.
    Since then I have changed so when I re-read this it spoke to me and I could relate to something that just recently happened to me.
    In a Google hangout series named “Is TDD dead?” Martin Fowler talks about semantic diffusion, that over time powerful messages gets diffused, and one way to remedy that is to go back to its principals. He was referring to TDD in particular but I guess also about lots of stuff happening in agile.

    I recommend anyone interested in the mindset of unit tests, TDD and agile to watch the whole “Is TDD dead?”-series, here is a link to the last episode in which he discusses semantic diffusion: https://www.youtube.com/watch?v=dGtasFJnUxI

    “My” version of the “Learn from the past”-heuristic is that in order to understand some things, reading about it is not enough. Vary your “learning channel” – read, watch videos, discuss with others, listen to podcasts, speak to the “source authors” if possible etc.

    Cheers,

    /magnus

    • Hi Magnus,

      One of the triggers for this blog post was actually that particular TDD Google Hangout series and how Martin Fowler talked about learning about things got the way they are. The quotation on the end of this blog post is from that TDD series.

      I agree with your version on the “Learn from the past” -heuristic. We definitely need to add variety to our effort on learning about past. Where speaking about “source authors” is quite close to ideal approach. Of course there’s limitations to this approach as the challenge is that people who remember for example where test cases came from, are close to 90 years old (e.g. Jerry Weinberg).

      In the end I think it’s crucial for critical mind to know about “learn from the past” -heuristic as it can be valuable for understanding new subjects.

      Cheers,
      Aleksis

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s