Posted on

Notation and Thought in Unit Testing

The paper “Notation as a Tool of Thought” by Kenneth E. Iverson of the IBM Thomas J. Watson Research Center was published in the Communications of the ACM, Volume 23, Number 8, 1980-08. It’s available online at https://www.jsoftware.com/papers/tot.htm. Thanks to John Arundel (https://twitter.com/bitfield) who called attention to the paper in a tweet.

The paper deals with the way an appropriate notation influences people’s thinking in a given domain. Iverson was interested in the domain of mathematical computing, and he uses the APL language to illustrate his ideas. APL is an array-processing language Iverson developed in the 1960s. It has a following even today. You can read more about it on the APL Wiki at https://www.aplwiki.com/. You can try it out online here: https://tryapl.org/,

In this piece, I’m going to stretch the point a bit and apply some of the principles of notation Iverson presents in his article to a different domain: unit testing of application software.
Continue reading Notation and Thought in Unit Testing

Posted on

Microtests and Unit Tests for z/OS Applictions

The idea of “unit testing” is pretty well-known in programming circles. Everyone has some concept of what it means and most software developers practice some form of unit testing.

Yet, there is disagreement about unit testing. If you’re trying to get a handle on this topic for purposes of supporting existing applications in a z/OS environment, you may find a lot of contradictory information online. Opinions are often presented as facts, and are defended strongly. I’d like to try to tease some of that apart so you can make practical sense of it.
Continue reading Microtests and Unit Tests for z/OS Applictions

Posted on

Cobol Rising

As early as the mid-1980s, people were quite certain Cobol was on its way out. Most of us looked for opportunities to learn emerging technologies and shifted our career focus away from Cobol and from its primary platform, IBM mainframes.

At that time, opportunities opened up for those who understood the old technology and could help re-implement solutions in the new. It was a way for us to learn other technologies and build a new career path.

There was pressure to replace older applications based on Cobol, as the mainframe was due to die at any moment.

Cobol forgot to die

But a funny thing happened on the way to the cemetery. Writing in Forbes in July, 2020, Tom Taulli notes:

  • “[Cobol] powers about 80% of in-person financial services transactions and 95% of ATM swipes.
  • On a daily basis, it processes $3 trillion in commerce.
  • There are over 220 billion lines of code and 1.5 billion are written each year.”

See COBOL Language: Call it a Comeback?.

Continue reading Cobol Rising

Posted on

The Problem with Metaphor

Some time ago I wrote about the use of metaphors in the field of software development (Metaphorically Speaking), and more recently on the risks of using colloquial English with international colleagues who learned business English (English for English Speakers). I’d like to revisit the subject, as I still see a lot of confusion out in the world, and we’re still coining new terms that strike people differently than intended.

Continue reading The Problem with Metaphor
Posted on

Collaboration

Contemporary software development methods emphasize collaborative work over solo work. I remember this idea gaining momentum from as far back as the 1990s, when Extreme Programming was becoming known, including one of its core practices, Pair Programming.

In retrospect, I can recall many instances when people collaborated in an ad hoc way to solve specific problems, going back to the beginning of my IT career in 1977. I’ve read articles and heard stories about the value of collaborative work in engineering going back at least to the 1950s. There was even a deliberate experiment in 1975, carried out by the US Army, on the value of “two-person teams” in software development (the article does not appear to be online anymore, but there is an excerpt in this old blog post: Does pair programming work?).

In all these cases, from formal studies to informal “war stories” told over coffee or beer, direct collaboration provided immediate and palpable benefits to the people involved. That has been my experience, as well. And yet, it seems as if solo work continues to be the norm.

Continue reading Collaboration
Posted on

Scrum pain in large organizations

Although “agile” has been around a long time, and Scrum even longer, many large organizations are only now undertaking “agile transformation” initiatives. People in those organizations who have not had experiences elsewhere with “agile” or Scrum are on the learning curve. I’ve noticed a handful of challenges that seem to be fairly common in these organizations.

Maybe it will be helpful to mention some of the common points of confusion and try to clarify them. I hope so, anyway.

tl;dr warning
Continue reading Scrum pain in large organizations

Posted on

Gilded Rose: Read by Refactoring

People who practice refactoring often turn to the Gilded Rose exercise, originally posted by Bobby Johnson and extended and elaborated by Emily Bache. The exercise can be approached in many different ways. I think that makes it especially useful for exploring alternative ways of dealing with existing code bases.

Several years ago, Arlo Belshee came up with an interesting way to address existing code that he calls read by refactoring. I will admit that I haven’t discussed this with him directly, nor have I attended his training on the subject. I’m basing this on my reading of the idea online and experimenting with the approach on my own. So, I might be missing key aspects of the idea. Please feel free to correct me if that’s the case.
Continue reading Gilded Rose: Read by Refactoring

Posted on

80/20 Skills

People in our field like to cite various maxims or laws. To name a few, there are Conway’s Law, Hyrum’s Law,
Brooks’ Law, the Peter Principle, Hofstadter’s Law, the 90-90 Rule, Parkinson’s Law, Sayre’s Law, Eagleson’s Law, Postel’s Law (a.k.a. the Robustness Principle), Linus’ Law, the Dunning-Kruger Effect, the Principle of Least Astonishment, Hanlon’s Razor and it’s notable parent, Occam’s Razor, and of course the ever-popular Murphy’s Law.

I’d like to consider a couple of maxims today: the Law of Diminishing Returns and the Pareto Principle, or 80/20 Rule, in relation to the idea of multi-skilled team members on a cross-functional team.
Continue reading 80/20 Skills

Posted on

What happened to the test automation pyramid?

In a February 2020 article on cucumber.io, “Eviscerating the Test Automation Pyramid”, Seb Rose points out some of the issues that ensue when people misunderstand the intent of the test automation pyramid (or triangle) originally proposed by Mike Cohn and interpret the model too literally. He suggests if we remove the various levels and labels that people have added on the inside of the triangle, and think about the shape as such, we’ll come closer to the original intent – many tests of small scope and fewer tests of larger scope.

Continue reading What happened to the test automation pyramid?