Kent Beck captured from hack.summit() 2016

I deleted my favourite game in the world, Civ V, a game I have played over 1200+ hours over the past 5 years. Parting was hard, but necessary, so I could free up time to do more writing.

I have a few writing exercises under my belt. They are ok. Nothing is ground breaking. But today, I have been given a challenge to write about Kent Beck in his remote interview from hack.summit() 2016

Kent Beck’s Life

The interview starts with a few questions about his home life and his children. His 5 children were home-schooled with the latest one just about to enter college.

He lives in a rural area with his wife. They grow their own food and keep a light pack of livestock. Most of his friends are non-tech people. This is rather strange. I didn’t expect the father of extreme programming, the co-founder of the Agile movement, the advocate of test driven development, and a senior engineer at Facebook to not be living in the holy land of technology — Silicon Valley. Instead, he chooses a simple life and works remotely.

His day job at Facebook

Kent’s day to day work at Facebook is mostly one on one coaching. It is about 80% of the time. He recalls his younger years, when he was mentored and learned a great deal from that period in his life.

When he first got to Facebook, he found himself surrounded by better programmers than he was. But there was a lack of mentoring. So that is where he starts his contribution.

His mentoring also spread out into classes if he taught the same topic to many of his students. The topics are diverse, starting from very basics, like time-management and how to self-prioritise. His goal is to turn Facebook into a place where one can become a good engineer, instead of a place where you do good engineering. Not everyone had to be thrown into the deep end.

Most of it is done via pair programming and remotely.

His exploration works

Kent said something very interesting. He said it is a responsible of an engineer to research. Most of the time should be invested in working on something that will pay off. But also, one must do something risky that may or may not pay off.

There is also a book in the works, as well, titled, “How Facebook works.”

Best practices?

When asked if there any best practices he encourages people to follow at Facebook, he said something very interesting. He said to imagine talking to a dog. When you point a finger at a chicken, a dog wouldn’t understand. It will look at the finger, instead of the chicken. No matter how hard you point.

So, that is how he felt about best practices. The focus on best practice is dangerous. There is no point telling people what Facebook is tracking or doing, because that is the finger, not the chicken.

He said, don’t look at the numbers or practices. That is the finger. The chicken is the sense of a shared and common goal. How you get there depends on each organisation.

Just learn the practice and copy it. That is the finger. It is not the point.

JavaScript and its mess

When asked about design pattern on how to tackle a messy work of asynchronous development in JavaScript, he is not sure, because he has not worked on that for some time.

Instead, he refers to his principle. He said to focus on the feedback cycle and the length of that. What would you have to do to make the feedback cycle run 50% faster.

If somebody coded for an hour before he learned the impact of the code, it takes too long. The goal is to make it easier and faster to catch the error.

On Test Driven Development (TDD)

On a normal workflow, it is development and then testing to see if it runs and if the feedback cycle is long. Now, the CPU runs much faster, but people have not yet fully used it.

Then comes Test Driven Development. We start with the end in mind. Start with the test. What would need to be tested so the programme would pass then write the code itself. It will fail in the beginning because the test cannot locate the function or the code it is meant to test. But then, you code and make the test code pass.

How does one get started in TDD?

Simple, start by writing your first test.

He then expands that it is about writing a test for the code that has not existed yet. Sometimes, you can use test framework. Sometimes, it can just be a shell script checking the expected result.

The goal is, instead of looking at the requirements and implementing a solution for it, TDD starts with thinking about how to test those requirements before writing a solution for it. That is the essence of TDD.

Then it becomes the feedback cycle, code coverage, and optimizing.

TDD at Facebook

Kent shares his first time joining Facebook. It was around the time of internal Hackathon. It is an event that covers many areas, including lectures. So, he decided that being the “great Kent Beck” master of TDD and Agile, people will want to learn testing from him.

The signup sheet turns up empty, while the other classes were full. That was a real shock to him. So, this got him thinking. Could this place just be a “clown show”, where people just do not know what they were doing. But then, he realised Facebook is using software to deliver value to people on a massive scale. They can’t be just a “clown show.”

So he pretended he knew nothing about software development and to see what Facebook would teach him.

It turned out there were already many feedback loops in place at Facebook, just not in the traditional sense of unit testing and frameworks. Because TDD, in a traditional sense, is not a cost effective way to get feedback. Facebook is doing things on a large-scale, many of which have not been attempted before. So, there is no way to know what the expectations would be. Instead, they get the feedback loop from monitoring and the ability to partially roll things in and out.

Fast feedback loop and TDD

The next question is in a start-up scene, where people must validate an idea quickly, so would TDD make sense?

Kent said it depends on latency or time to deploy. Sometimes, writing a test first may cause a delay in time to deploy because of the extra overhead. But sometimes, without writing a test first, the code might get too completed and take time to sorted out which caused delay in time to deploy.

Innovation comes from a cycle of learning. So do the thing that will shorten the learning cycle as much as possible. That is the chicken. Writing a test before or after or not at all — that is the finger.

About 5 years ago, before he joined Facebook, he worked on a PHP project. He cranked on a poker project, and he started with an interface. It was a simple HTML code, and he coded and ran it to see what it looks like — a fast feedback loop. Then he worked on the backend bit in PHP. Here, he used TDD, because in this case, many edge cases are very dangerous, and he may spend a lot of time trying to debug his way out if the code written without using TDD.

The key is latency.

Current Agile practices community

When asked about what he would change in the current Agile practices community, Kent Beck said he has attended no Agile conferences for a long time now — he was busy being Agile.

From the echoes he got from the people around him, he thinks people know the Agile practices, like Scrum and Kanban, well. But to go back and use his old metaphor. Those are the finger, not the chicken.

He encourages people to step back to think about what they are trying to do then step back in and do that. Focus on how to shorten the cycle. Kanban is the finger; the chicken is making sure people are not overworked and creating flow.

On Documentation

Should code be commented? Again, Kent Beck went back to his analogy. Commenting the code is the finger. There is always a trade-off. The biggest cost in software development is opportunity cost about the work not done. That’s why removing work is powerful.

In this sense, a balance is looked at. The chicken, again, is the feedback loop. How much time will be saved by commenting the code? If there is a large team working on a common piece of code, then commenting it saves time for other people that must be spent trying to understand the code. But, if this code is a “Prove of concept”, nobody will come in and read the code. So, the cost of comment creates no benefit.

Commenting the code is a means of communication. It can also be diagrams or a test or pair programming. It doesn’t matter what it is.

Also, if the comment is redundant, then he would remove it.

He touches a little on designing/refactoring the code so well that comment becomes redundant.

Trade-off is different on the individual level, even in pair programming, so he encourages people to experiment and see what would work best. Each team at Facebook works differently and should.

Conclusion

Kent beck covers various topics, such as pair programming, coaching, recommended books, and requirement estimation.

For me, this is a very interesting interview. Being in an Agile community for some time now, I have heard Kent Beck’s name many times. Today, I understand why he is so well respected in the community.

From how he lives to how he enters Facebook, how he views various practices in the software development community as a finger not the chicken, it is the means to an end, and the essence of software development is about improving the feedback loop, not the practice. It is also very context dependent.

-Pondd-