Kent Beck fired from Facebook

Hello to all my non-existent fans! It has been a while since I’ve written anything on this blog, but I figured I’d start adding content again. In particular, I’d like to do what I’m going to dub “Tech Talk Tuesdays”. I have a habit of watching famous (or semi-famous) techies talk about the software industry. This seems like a good place to knowledge share and condense some of the thoughts in the talks that I view. The videos/talks themselves are typically close to an hour long, or longer, and I don’t think everyone has the time to go through them. I’m boring/nerdy and so I watch the talks regardless of the time sink. I’ll do my best to condense the good info into a 10-15 minute read. Every Tuesday I’ll be posting about one of these talks.

This Tuesday we’ll be going over an interview from one of my software heroes, Kent Beck. He is one of the signers of the Agile Manifesto (https://agilemanifesto.org) as well as the author of “Test Driven Development By Example” (a fantastic book, and well worth the read if you haven’t read it already). Kent is also responsible for creating XP (Extreme Programming). I use Test Driven Development (TDD) almost every day as a developer, and I take a lot of ideas from the XP playbook as well.

In this talk, Kent talks about:

• The “old way” (1990s) of developing software, and how we may have reverted back to them
• Why XP was not marketed/sold as Scrum has been
• His experience at Facebook including “Agile” at Facebook, what he saw as problems at Facebook, Facebook’s performance evaluations, and how honesty (possibly brutal honesty) got him fired.

Just going to ramble about each of these points in order. Before we get started, here’s the full video (no need to watch it, just listing it here for those who are interested). Kent is being interviewed by Richard Atherton on his Being Human podcast:

The “old way” of developing software (Waterfall) vs. XP/Agile:

Let’s quickly go over “the old way” of software development.. “The old way” consists of a few steps. In short, they are: gather requirements, design, implement, test and maintain. Typically each phase would last a few months. So we take a month, or at least a few weeks, to gather requirements, a month to design, a few months to implement, a few months to test/bug-fix, and then there’s the maintenance phase (which might go on indefinitely and is a whole topic in and of itself). This is referred to as the “Waterfall” development model, and has become somewhat of a curse word in the software industry.

Some problems with Waterfall include:

• Spending enormous amounts time on non-development activities such as gathering requirements and design.
• Dogmatically sticking to a design that was planned out far in advance of actual implementation, regardless of the design’s inherent flaws (the design phase is over when implementation occurs).
• Testing at the end of the development cycle.

A prime example of a Waterfall failure is the ObamaCare website, Healthcare.gov. In particular, this website cost $500 million to launch, and it’s estimated that the site has cost a total of around $2.1 billion after catastrophic launch failure.

How do I know Healthcare.gov was designed with Waterfall? Unfortunately, most government projects are developed with Waterfall. I’m the primary source/reference for this claim, as I worked for Lockheed Martin for 3 years doing mostly government contractual work. Additionally, NPR (among others) ran a story about it.

The more modern way of software development that Kent references in his video is what’s usually referred to as “Agile”. In particular Kent talks about Extreme Programming (or XP), which is an Agile software development methodology. The idea is to work in shorter iterations, as opposed to having long phases, and just keep repeating/iterating until the project is complete. For example, small design, small test (test first!), small amount of code, quick review, and merge this little chunk into the codebase. In this way, the developers are able to react to changes in requirements and can deal with unexpected issues on the fly. XP is also a strategy that guarantees value, as every time a little chunk of code is produced, something is now working/functional that was not working/functional as of yesterday. Every iteration produces something of value. If the project suddenly loses funding, gets cut short, or time runs out, at least something of value is produced. This is in stark contrast to Waterfall, where the system usually doesn’t work in any capacity until after the testing phase (which occurs months or years after requirements, design, and implementation).

How about we start with the assumption that we are going to learn stuff? Because we are going to learn, everything needs to be prepared to change. …. It sounds so adult. “Let’s get this architecture right so we don’t have thrash if we have to change the architecture”. Who could argue with that? Well…you can’t get the architecture right up front…

–Kent Beck

This is just an awesome mindset. We typically do learn as we go. So it makes sense that we should be apt to change, and try to incorporate what we’re learning as we’re going. Being adaptable and continuous improvement is core to any Agile process.

I was in South Africa, at Agile Africa, and somebody came up to me and said “Well, we want to do software development, but we just can’t stand all this ceremony and Agile stuff. We just want to write some programs.” And tears came into my eyes…like…how can it be that we who set out to refocus development on essentials and get rid of stuff that didn’t matter, how can it be that we’re right back where we were 20 years ago? Like how can it be that “this is too much ceremony”? … No, this is wrong. I don’t know what to do about it.

–Kent Beck

Interestingly, Kent thinks we’re sort of back to where we started, and I think he’s mostly blaming Scrum. Scrum and Agile are commonly confused (Scrum is a particular implementation of an Agile methodology), and apparently that’s what happened in Agile Africa.

To be fair, I’ve seem Scrum work wonders for projects, and it can be really great depending on the organization/team. Scrum is a bit ceremony heavy, but sometimes the ceremonies, organization, planning, and prioritization are useful for more chaotic development teams. And sometimes they’re not very useful. So if Scrum doesn’t work for your org/team…then don’t do it! That’s the most Agile thing you and your org can possibly do. Don’t be afraid to actually be Agile and learn from your Scrum process, and heavily modify the framework to fit your team’s needs. This is where Scrum falls apart for some orgs. To quote the last principle in the manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Why XP wasn’t monetized like Scrum:

Kent also talks briefly about why XP was not marketed as Scrum has been marketed, and why he chose not to monetize it. He simply claimed that monetizing XP didn’t seem particularly moral. XP puts it all out there, makes developers confront their own limitations/weaknesses (paired programming), and that’s not particular comfortable. It sure is effective at developing high quality software, though, and at the end of the day that’s what counts.

Kent claims he has serious reservations about certifications and how they mis-align incentives.

You attend a 2 day training, and you get this title, and you can put CSM: Certified Scrum Master after your name, and it didn’t actually mean anything. It should have been AST: Attended Scrum Training….but certified, whoa, who doesn’t want to be certified…Scrum, okay, already with the branding. Master! Who doesn’t want to be a Master? It’s a lie though. After two days, you’re not a master, anyone who certifies you is lying, and to me that whole edifice, certified scrum trainers, certified scrum trainer trainers, and then blah blah blah, it’s starting to look like a Pyramid Scheme to me. And none of it is honest. It’s built on this “hey, I want to look better than I actually am”….and I brought this up at the time, and the answer was “but nobody would come to the classes then!” Okay? And then…? I’m not clever enough to build an edifice on deceit. And this is going to piss some people off…I’m back! I’m off the goat farm. Look out!

–Kent Beck

I have mixed feelings about this, as I know some fantastic folks who have been through this training. But I think they were fantastic before the training. I’m not totally convinced that CSM training is worth the money or time, since you can get most of the information online for free, and Kent does have a point that you don’t become a “master” of anything in two days (it takes time, patience, practice, and experience to “master” Scrum, i.e. how to implement it, figure out it’s ups and downs, where it’s useful and where it’s not, etc).

What I really appreciate is that Kent is an honest person. We need more people like that in tech. Is there something wrong with sharing ideas and not making money? I don’t think so, and neither does Kent. He’s given us XP, TDD, and other great ideas, and essentially did it for free. Sure, there are books and Kent’s made some money off it, but all the information is available for free, and you don’t have to be a certified TDD-er or certified XP practitioner.

Working at and Fired from Facebook:

Kent had plenty of nice things to say about Facebook, including what I would describe as them being truly Agile (not over engineering, being very flexible and ready for change, and not trying to predict the future). I think we know that Facebook is a pretty strong tech company, and so it probably doesn’t come as a surprise that they have a reasonable methodology/attitude towards software development.

Kent also talks about his 3E idea (Explore, Expand, Extract) that he conceived at Facebook. I won’t expand too much on here as it’s a big topic in and of itself, but there’s plenty of videos on it if you’re interested. In short, every successful project starts with an Explore phase. Then something (typically unpredictable) catches on and “takes off” (consider Flappy Bird, or other viral apps/games/videos that you may think are popular now, but it would have been hard to predict 10 years ago that they’d be popular). After you get some “take off”, you then Expand and scale the idea/product. Lastly, the idea/product should start to stabilize as a user base grows, and that’s where you can Extract the most value as this is the most predictable stage of any idea/product.

The video got more interesting when Richard asked Kent if there was anything Facebook could be doing better:

So, when I joined Facebook it was 2,000 employees. When I left it was about 25,000. I’ll try to give you the short version of what I think kind of went wrong. Facebook’s culture is very focused on a 6 month review cycle. Every 6 months, you need to prove what “impact” you had on Facebook as a whole. That word “impact” is a really important, kind of magical word, that has a very special meaning inside of Facebook. So you should be able to say “Here’s the metric I cared about, and here’s what I did, and here’s the effect I personally had”. You need to do that every 6 months, and I need to do that every 6 months. That focuses everybody on the upside of what they’re doing. … If you’re exploring stuff, being focused on upside (impact) is fine. You’ve got nothing to lose … Now you’re expanding rapidly, and “impact” still is a good criteria … the problem is when you come to the Extract phase as a company, which Facebook is as a company, we are running out of people on the planet to Expand to…so now you’ve got a lot to lose. Facebook the company is still focused on “what’s your ‘impact'” … so if you’re developing a messaging feature, and you’re getting to the end of your 6 months and you need a win, if you can show that your feature ups messaging by .2%, then you’re going to ship that.

But what if there are downsides? Like that feature makes it easier for someone to social engineer extracting private information, what if it just makes the app more cluttered…you have no incentives to look at the downsides of what you’re doing. Because all the incentives being applied to you are all about the upsides. And at some point if you say “well I’m not going to put this feature in because I’m not comfortable with the downsides”, then you’re screwed. No one is ever going to make a good decision for the company that then makes their own review harder.

At some point Facebook needs to switch to focusing on impact to focusing on the quality of decisions. People should be rewarded for making good decisions, regardless of personal “impact”. … Problem with quality of decisions is it now boils down to your ability to present this as a good decision.

I think the takeaway from this is performance reviews are hard. And no matter how you organize it, folks will game it, and some part of it won’t be fair. I do agree with Kent, though, that not looking at the downsides of what you’re doing is pretty blind. I guess it’s less surprising that something like the Cambridge Analytica could happen with this “personal upside only” incentive scheme.

Richard: And was that a conversation that was live in Facebook? Like what you’ve just brought up, or was that just sort of a personal insight?

Kent: Well, I got fired trying to have it, so…

Typical Kent, trying to do the right thing, regardless of the cost. Unfortunately, this time the cost was him losing his job.