In this episode of Semaphore Uncut, we welcome Aslak Hellesøy, Cucumber Founder, Cucumber Open Source Lead at SmartBear. We walk about TDD and BDD, how to adopt automated testing, what different kinds of tests there are, and what the future holds for Cucumber.
What we talked about, in more detail:
- Introduction
- The differences between TDD and BDD
- How developer communities evolve
- What is Cucumber?
- How companies started adopting Cucumber
- TDD: patterns and anti-patterns
- How to adopt test automation
- Hexagonal architecture of BDD
- Why do we need different kinds of tests?
- The future of Cucumber
Listen to the full conversation or read the edited transcript.
You can also get Semaphore Uncut on Apple Podcasts, Spotify, Google Podcasts, Stitcher, and more.
Like this episode? Be sure to leave a ⭐️⭐️⭐️⭐️⭐️ review on the podcast player of your choice and share it with your friends.
Introduction
Darko Fabijan:
Hello, and welcome to Semaphore Uncut, a podcast for developers about building great products. Today I’m excited to welcome Aslak Hellesøy. Aslak, thank you so much for joining us. Please introduce yourself.
Aslak Hellesøy:
Hi Darko, thanks for having me!
I’m a programmer. I’ve been a programmer since the late 90s, so that’s over 20 years now. I’ve been programming in lots of different languages. Started with Java, then did Ruby for many years, and some .NET, and lately Go, JavaScript, TypeScript, and probably a few others.
I’ve been an open-source contributor. I started doing that quite early around 2003, when I released some tools in the Java space that nobody uses anymore, and then moved over to work on the RSpec project. Cucumber grew out of RSpec. I’ve been working on Cucumber since 2008, 2009, so that’s about 13 years.
I’m also an entrepreneur. I founded a company in 2013 or ’14 that we sold in 2019 to a company called SmartBear, and that’s where I’m currently working.
Darko Fabijan:
Great. Thanks. And our ways cross in a way that I was introduced with a team to TDD, BDD, Ruby, and all that through a Ruby community. It was one of the early adopters of TDD and BDD and was pretty religious about it.
Then Cucumber is one of the main building blocks of BDD. Can you please give us a short introduction to how you came up to create Cucumber and what your take on the BDD is?
Aslak Hellesøy (02:05):
I think we actually have to go nearly 20 years back in time to 2003. At the time, I was living in London and there was a community of extreme programming or XP practitioners who met up regularly. I was working in a company called ThoughtWorks at the time. And TDD being part of XP was something that everybody was very interested in.
One of my colleagues at the time, Dan North, was training a bunch of people in TDD. He realized that TDD was really hard for people to grasp. He ran into this frequent misunderstanding that people thought it was about testing, whereas the way he and many others thought of it is not really about testing, it’s just a development workflow.
So he came up with BDD as a variation of TDD to make it easier for people to understand the core values of TDD.
The differences between TDD and BDD
Aslak Hellesøy (03:02):
The main difference between TDD and BDD is that BDD has a stronger emphasis or collaboration between technical people and business stakeholders. So it’s kind of a tool to discover misunderstandings that happen very early on in the requirements phase.
The main difference between TDD and BDD is that BDD has a stronger emphasis or collaboration between technical people and business stakeholders
-Aslak Hellesøy, Founder of Cucumber.io
And the other thing is expressing the understanding of what the requirements are, not as unit tests, which is what you would do with traditional TDD, but rather as acceptance tests. So higher-level tests that are expressed in a way that the technical stakeholders can understand.
Aslak Hellesøy (03:38):
I just want to emphasize that both of these things – collaborating with the non-technical stakeholders and using acceptance tests – were actually emphasized originally by TDD. But it was sort of not regarded by the community as the most important thing. So BDD tries to take those two values as two of the most important aspects of the practice.
So around this time, JUnit was pretty mature already, and there was RSpec, NUnit, and lots of unit testing tools. But apart from FitNesse, there were no other tools for writing acceptance tests, using a syntax that can be read, and understood, and even written by non-technical people.
So that’s why I started Cucumber. I wanted to write these kinds of high-level, readable, acceptance tests that everybody could understand, so I needed a tool. It started out in RSpec, and there was later extracted into its separate tool.
How developer communities evolve
Darko Fabijan (05:07):
You spent a lot of time as part of these communities. Let’s say we can put them on their own single umbrella. What are maybe some changes that you have seen?
Because these things can have adoption cycles, which is very funny. In a way, there are different communities usually form along with the languages or frameworks, and then they evolve and then embrace various tools at different rates, and with a different level of engagement. So we cannot say it’s 20 years, but it’s also not too far away from that.
Have you seen any changes, any patterns in adoption how teams are embracing? They’re also a completely new generation of people. Every three to five years, there is a new generation of developers.
Aslak Hellesøy (06:04):
Yeah, definitely. So the first release of Cucumber came out in 2008… Or was it ‘9? I can’t even remember. And at that time, it was only Ruby.
It came out at a time that Ruby on Rails was quite new. So the first adopters of Cucumber and also BDD were Ruby on Rails developers. At the time, there were also some tools in the Java space, but primarily, all of the buzz around it came from the Ruby community.
Two or three years later when my friend, Matt Wynne and I had realized that Cucumber was kind of taking off, we decided to write a book about it. So when that book came out three years into Cucumber’s life, it made it more accessible to a whole new audience.
The people who picked it up then were testers. People who maybe traditionally had been doing a lot of manual testing were now adopting Cucumber as a way to automate their tests.
Aslak Hellesøy (07:03):
I think that’s when we see the first shift in paradigm, because, as I alluded to earlier, TDD and BDD aren’t about testing. It’s really a programmer-focused workflow, at least that’s the way we intended it to be, and I guess in many ways still intended to be.
But people have adopted Cucumber as an acceptance testing tool where they write the tests afterwards, rather than before they write the code. At the same time, people would start using Cucumber with browser automation tools like Selenium WebDriver, and Watir, and other things. It started out as being a tool where developers would use it, not necessarily to test through the UI, and almost overnight, it became a tool that was used by testers who would use a browser automation framework to test existing code.
TDD and BDD aren’t about testing. It’s a programmer-focused workflow.
-Aslak Hellesøy, Cucumber Founder
Aslak Hellesøy (07:53):
So that happened around 2012 or something like that. I would say it hasn’t really changed much in the decade that followed after that. But 2022 and the majority of Cucumber users are still using it as a test-after tool with a browser automation tool.
We’ve tried to educate our users and the community about other ways and more efficient ways to use it. But I think we’ve failed in that regard, even if we’ve been standing on the rooftops, shouting it really loud.
There’s just so much, I would almost call it, misinformation out there about using it as a testing tool that that is what most people are using it as.
What is Cucumber?
Darko Fabijan (08:35):
Just a couple of months ago, I was speaking with one of our prospects. They said, “Okay, we are really struggling with connecting our UX teams and business people or developers. We are separated by silos and separated by brick walls. We have found this great tool, Cucumber. I’m really happy about that.” Look, it’s been around for a decade.
Aslak Hellesøy (09:02):
Well, it’s a funny thing because Cucumber is a decent testing tool, but it’s just that. It’s a tool that, if you use it right, you can get so much more value from it.
So I don’t really mind when people use it with the web driver and just drive UIs with it. I just feel a bit sorry if they haven’t discovered the BDD way of using it.
But you can only really do that if you are in control over the whole stack, which is difficult when you’re working in a silo, either as a front-end developer who doesn’t touch the backend or as a tester who just doesn’t touch anything, just tests the front product.
How companies started adopting Cucumber
Darko Fabijan (09:35):
I was interested to hear about your efforts to try to teach people, and to sway the whole community in that direction, and what are some of the experiences and how it looked.
Aslak Hellesøy (09:49):
When I started Cucumber Limited with some of the contributors, one of the ways that we made money was to do trainings for companies. So a company would come to us and say, “We want to adopt. We’ve heard about all the benefits of BDD and Cucumber. We want to adopt it. Can you help us?”
So we would run a three-day training course with them, and teach them how we think it ought to be used. And then occasionally, we would also get coaching engagements where we would come back and spend some time with them after the training and just help them as they were learning and putting into practice what they learned in the training.
So I guess that’s probably the most significant effort that I and my colleagues have done. We’ve also written blog posts, and we’ve had podcasts, and Twitterstorms, and so on. But there’s only so much you can do to educate when there is so much more additional information out there that says something different.
Aslak Hellesøy (10:54):
Lately, there’s a new book series called the BDD Books, written by Seb Rose and Gaspar Nagy, that teach you the three main practices of BDD as we’ve come to understand them, which is Discovery, which is a completely non-technical thing. It’s just, “How do you have efficient communication between the development team and the non-technical stakeholders?”
And the second one is Formulation, “How do you capture and write down in Gherkin documents in a good way?” This understanding from the Discovery, and then finally Automation, “What are some good techniques you can use to automate this stuff?”
So two of these books have come up, Discovery and Formulation, and the Automation book is in the works. Those three books are capturing, I would say, all of the knowledge that we’ve sort of built and evolved as a community over the past decade. So for anybody who really wants to learn BDD, I would recommend those three books, bddbooks.com.
TDD: patterns and anti-patterns
Darko Fabijan (11:57):
That’s a great resource. We’ll make sure to include it in the notes. In the beginning, there was RSpec book and the Cucumber book. If you are a Ruby developer, those are like Bibles, and you started from there, and you had to go…
I remember for me, and also some of the colleagues, it was a bit of a struggle that you are embracing the practice of TDD and BDD at the same time, which are on different levels. It’s not trivial because, to the best of my knowledge, still the majority of the universities in computer science courses are taking, generally, design and testing overall as some afterthought. It’s not the first-class citizen on the courses.
With your experience of teaching teams and helping them embrace BDD and Cucumber, do you also have connecting points with TDD in those companies as a design tool? What are some patterns and anti-patterns that you have seen? What’s hard for people to grasp, what do they usually miss?
Aslak Hellesøy (13:01):
One thing that’s hard to grasp is the same thing that was hard to grasp for the people that Dan North was training when he came up with BDD, which is realizing that BDD and TDD are not about testing existing code, it’s about designing a code that hasn’t yet been written.
BDD and TDD are not about testing existing code. They are about designing a code that hasn’t yet been written.
-Aslak Hellesøy, Founder of Cucumber.io
That is really hard for a lot of people to grasp, especially non-developers because you have to be a developer or a programmer to understand those concepts.
So when we were teaching people, we would teach everything from product owners and business analysts to manual testers, to developers. But quite often in enterprise organizations where you have silos, there can be barriers in the organizational structure that make it really hard.
Even if you understand BDD, you’d have to put it in place because you need to tear down some of those walls that prevent people from collaborating efficiently.
Aslak Hellesøy (13:54):
Another anti-pattern I’m often seeing is when a team or an organization realizes that all of the manual tests that they currently rely on are too slow, and too inefficient, preventing them from delivering continuously. They want to basically translate all of the manual tests into automated tests, and they have these long manual tests, and they’re starting this journey to automate them.
That can become a real struggle because you’re dealing with a system that wasn’t really designed for test automation. One of the common problems is that you can’t easily put the system in the state that you wanted to be in order to run those assertions that you want, simply because it’s just a black box.
How to adopt test automation
Aslak Hellesøy (14:40):
So what I usually recommend to those teams is that it’s good that you want to adopt test automation, but do it very incrementally. Only do it when you’re adding a new feature to the system, for example. Do test automation for that new thing, but don’t worry too much about the old stuff. You can still use your manual testing effort for that.
It’s good to adopt automated testing but do it very incrementally.
-Aslak Hellesøy, Founder of Cucumber.io
And the other thing is, if you have tests that never fail, there’s no point in automating those. You should focus on the ones that tend to fail often, or the ones that verify very critical behavior in your system.
So there are a lot of techniques you can use to filter out from those 10,000 manual tests you have, and maybe filter it down to 50, and focus on those. Every time you modify something, write an automated test. So you have to adopt this stuff incrementally, you can’t have a big bang translation effort.
Every time you modify something, write an automated test.
-Aslak Hellesøy, Founder of Cucumber.io
Darko Fabijan (16:12):
I remember some more experienced colleagues saying to me about the piece of code that I wrote, “Okay, code looks decent, but how we’re going to test it?” It involved connecting to some payment gateways, and APIs, and all of that, and that cannot be easily tested.
So that’s one of the moments when I realized, “Okay, I now start to get why BDD and TDD are also design tools, and you design software through them because you must enable yourself to test the things that you wrote”.
Aslak Hellesøy (16:45):
There’s one question that every tester and developer needs to ask themselves when they design a test, and that is, “What kind of confidence do I want to get from this test? Do I want to get confidence that the business logic is working correctly?” That’s one kind of confidence.
“Or do I want to get confidence that it works on this particular platform? Does it work in this particular browser? Does it work on this particular phone?” Well, that’s different confidence.
The third kind of confidence is, “Does it interface correctly with these external systems?”
You can come up with different kinds of confidence categories, performance, business logic, interacting with external systems, but if you’re trying to get confidence that all of these things are working in the same test, that’s not going to work. You have to design tests specifically for a particular kind of confidence.
You have to design tests specifically for a particular kind of confidence.
-Aslak Hellesøy, Founder of Cucumber
Aslak Hellesøy (17:42):
So we need a lot of confidence from our systems. We need to make sure that they work on different platforms. We need to make sure that the business logic is implemented correctly. We need to make sure that interaction with external systems is working well.
You can’t get all of that confidence from the same tests. You need different tests to test on platforms. You need different tests to test business logic. You need different tests to test interaction with external systems.
That’s one mistake that a lot of people are making, they try to fit it all into the same test. So when I do BDD, I tend to focus on the business logic aspect. I want to make sure that the business logic is correct, that’s really where BDD shines.
Aslak Hellesøy (18:23):
It’s not a great way to verify that you’ve integrated properly with a payment gateway. It’s not a great way to verify that this system works on all these different operating systems, or browsers, or mobile phones or whatever. You can use other kinds of tests for that.
So if we accept then that BDD is great for making sure you have implemented the business logic correctly, that means you need to be able to decouple all of the external factors that can pollute your result, for example, a payment gateway or something that can slow it.
So anything that’s slow or unreliable, you want to decouple that when you run your tests because it’s important that your tests are really fast, and it’s important that they all produce the same result.
Hexagonal architecture of BDD
Aslak Hellesøy (19:10):
So the technique that I use, and many other people in the BDD community use, is something called ports and adapters, or hexagonal architecture. You put an interface. It’s probably easier to explain this with a statically typed language, like Java.
So rather than your business logic invoking, calling out to some sort of payment API directly, you define an interface that encapsulates, that sits in front of that payment gateway, and then you can have one implementation that actually talks to the payment gateway and another one which doesn’t do anything. Maybe it hasn’t prerecorded results or something like a stub.
And then you can still test your business logic and verify that it behaves correctly without connecting the real payment gateway. And then you have another test that will verify that your payment gateway interaction code is working correctly, but that would be a unit test that you run as an integration test. So we need all these different kinds of tests. We can’t do everything with the same tests.
Why do we need different kinds of tests?
Darko Fabijan (20:11):
Very well explained, very valuable. But you’ve probably seen that, as you mentioned the Rails community, it’s so easy to couple that verifying the business logic is okay with the actual implementation of the platform, which is usually web and some web interface in the middle. I’m guilty of doing that many, many times throughout my career.
What I’m seeing these days with customers, there is that very expensive test suite that ends up being maintained, which is testing things all the way. A small change, a small feature added is actually testing almost the whole browser, the whole JavaScript test, all the way down to the database with various networking calls all the way back, being very fragile, very expensive to run over and over.
I’m seeing a lot of teams struggling with that testing pyramid and how they maintain it. Different people in teams employ different kinds of iterations, and try to heal that, or just steer it in the right direction. Any tips or advice that you can give in that area?
Aslak Hellesøy (21:28):
You do need some of those tests. You do need some of the tests that go through the entire stack, those are your smoke tests. Those are the tests that verify that everything is working together.
Those are the tests that try to give you all the kinds of confidence, confidence that your database is fine, that your external APIs are fine, that it works in this particular browser and your business logic. It’s good to have a few of those.
But for a medium-sized system, typically I wouldn’t have more than maybe a dozen of those. Maybe each one of those tests run in five to 10 seconds, and you can run them in CI, you don’t need to run them on your workstation every time.
But then there’s everything in between. I think that’s where you should be using unit tests.
Testing as car manufacturing
Aslak Hellesøy (22:10):
Think of the hardware manufacturing industry or even car manufacturing. When something comes off the conveyor belt as a finished product, when you’re making a new car… I don’t know how they test cars, but they probably drive it around the block just to see if it kind of works.
But there’s been so much testing going into the individual components before that, everything from the software inside the car to every different physical component that they’re tested in isolation.
But the reason why that testing doesn’t require another very thorough, full-stack testing afterward is that they have some well-defined interfaces. They have some well-defined interfaces between the various components so that when you put them together, you don’t need to do thorough testing.
This, again, is related to ports and adapters. When you’re designing an application according to ports and adapters, you are defining what those interfaces are, and you can test the components at their interface, and you don’t really need to worry so much about testing it again when you bundle it together.
Mixing concerns in the same code
Aslak Hellesøy (23:12):
I do think that statically-typed languages help a lot in this regard because you can have the compiler verifying that you are respecting the interface or the contract between components.
But with dynamically-typed languages, there is no compiler that will tell you if you’re calling a method that wants three arguments with two arguments. You’re not going to know that at compile time because there is no compile time. So with languages like Ruby, unfortunately, you do need to rely more on those tests that test a whole assembly.
And then there’s also the thing about what you mentioned, you’re guilty, and I think everybody who’s built a Rails application is a bit guilty of mixing concerns in the same code.
For example, putting the business logic in your active record models makes it really hard to test that business logic without a database, which makes the whole thing really slow and so on.
But that’s just the way Rails is designed. That’s the price you’re paying for the ridiculously rapid development experience you get, at least at the beginning of the project.
Applying a more functional programming paradigm
Darko Fabijan (24:09):
Yeah, yeah. Exactly. I’m mostly speaking with people who have 10-year-old Rails apps. Those rapid things, in the beginning, are biting back pretty aggressively 10 years later.
Aslak Hellesøy (24:26):
But you can still do it. I mean, I’m working mostly in Typescript at the moment, and we are using a framework called Next.js, which is, I guess… It’s not quite Rails, but it’s a full-stack web framework. You can easily end up with the same kind of title-coupled code out there that you can only test with an acceptance test.
But what I’ve started doing is to adopt a more functional programming paradigm where I extract lots of small functions, and I unit test those functions in isolation. You can do the same thing with Ruby.
Aslak Hellesøy (25:01):
You have a lot of business logic in your model, well, just extracted to… What is it called? A PORO, Plain Old Ruby Object. And then you can test that in a unit test without Rails. But you have to be aware of these problems.
I think a lot of people don’t think about abstractions and decoupling and haven’t really experienced the pain. By the time you experience the pain, it feels like so much effort to try to undo that. But you can do these things incrementally.
My rule of thumb is that when I’m working on the legacy system, I only improve the things that I’m working on. So I’ve got to implement a new feature here and it’s a big hairball, fine, okay, I’ll spend a bit of time extracting that so that I can TDD on that little quarter of the code, and then things are a little bit better, and I’m a little bit happier.
My rule of thumb is that when I’m working on the legacy system, I only improve the things that I’m working on
-Aslak Hellesøy, Cucumber Founder
How to decide what to improve in the system
Darko Fabijan (25:46):
Working as a consultant, and then as you are entering a big and old project, it really forces you. You have a lot of limitations that you must have a focus point, “What are you trying to improve?”
I remember that helping me a lot because I cannot go ballistic on various parts of the system, and, “Oh, I’m going to improve everything,” knowing you are not.
You’re tasked with improving this one component. And that kind of discipline, which is dictated by external factors, was a pretty fruitful thing for me.
Aslak Hellesøy (26:17):
Your opinion of what is good and bad is probably similar to my opinion of what’s good and bad, although we probably have some differences, and everybody has a different opinion on what’s good and bad.
Another practice that I think is really important in order to have a nicely testable code base with fast and reliable tests and so on is to have shared code ownership. If I go in and change a bunch of stuff, that’s not really going to fly, unless everybody else in the team agrees with my approach. It has to be the team’s approach.
Aslak Hellesøy (26:51):
So in my experience, if you want to do BDD and TDD, you kind of have to mix it with practices like, at least, occasional pair programming or mob programming to build that shared ownership of the code, because it means introducing obstructions that you wouldn’t otherwise have introduced like decoupling.
Everybody needs to understand and see the benefits, otherwise, they’re just going to throw their arms up in the air and go, “Why did you do all of this stuff? We can do it much simpler.” Yes, but it’s so that we can have a better test suite and work faster.
Darko Fabijan (27:23):
Yeah. It’s about investment. It’ll pay in the long term. What you’ll pay off in the short term versus long term are usually somewhat competing in a post.
Aslak Hellesøy (27:33):
Yeah.
The future of Cucumber
Darko Fabijan (27:34):
Well, great. Many war stories that we have here with TDD and BDD, and embracing them. For Cucumber, you mentioned that there is a team working on it. What are some of the things that are currently ongoing with Cucumber for the future?
Aslak Hellesøy (27:53):
Oh. Yeah, loads of things. So since we were acquired by SmartBear, there’s a small team that’s paid to maintain Cucumber, or Cucumber Open as we’ve now officially named it. So that’s Matt Wynne, or Aurélien Reeves, and myself.
But there is also a team of maybe six, seven, eight regular contributors outside of the company. We meet up every Thursday at 3:00 UK time. We have about an hour meeting where we just sync up, it’s like a long standup meeting, where we talk about what we’ve done and what we’re going to do and various stuff.
There are now many implementations of Cucumber. Originally, it was Ruby, but there’s Java implementation. There is a Javascript/TypeScript implementation. There’s a Go implementation. We’re maintaining all of those.
There’s also the C# and .NET implementation, which is maintained by Tricentis, but we collaborate closely with them.
Aslak Hellesøy (28:54):
So we meet up regularly, and one of the things that have been the main focus over the past few years is to consolidate the implementation so that they have the same feature set, follow the same design, making it easier to maintain everything because they’re more similar, because in the beginning they evolved and diverged quite a bit.
Gherkin parser and Cucumber expressions
So now we’re at a place where things are pretty compatible. Cucumber is built up of several smaller libraries. There’s a Gherkin parser. We share the same test suite for all of the implementations in Java, Ruby, .NET, and so on. We have something called Cucumber Expressions, which is an alternative to regular expressions with the possibility to extend them. We have tag expressions for filtering out scenarios.
It’s a little building expression language and a few other smaller libraries. So the approach we’re taking is, we store them in the same repository. They share an acceptance test suite, and we try to implement them more or less consistently using the same method, names, and class names, and so on. That’s worked out really, really well.
Aslak Hellesøy (29:59):
One of the things that Matt has been focusing on in the past few months is to grow the contributor community because Cucumber is used by, I don’t know, hundreds of thousands of people, maybe over 1 million. And as you can imagine with an open-source project that’s that popular, there’s quite a lot of work to do.
Even though we are a full-time team of two, three people plus regular contributors, we’re about 10 people, that’s not enough. So we need to grow the community. Math and Aurélien, they’ve been working on trying to recruit new contributors, helping people who have never contributed to open source before, and showing them how to get involved, is actually streaming on Twitch every Friday.
That’s been working really well. We’ve also improved the developer documentation so it’s easier to get onboarded, figure out where to start, and so on. So I think that work is really important.
Code completion in Cucumber
Aslak Hellesøy (30:52):
One big project that we have now is to build better support for IDEs and editors. When you’re working with feature files, you want to have the same excellent support that you get when you’re working with Java, or Ruby, or Go, or whatever, which means really good syntax highlighting. Code completion is very important because you might have a library of hundreds of step definitions.
So we’re building something called the language server, which is the technology pioneered by Microsoft and Visual Studio code. It basically lets you write an editor plugin that can be used in many different editors. So you don’t have to write a plugin for every single editor, you just write one. And then that will work with all editors that support the LSP, the language server protocol.
Aslak Hellesøy (31:36):
That’s something that we’ve been working on in the past year, and hopefully, that will be released in the next few months. We hope that’s going to make it just more pleasant for people to work with Cucumber.
We’ve also got an online reporting service where you can publish reports straight from Cucumber to a website. That’s one of the commercial products that we’re working on inside of SmartBear.
Darko Fabijan (31:58):
It’s great to hear that Twitch, and these things that were not around in the early 2000s when these products were started and generally the open-source, are great. I can relate to maybe young people who are now embarking on a journey, want to contribute to open source.
If I would have a chance 10, 15 years earlier to watch someone on Twitch how they do things… I mean, that’s a huge thing. It’s not easy to get access to someone’s knowledgeable workstation and look how they’re dealing with big and small challenges as they’re developing. Yeah, sounds great.
Cucumber Slack channel
Aslak Hellesøy (32:36):
We’re a 13-year-old open-source project and we’ve gone through several different communication channels. We had a Google group mailing list that went on for quite a long time. And then the activity on that just became less and less because we’ve turned on a Slack channel.
So now we have a Slack channel with 10,000 or nearly 15,000 members that have completely eclipsed the Google mailing list. We’ve actually disabled the mailing list now. And then we see new things like video streaming becoming more and more important. People want instant gratification now. They don’t have the attention span to read a mailing list or write an email. It has to be instant gratification in video or Twitter messages.
Darko Fabijan (33:21):
There is a component of that. There is, I think, also a component just being with other people, in some format, which with Slack, I don’t know the instant nature of it scares me in terms of connecting with open source project. But I know that many, many communities do use Slack for their communication. I guess there are some challenges.
Aslak Hellesøy (33:41):
The main challenge with Slack is that it’s not easily searchable and it also doesn’t keep history forever, at least not on the plan we’re on. It’s not a great collective memory of what has been said. Mailing lists are better for that, but they’re dated.
So I’m not 100% happy with Slack. It works pretty well, but sometimes, I want to go back to this old conversation, I can’t find it, or something important is said and it’s just scrolled past and you miss it. So it’s more like face-to-face communication.
Darko Fabijan (34:14):
Exactly. Anyone listening wants to join, here is an open-source project which is interesting, has been around for more than a decade, and will be around for decades to come.
Aslak, thank you so much for joining and sharing the history and the future of Cucumber and all about BDD that we talked about also. Good luck with the project.
Aslak Hellesøy (34:36):
Thank you. It was a pleasure, Darko. Take care.
