About Bob Martin’s talk — The Future of Programming (2016)

Overview

I am a bit late to the party, but still. Robert C. Martin, colloquially known as “Uncle Bob”, gave an exciting talk in May 2016 about the future of programming. The relevance of his words still stands, and it is a beautiful history lesson about software engineering, programming as a profession with remarks about Agile and possible future of the industry.

Below you will find main topics from this talk that captured my attention, links to the facts, articles and papers he mentioned; plus, my personal opinion on some of them. Still, the best course of action is to watch the talk itself.

Objective C history

In the beginning, Robert briefly mentions his version of the Objective C history in early ’90s. From his point of view, Objective C had to die at that point because, in general, C++ was a better evolution of ANSI C and both languages competed on the same field. But a series of circumstances saved Objective C. Steve Jobs was forced out from Apple in 1985 and founded NeXT, Inc to compete with Apple. There were not many programmers available on the market, but Objective C specialists experienced some problems finding new jobs. As Robert said:

There were a bunch of guys on the street holding up signs “We will code Objective C for food.”

– Robert C. Martin

NeXT hired them, and all these programmers produced the NeXTSTEP operating system. Within a few years, Apple announced that it would buy NeXT for $427 million, bringing Jobs back to the company. And Steve brought all the NeXT team along including all Objective C programmers. NeXTSTEP OS was part of the deal as well. It was the team that started to work on the iPod prototype and, as you can imagine, Objective C was the primary language. So, in short, that is how Objective C was resurrected from the dead. Or saved.

Alan Turing

During the talk, Robert references Alan Turing a lot. Probably, the first person actually to write code that we can recognise as code, Robert said. In his works, Alan Turing defined variables, subroutines, floating-point principles, many things we use every day as programmers.

There is a remarkable paper from Alan Turing, “On computable numbers, with an application to the Entscheidungsproblem” (November 1936) that set the limits of computer science. It defined the Turing Machine, a model for all computations. On the other hand, it proved the undecidability of the halting problem and Entscheidungsproblem and by doing so, found the limits of possible computation.

If you want to learn more about the guy, I highly recommend “The Annotated Turing” book from Charles Petzold (the guy behind Microsoft Foundation Class Library (MFC) and former software engineer) that Robert mentions in the talk as well.

Robert says a lot about programming discipline and why it was supposed to be based on the shoulders of mathematicians. In his opinion, there are many problems with mentoring new programmers and lack of fundamental knowledge. This topic is a bit controversial but the funny is thing that Alan Turing predicted the problem after writing “a few hundreds of lines of code” more than 70 years ago:

“One of our difficulties will be the maintenance of appropriate discipline so that we do not lose track of what we are doing.”

– Alan Turing, Lecture to the London Mathematieal Society on 20 February 1947

A quick note about GOTO statement and what not to do

At the pre-ALGOL meeting held in 1959, Heinz Zemanek explicitly threw doubt on the necessity for GOTO statements; at the time no one paid attention to his remark, including Edsger W. Dijkstra, who later became the iconic opponent of GOTO. The 1970s and 1980s saw a decline in the use of GOTO statements in favour of the “structured programming” paradigm, with goto criticized as leading to “unmaintainable spaghetti code”.

– Wikipedia, GOTO

So, in 1968, Edsger W. Dijkstra wrote his quite famous “Go To Statement Considered Harmful” article. And it was one of the first examples of programmers starting to improve the technology and the discipline itself. I mention this fact as an example because I agree with Robert on his thoughts:

“What we have learned since the ’70s is more on what not to do than what to do.”

“If we have made any advances in software, since 1945, it is almost entirely in what not to do. Structured Programming was in what not to do — don’t use unrestrained GOTO. Functional Programming — don’t use assignment. Object-Oriented Programming — don’t use pointers to functions. What we have learned over the last 70-some years is more about what not to do, than what to do. There have been no radical advances in software technology. The craft of writing software remains roughly the same as it was in 1945 — a little more modern, but not essentially any different.”

– Robert C. Martin

See? Almost all modern paradigms were built on top of the “not to do” practices. From Robert’s point of view, we are more or less capable of agreeing on bad things but it is tough for us to agree on something new and go in the same direction, and this is one of the biggest challenges we have with the discipline:

“We have a problem: we do not agree on our own technical disciplines.”

– Robert C. Martin

We know a lot about which things to avoid, hundreds of bad practices and anti-patterns. But, on the other hand, there are too few general principles to follow. We are learning and creating new languages to solve specific problems, dancing with generics on top of the generics, copy-pasting templates and consuming articles about syntax sugar as best development practices. But fundamentally, since the ’70s, not many things have changed in software itself. In the end, your program will operate with if statements, assignments and while loops.

“You would recognise the code that Alan Turing wrote on the ACE machine. You would not like it, but you would recognise it.”

– Robert C. Martin

What happened to the discipline

It is quite interesting to listen to the guy who experienced all the changes in the discipline during all these years. For example, Robert stated that back in the ’60–70s the situation with programmers looked like this:

- Up to now programmers were disciplined professionals;

- They did not need a lot of management or process;

- They knew how to manage their time, communicate, and work together;

- They understood deadlines & commitments. What to leave in and what to leave out.

– Robert C. Martin

At that time, with the principles mentioned above, programmers built great software. Or, as Robert said, “They knew how to get big things done”:

• IBM 360 Virtual Memory OS — the first family of computers designed to cover the complete range of applications, from small to large, both commercial and scientific;
• NASA Project Mercury — the United States’ first man-in-space program;
• NASA Project Gemini — second human spaceflight program;
• NASA Project Apollo — human spaceflight program which succeeded in landing the first humans on the Moon from 1969 to 1972;
• Structured, Functional, Object-Oriented paradigms;
• Fortran, Cobol, Algol, Lisp, C, Unix;
• And many more.

I want to mention Margaret Hamilton — director of the Software Engineering Division of the MIT Instrumentation Laboratory, which developed on-board flight software for NASA’s Apollo program.

And, at this point, let’s talk a little about Agile.

Agile manifesto

In 2001, these seventeen software developers met at a resort in Snowbird, Utah to discuss lightweight development methods: Kent Beck, Ward Cunningham, Dave Thomas, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, Robert C. Martin, Mike Beedle, Arie van Bennekum, Martin Fowler, James Grenning, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, and Steve Mellor. Together they published the Manifesto for Agile Software Development.

– Wikipedia, The Manifesto for Agile Software Development

Note: By lightweight development methods they assumed rapid application development (RAD), from 1991; the unified process (UP) and dynamic systems development method (DSDM), both from 1994; Scrum, from 1995; Crystal Clear and extreme programming (XP), both from 1996; and feature-driven development, from 1997.

So, Robert was part of the group behind the manifesto, and his explanation fits well with my mind. Programmers were not just operators anymore, and they needed to be part of the whole process of creation. And Agile is about all the promises you make and not a list of tasks you follow. This perception has faded in the modern world, and Robert assumes that it happened when business got in the way. The business was totally in line with what the Agile movement offered, the whole set of principles made sense to them, and they understood discipline. However, the business started to take control of some of the engineering practices, and Agile helped them. In worst cases, programmers have to discuss technical debt, refactoring and technologies with the business and ask for permissions to control simple engineering things. The issue is that business does not always understand (and, frankly, should not) what programmers are doing. So, once project managers took control over Agile (via Scrum, for example), it became less technical. Ironically, one of Agile’s goals was to “heal the divide between business and programming” (Kent Beck).

Robert believes that Agile has failed and that things have to change. Again. Programmers have to step up and define their profession, their practices, and the discipline they use because they are the ones who have the expertise to do so. Programmers have to handle technical risks and take these risks as professionals.

There is a helpful article from Martin Fowler — Flaccid Scrum about more or less the same matters.

“The Scrum community needs to redouble its efforts to ensure that people understand the importance of strong technical practices. … If you’re looking to introduce Scrum, make sure you pay good attention to technical practices. We tend to apply many of those from Extreme Programming, and they fit just fine. XPers often joke, with some justification, that Scrum is just XP without the technical practices that make it work.”

– Martin Fowler

I can recognise a lot of failed/struggled projects from my experience in the way Robert describes the phenomena:

“Flaccid Scrum — an efficient business discipline coupled to an undisciplined engineering team, will very rapidly make a mess.”

– Robert C. Martin

Also, an interesting point was made about the fact that Agile is in line with Alan Turing’s thoughts on the future of the profession. Turing said that discipline and ability are essential parts of the prosperous future, and Agile declares that discipline, craftsmanship and professionalism are the directions to go.

Historical references

These are links to some hardware, software and events mentioned in the talk.

• Automatic Computing Engine (ACE) — a British early electronic stored-program computer designed by Alan Turing;
• Delay Line Memory (Mercury delay lines) — a form of computer memory that was used on some of the earliest digital computers;
• Cathode-Ray Tube — have been used as memory devices known as Williams tube;
• Lisp — the second-oldest high-level programming language in widespread use today that refuses to die;
• Simula 67 — considered the first object-oriented programming language;

Bottom line

Professionalism. Discipline. Attention to details.

These are the base principles for better programmers. It sounds easy and obvious. Why not to try?

P.S.

Sadly, this talk heavily foreshadows the situation with Boeing 737 Max.

Originally posted here.