Posted on

COBOL: Not only for mainframes

Recently, there’s been a lot of news about growth in opportunities for work in the COBOL language, owing to a resurgence of the IBM mainframe platform both to support mission-critical applications in key industries and to take advantage of IBM Z cloud computing capabilities. While IBM Z accounts for the majority of existing COBOL applications, the language is relevant to other platforms, as well.

Historically – if I may use such a word for an industry less than a century old – the computing market has been segmented into more levels than just “micro” and “mainframe.” Mid-sized enterprises have long faced a dilemma: Use relatively inexpensive microcomputer equipment and systems that barely keep up with the company’s demand for computing power, or pay heavily for mainframe systems that have several times more capacity than the company will ever use.

To serve that market, a number of computer companies provided midrange computers.

Most of the media play centers on the big iron – IBM Z – but midrange systems are in the same position today with respect to legacy systems and virtualization, and with respect to the generation of people who have been supporting them going into retirement. Companies have significant investment in and dependency on legacy systems, and the old systems are being modernized and cloud-enabled.

Which programming language do you suppose people used to write most of their applications on midrange systems? You guessed it: COBOL.

Continue reading COBOL: Not only for mainframes

Posted on

Whither Tuckman?

There’s a common model people seem to believe in implicitly, known as the Tuckman model, named for psychologist Bruce Tuckman, who published the idea in 1965. The idea is that all teams go through several distinct stages: Forming, Storming, Norming, and Performing. You can probably guess what those stages are like based on their names. The model has been a mainstay of agile coaches for many years.

But I’ve had doubts about the Tuckman model for a long time. My personal experience has been that once people get used to working in a collaborative way, they can move to new teams without any friction.
Continue reading Whither Tuckman?

Posted on

Code Freeze 2021: Mob Programming Workshop

The Code Freeze 2021 virtual conference culminated in a two-hour mob programming (a.k.a. ensemble work or samman) workshop. Seventy-four participants worked in 17 groups, each facilitated by an experienced mobber. Facilitators included such luminaries as Woody Zuill, Llewellyn Falco, and Jeff Langr, among lesser lights.
Continue reading Code Freeze 2021: Mob Programming Workshop

Posted on

Terminal Velocity for Agile Teams

The most popular metric for agile software development teams, by quite a margin, seems to be velocity. Yet, experienced agilists don’t find velocity particularly useful. Even some of the authors of the Agile Manifesto who played a part in defining velocity, as well as story points and planning poker, have moved on. But today, as large organizations undertake major initiatives to “transform” into agile organizations, there is a strong emphasis on velocity as a key metric.

Despite the advice of leading agile consultants and coaches, and books like Doc Norton’s Escape Velocity and my own Software Development Metrics, corporate leaders stress the importance of velocity in their transformation programs, and require their software development teams to track and report it.
Continue reading Terminal Velocity for Agile Teams

Posted on

Pain today, gain tomorrow?

Many of us who try to help others learn and use good software development practices have made the case that if only a person would try a recommended technique and get used to it, eventually they would see improvements in code quality and a reduction in delivery time, and probably easier maintenance of the code base, too.

It’s generally true that when we begin to learn a new skill we work more slowly than we will after we’ve learned to apply the skill effectively. This seems to make many people hesitant to try anything different than their current practices. The idea of slowing down temporarily in order to improve “later” is hard to accept. People have difficulty accepting any short-term cost in order to achieve long-term gain.

But what does it mean…eventually or later or after a while? When is “eventually?” How much “later?” How long is “a while?” People are afraid the temporary slow-down during their initial learning curve will have too much impact on delivery time, or will take too long to overcome.

Continue reading Pain today, gain tomorrow?

Posted on

Cultural Divide and Implications for Tools and Practices: Mainframe vs. Distributed

I began my career working on IBM mainframes in 1977, moved away from that platform gradually from about 1987 to about 1994, and have recently begun to return “home” again (also gradually). I have been heavily influenced by some of the advancements in software development in the world of Java, C#, and similar languages.

As I work more closely with mainframers and with vendors and open source developers who focus on the IBM mainframe platform, I’m confronted with cultural differences between those who work on mainframes and those who work, as mainframers put it, in the “distributed” world (that is, everything that isn’t a mainframe).
Continue reading Cultural Divide and Implications for Tools and Practices: Mainframe vs. Distributed

Posted on

In an Ideal World

Warning: Rant.

Many of us who try to help organizations and teams improve the way they carry out software development and delivery work encounter a bizarre response from clients on occasion: “Your suggestion may work in an ideal world, but it can’t work in the real world.”

Why bizarre? Because they are experiencing challenges in their work and they have engaged outside helpers to advise them, and yet they dismiss the helpers’ advice out of hand. If all they intend to do is continue working in the same way as before, and claim that nothing will work “in the real world,” why do they bother to spend time and money to engage outside help?

Many people assume the advice we offer was just made up on the spot, or represents some academic theory that hasn’t been tried in the field, or requires the organization to be perfect even before they can try to implement the advice. In reality, the things we suggest are not new.

Continue reading In an Ideal World

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 Thanks to John Arundel ( 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 You can try it out online here:,

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