Uncle Bob Martin challenges software industry to Grow-up

The State of Software talk by Robert C. Martin

London, UK 1st May 2018 at Skills Matter, for Scrum Event

Agile Manifesto author and software expert Robert Martin asks if it is time for us to take responsibility for our work? Can we admit that Agile hasn’t worked? Will we sit at the adults’ table and join a discussion without upsetting anyone?

Charming, intelligent, and original, ‘Uncle Bob’ Martin defies the typical image of a computer programmer. He is an accomplished public speaker, who effortlessly held the attention of two hundred people for an hour.
Uncle Bob Robert C Martin State of SoftwareHe chunked his talk on the state of software into four timeboxes of fifteen minutes each.

Except he didn’t say ‘chunked’ or ‘timebox’, he simply told us the talk would be in four parts: Programming; Process; Professionalism; Politics, and that each would be fifteen minutes. I savoured that simple act of leadership by example.

Martin uses his own language and is comfortable sharing his own approach to work. Social media has taught people how to gain community approval by using memes and hashtags, and we have got used to this. By being original, Martin served his audience with an opportunity to think for themselves. I certainly did, reflecting on the points he raised as I drove home after the talk.


Finding the perfect programming language

Rapidly surveying his audience, Martin listed fifteen different programming languages that people knew, without even mentioning Basic or JavaScript. Rhetorically, he asked why we have so many, wondering if it is because we hate the language we are using so much that we have to create a new one. Then he asked whether the benefits of learning a new language could possibly be worth the effort involved.

Martin remembers the impact of assembler as a means of programming. He said it increased productivity by an order of magnitude of perhaps a thousand.

The move from Assembler to Fortran was significant too, but Martin believes the impact on productivity was not as large. As for Fortran to C, then to C++ and Java, they were improvements that made programming better or easier. Although it didn’t always work-out that way in the case of C++, these improved languages resulted only in fractional increases in developer productivity. For example, although dynamic typing in Scala and Kotlin is faster than explicitly writing class definitions, it is unlikely that the saving of a few minutes of typing has any real impact on software development.

One language to rule them all

Instead of pursuing the endless quest for the ‘golden language’ why not pick one and just use that? He asks, pointing-out that most new languages are merely variants of each other, and there has been no innovation for a very long time. Perhaps none since Fortran.

I admit I only know a handful of languages, so I didn’t feel very affected by this. Then he mentioned frameworks and said it applied to those too. The JavaScript guys in the row behind me had the same realisation at the same time as me. Probably they were thinking of the Brutal Lifecycle of UI Frameworks whilst I was remembering an endless succession of data access libraries and SOA toolkits.

Martin is challenging developers to accept the diminishing magnitude of improvement of tools and to concentrate on making a good job of writing software instead.

Thinking further about this, I wonder if this is a symptom of us (stereotypical) techies avoiding eye contact with the real world. Many of us would rather focus on our preferred activities, such as researching new frameworks and languages, or gaming than attend to the rather serious business of being fully-present developers of software. Perhaps this is what Martin wants us to think. It certainly fits with his later theme of professionalism.


Wanna know how Uncle Bob really feels about Agile?

“The divide between business and development teams could have been healed by Agile, but it hasn’t worked that way.”

Martin was one of the seventeen people that met at Snowbird to discuss and agree the values and principles of the Agile Manifesto. As one of the few without a corporate agenda to support, Martin spoke plainly about his ambitions for what became known as Agile, and what has happened since that meeting.

Although we didn’t recognise his labels at first, and his observations of some of the effects of these methods were consequences I had not before considered, the anti-patterns Martin described were well-known to the members of the audience. He talked of:

Organisations doing ‘flaccid Scrum’ who are merely calling their activities Scrum. They are unaware that it takes a lot of technical control to develop software right, and calling it Scrum doesn’t stop you grinding to a halt if your process and skills aren’t good enough.

There are those doing ‘Scrum fall’. They want a points estimate just so they can plan how many sprints the work will take. That’s just waterfall, so no change of any significance can possibly occur.

The ‘agile mindset’ brigade focus on getting people to think the right thoughts, yet they overlook the fact that there’s considerably more to development than ‘getting your mind right’.

The ‘Invasion of the PMs’ started with a story about Ken Schwaber borrowing a classroom because he wanted to start a Scrum master’s course. According to Martin, the resulting success of certified Scrum master training has backfired on Scrum. This is because project managers have used Scrum certification to regain control of teams. In that sense, Scrum has failed because of certified Scrum masters.

At Snowbird, Kent Beck had said that Agile (although it wasn’t called that yet) was invented to fix the gap between the business and development teams. Martin believes that “although that divide could have been healed by Agile, it hasn’t worked-out that way”.

Responding later to a question about what Scrum masters should be doing, Martin explained it should be a temporary role, to remind people to follow the steps of the process. It’s not a separate job, but something one of the team should do for a bit, then pass it on. After a while the team shouldn’t need a Scrum master as they will know how to operate their process. Maybe they will forget it later and need a Scrum master again for a while.


“Under no circumstances should a Scrum master be responsible for budgets, schedules, or delivery.

Nobody reports to the Scrum master.”


Agile in the large

There may have been several certified Scrum masters in the room, but judging by the warm laugh Martin got introducing ‘really big Agile’, there weren’t many SAFe, Nexus or LeSS masters present.

He stated it plainly

“Agile was never intended for this and there’s no way you can take a 200 person project and run it in an agile way”. Adding “What you can have is twenty Agile teams”.

His key insight here was that humans are actually good at building big things. For a very long time, we’ve known how to build pyramids, land on the moon, create cities and dig tunnels. It’s the small things we’re bad at, and that’s where agile helps.

“Agile has made a huge difference to small teams. It’s not going to make a difference to large ones.”



White-haired and avuncular, ‘Uncle Bob’ remembered starting-out in 1969 when nobody even knew what a programmer did. Today, everyone interacts several times each day with software systems. Society relies on software to buy and sell goods, drive a vehicle, and pass laws, yet society doesn’t realise how much it depends on software developers.

As an industry, he wants software developers to rise-up to absorb that responsibility. To code with ethics and dignity. Last year, in an interview with Ben Linders for InfoQ, Martin argued similarly, proposing an Oath for Programmers.

As with the Agile Manifesto’s principles, it is easy to agree to these ideals and much harder to understand how they affect routine work.

Knowing this, Martin tells a story of how a thermostat in his home was recruited by hackers and used to attack a corporate network. His point is that the people who wrote the code for thermostat did not think about how it could be weaponized. They took no responsibility for it.

Anticipating the objection that they were doing the work that was expected and requested of them by their managers, Martin spoke of the Space Shuttle Challenger disaster. NASA’s engineers knew the O-rings could fail but were unable to persuade NASA officials to stop the launch. However, none of them called Dan Rather at CBS news. None of them was prepared to throw their job on the line to prevent it.

Martin asks us to consider the ‘responsibility of knowledge’ for our work.

Testing, 1…

Worryingly, only about 10% of the audience raise their hand when Martin asked how many people practiced TDD. He wondered if Londoners had stopped doing it, but I suspect the question caught people unawares after such a dramatic build-up.

However, the title on the slide was ‘TDD Rant’ and nothing else needed to be said.

This section wasn’t all gloom and doom though since he noted that marketplaces such as the AppStore were successfully self-regulating the work of developers. Hopefully, someone will create a framework store, although it won’t be him.


Office Politics

Nobody expects politics in a developer’s talk, but Martin wanted to raise two points. The first was about who does what in the office and concerned the roles of teams and managers (search #RoleoftheManager on Twitter if this interests you). The second was really about freedom of speech whilst in the office.

Thinking back to the meeting at Snowbird, Martin recalled they expected teams to be well-structured groups of developers. Probably with a team lead, who was an experienced programmer, and a Scrum master who knew the rules of Scrum.

There was no suggestion that they would have no managers, nor that everybody would be equal under Agile.

Agile was never a manifesto for an egalitarian workplace.


An environment where it’s Safe to Speak

Finally, Martin asked if anybody should be fired for expressing their views, even if those views were not popularly held, or were politically naïve.

He provided several examples of noted technologists who had lost their jobs because their views were distasteful to others, or because they supported the other side of a public debate. He then cited the case of Google technologist programmer James Damore, whose internal memo caused such offense that it got him fired. Martin said he read the memo and found nothing offensive to him (although this wasn’t the view of others).


Growing-up is hard to do

Superficially, Martin was raising the importance of holding a discussion and of ensuring it is always safe to have that discussion. Yet by connecting the threads of this deliberately thought-provoking talk, it seems that Martin wants developers to take responsibility for their own behaviour as professionals, as well as taking responsibility for the behaviour of their software.

Growing-up and taking a seat at the big table means more than just giving-up chasing the next language or framework and concentrating on the job of writing code. It means being present within society, listening actively for information that may not be verbalised, and then taking responsibility for that knowledge.

The talk we heard was more thought–provoking than a technology lecture. It was very much Uncle Bob’s State of Programming address.

You may also like...

Leave a Reply
