There are lots of analogies for software testing, but none of them quite fit.


Transcript for episode 6 of the Test & Code Podcast

This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.


I’ve heard lots of analogies for writing software.

Writing software is like mathematics. Except it isn’t. Mathematicians have proof systems. Software developers don’t. A math problem is either right or wrong. Much of software is subjective.

Writing software is like science. Except it isn’t. I have a CS degree. But I’ve never understood that one. I don’t remember the scientific method as applied to operating systems.

Writing software is like engineering. Except it isn’t. This one is close. We do solve problems pragmatically using software. However, engineers in any other field with roughly the same level of competence will generally solve an engineering problem in roughly the same ways. Many forms of engineering are constrained by physics, and those don’t change depending on which engineer you throw at a problem. Software isn’t constrained by physics so much as the types of problems a software developer has encountered in their past.

Actually engineering isn’t like engineering. Electrical, mechanical, chemical, and civil engineering are all very different, as are the other fields of engineering. Why do we want software to be like one of the others.

Writing software is like writing a novel or an essay. You know, with words. Except it isn’t. Both benefit from a few iterations. And sometimes tossing it all and starting over are best. But they are also way different. I can’t write an automated test to see if I’ve effectively conveyed an idea, or evoked an emotion.

Writing software is like nothing else.

Writing software isn’t even like writing software.

Here’s a quote from “Managine the Development of Large Software Systems”. This is actually the very first two sentences, and they are significant: “I’m going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding, and post-flight analysis.”

Why is this significant?

This is one of the most influential papers in software process history. And the author prefaces it with these two sentences. Why?

I don’t think he’s bragging. Even though those projects do sound way cool and impressive, and difficult.

I think he’s saying this because writing software is like writing software. Except it isn’t.

If you are living in 1970 with nine years of management experience and are managing a large project for spaceflight mission planning, then maybe Dr. Royce’s experiences can translate well to your problems.

If your situation is different, it still might apply. But it might not.

We should definitely learn from each other, despite our differences. But we are different and all lessons don’t always transfer to different domains and skill sets well.

We have different teams, different skill sets. Techniques that work great for one team can seem abrasive and disruptive to another.

I’m starting a journey in exploring software development practices. I’ll be looking through my eyes, my experiences.

I started programming by copying simple programs from magazines into my TRS-80 color computer. My favorite and longest program I typed in was a version of Lunar Lander. This was in BASIC. But I didn’t know it was BASIC at the time. Was this experience significant in the way I look at software development? Maybe. Maybe not.

I was talking with a software developer that I admire very much that grew up in Germany. He had a similar experience than me with a computer in the family. His was an Atari. He was frustrated with the speed of it compared to the Commodore 64, even though they had the same processor. So he learned assembler to program games so they were more responsive. He didn’t know about the TRS-80, partly because it was mostly an American thing. (I’m probably getting this story wrong, but it does highlight the geographical effects.)

I been programming professionally for about 20 years. Most of that has been working on large embedded projects in the electronic test and measurement industry.

I’m telling you this so that you know that if your experiences and problem domain are different than mine, my perspective might not help you.

But it might.

I also lived through speed-metal post-punk crossover albums and John Hughes movies. Were those significant in how I develop software? Doesn’t seem like it, but I have no idea. The point is that we all have different perspectives, different experiences, different skill sets, different programming language history.

There is no way that you can pull two groups of people together in such a way that the right way to develop software will be the same for both groups.

I’m going to be exploring software development methodologies. And I’ll be including my opinions that come from my experience. My experience is different than yours, so don’t be surprised if you don’t agree.

Writing software is like nothing else.