Do we avoid breaking changes too much?

In the software industry do we avoid breaking changes too much? I am talking about the big stuff. I am talking about browsers and programming languages. Breaking changes are difficult in these systems as there are multiple groups that need to coordinate to implement the change.

What is a breaking change? A breaking change is an upgrade that sacrifices compatibility with previous versions. For example, Python 3 was a breaking change, Python 2 code will not run on the Python 3 interpreter. This may be thought of as a branch. Breaking changes are noted by a change in the ‘major’ version number. For example 2.0.0 to 3.0.0 is a breaking change. See: Semantic versioning

Breaking changes are a big deal. I don’t want to under-emphasize this fact. There are people still upset about Python 3. Breaking changes incur costs to the users of the code. And if there are a lot of users then there are a ton of costs. But there are benefits, python 3 has risen to the top of the charts. I think the change to 3.0 allowed Python to expand to the king of the hill status. Without that breaking change, Python fades away.

A technology we have held on too long is a ‘Turtle’ technology (I just made that up, so don’t go Googling it). Developers that use a technology too long are called ‘Turtles’. They lock onto it like a snapping turtle and won’t let go. They growl at you and doubt your sanity if you suggest an alternative or doubt the rightness of it.

For some perspective let’s look at something that the a group of developers held on to for too long. Let’s talk about IBM’s green screen. Known as IBM 3270 and IBM 5250. Subsequently called 3270 in this essay. 3270 was developed in 1971 and was a very good solution for communication to a mainframe on a remote terminal. You could do anything on a 3270 including programming and debugging. But the 3270 was character-based and could not display graphics or bar codes. I worked in the AS/400 and IBM 5250 in 1995 and the developers were in the full turtle mode. Their forceful obstinacy seemed, to me, a bit irrational.

In the end, IBM wrote Java drivers for the database and all the systems for the AS/400, and we wrote a web page interface in short order. IBM even added Java to the AS/400. After which green screen development decline to a natural level for applications in which it makes sense to use, data entry applications, and such.

Another turtle technology is the ‘C’ programming language. C turtles are not the irrational kind. They acknowledge the problems of the language, such as buffer overruns and race conditions. C was created in the 1972-1973 time frame. It remains a very popular language and is the ‘go-to’ language for systems programming, low level, and embedded. C has several descendants such as C++ and C#. C++ adds object-oriented programming but still suffers C’s problems. C# is just Java misspoken and is more of a Java descendant than a C decendant. Both are very good, but neither one was designed to be a ‘systems’ language. I don’t know why it has 48 years to find something better. It may be the C is just that great. The good news it is looks like Rust may be the successor to C. Rust fixes most problems with C and still remains a systems-level language.

Try not to be a turtle. Remember all technologies will lose popularity. If your favorite tech is currently falling and in ridicule then recognize, accept it. Don’t take it personally. Don’t disparage your fellows on the other side. You can take steps to reverse the demise or move to something new or just live with it and ride the bubble down the drain.