Skip to content

Instantly share code, notes, and snippets.

@asmallteapot
Created April 12, 2012 15:14
Show Gist options
  • Star 8 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save asmallteapot/2368038 to your computer and use it in GitHub Desktop.
Save asmallteapot/2368038 to your computer and use it in GitHub Desktop.
Notes from @UncleBobMartin’s Demanding Professionalism talk in Tampa, Florida on 11 April 2012.

Demanding software professionalism

Presented by Bob Martin in Tampa, Florida on 11 April 2012.

Miscellany

“Uranus is not a naked–eye object under any circumstances.”

  • Copernicus’ motivation was religious, not scientific! Galileo looked at the phases of Venus to determine its orbit in relation to Sol.

Bob: How do you become unafraid of your code?
Audience guy: Change jobs.

Is anybody here good at estimating? (If anyone raises their hands, they’re lying.)

If you don’t care about the number of defects, I can get it done on any schedule you’d like!

What’s the matter here in Florida?

Objective-C! puke

The Software Crisis

“How many times per day do you put your hands in the life of some code written by some 22-year-old at three in the morning?”

“How many times do you put your life in the hands of an if statement…? Our civilisation depends on software, and that trend is doing nothing but increasing.”

“Sometime in the next decade, there will be an accident, and it will kill thousands of people, and it will be because of some software that was written by some 22-year-old at three in the morning. And the government will regulate us.”

The two main schools of philosophy in software development are: iterate slowly and throw out planning almost entirely, or, imitate other engineering fields.

We think of engineers as builders, but they don’t really build things. Engineers are specifiers. An architect is an engineer, but he creates the blueprints and diagrams, but not the house itself. This philosophy has dominated our industry ever since.

In conventional engineering, the build is much more expensive than design. In software, the reverse is true. The cost of the build step is basically nothing; the design is much more expenive. This changes the way you build things.

…digging the basement, filling the basement back in…

“Software doesn’t have a foundation! There’s no digging!”

Winston Royce’s paper set up waterfall as a strawman that he could tear down. Waterfall has been used as a serious model ever since.

We have forgotten that there is a software crisis.

The Software Crisis is that we are not professionals.

Our software has defects. That is unprofessional.

The Test Plan

Quality Assurance exists because we are not doing our jobs correctly. They run our software to find problems in it. We could do that…

The Test Plan

  • That is not the test plan. That is just the table of contents.
  • Most of these tests could be done by a machine.
  • If you are a professional, QA should hardly ever find anything.
  • Finding a bug in the QA step should be cause for a good deal of reflection.

Words of Unprofessional Behaviour

Afraid of your code (Here Be Dragons)

  • The notion that we can do it right the first time is a fallacy.
  • We need to be able to iterate, and that means automated tests.
  • If the tests pass, ship it.
  • If you don’t trust your tests, you’re doing it wrong.

Uninverting the cost model (Expensive Builds)

  • Manual testing and deployment are the number-one cause of this.
  • Automated tests that take a long time also fall under this.

Make commitments you can’t keep (Rushing)

  • Managers will ask you for committments.
  • Everything now belongs to the commitment.
  • Don’t make the commitment! Instead, come up with estimated ranges.
  • If it’s perfect, x. If it takes a while, y. If everything goes wrong, z.
  • “Will you try?” — “I’m already trying!”
  • Rushing means you’re slowing down.
  • If you’re a professional, you don’t rush.

What is professionalism?

Short Cycles

The average agile sprint is about two weeks now, because that provides frequent feedback points. Every week is even better. The idea is that there should be no form of technical debt after a sprint – you should be ready to deploy.

Test-Driven Development

The TDD cycle – as newbies envision it – doesn’t actually work, because you can’t get anything finished in a reasonable amount of time.

Uncle Bob has a blog post explaining this better than my notes could.

How do we demand it?

(This is where my laptop’s battery died. Please fork and add your own notes here.)

@oelbrenner
Copy link

nice man.. thanks for writing this up.

@perty
Copy link

perty commented Apr 12, 2012

Did Bob say TDD doesn't work?! Find it hard to believe...

@asmallteapot
Copy link
Author

asmallteapot commented Apr 12, 2012 via email

@solojavier
Copy link

TDD doesn't work?? The article you are posting from unclebobmartin says it do work, this are his own words at the end of it:

"Given all these benefits, these stupid little rules of TDD might not actually be so stupid. They might actually be something fundamental, something profound. Indeed, I had been a programmer for nearly thirty years before I was introduced to TDD. I did not think anyone could teach me a low level programming practice that would make a difference. Thirty years is a lot of experience after all. But when I started to use TDD, I was dumbfounded at the effectiveness of the technique. I was also hooked. I can no longer concieve of typing in a big long batch of code hoping it works. I can no longer tolerate ripping a set of modules apart, hoping to reassemble them and get them all working by next Friday"

@asmallteapot
Copy link
Author

My notes for that section are incomplete. That section of the talk was, in full, very similar to the blog post I linked to. Sorry for the confusion; I’m editing the text of the gist to make it more clear.

@solojavier
Copy link

Thanks for the clarification, I was really confused, sorry about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment