A few months ago, Ippon started a book club. Each month, we choose a book (or a section of a book), we read it, and then we meet up, get some food and drinks, and discuss the book with each other. The first few book clubs were for employees only, but we quickly opened this book club up to non-employees who may be interested. Since then, we have created events through Meetup (an example: Ippon Book Club) and had a few people from outside of Ippon participate. So far, we have read The Pragmatic Programmer, Clean Code, Docker for Java Developers, and more. Each meeting has different people bringing different perspectives and a chance for all to learn. The Pragmatic Programmer, one of our first choices, was broken up into chunks. Chapter 1, Section 3, entitled Stone Soup and Boiled Frogs, has been particularly useful and is in fact the reason for this article. If you are familiar with the book, you may already be familiar with this section, and you may have used it in your career. However, in case you are new to the story, here it is (a variant of the one presented in The Pragmatic Programmer, Stone Soup):
“Some travelers come to a village, carrying nothing more than an empty cooking pot. Upon their arrival, the villagers are unwilling to share any of their food stores with the hungry travelers. Then the travelers go to a stream and fill the pot with water, drop a large stone in it, and place it over a fire. One of the villagers becomes curious and asks what they are doing. The travelers answer that they are making "stone soup," which tastes wonderful, although it still needs a little bit of garnish to improve the flavor, which they are missing. The villager does not mind parting with a few carrots to help them out, so that gets added to the soup. Another villager walks by, inquiring about the pot, and the travelers again mention their stone soup which has not reached its full potential yet. The villager hands them a little bit of seasoning to help them out. More and more villagers walk by, each adding another ingredient. Finally, the stone (being inedible) is removed from the pot, and a delicious and nourishing pot of soup is enjoyed by all. Although the travelers have thus tricked the villagers into sharing their food with them, they have successfully transformed it into a tasty and nutritious meal which they share with the donors.”
How does this relate to Software Engineering? And more specifically, to the life of a consultant? The story actually relates to more than just this; it relates to anything that changes. As a consultant, we are often hired to help enact change, and as we will discuss, this story turns out to be very useful. While in the story, the resources being provided by others are actual ingredients to a soup. In the context of software engineering, the resources are people (and their mental resources). Instead of providing us with physical ingredients, they help us by communicating domain knowledge and technical solutions to problems, which can be considered mental ingredients.
We can immediately see the use in this method -- convince people to help of their own volition, rather than by force. In the variation used in The Pragmatic Programmer, the travelers are actually soldiers, so you may say “the soldiers could have forced the villagers to help.” Of course this is true, and they would have eaten well (as the villagers had the resources for a soup), but what happens when they force the villagers to help? By using force, the soldiers put themselves at risk, as they will pose a threat to the villagers who may look to protect themselves.
Similarly, many times consultants are hired by business leaders with decision making power, so they can of course push the changes through, but at what cost? Let’s say a consultant pushes and shoves people to get their way and bring about change. They will surely meet resistance. They may be successful in enacting the change, thus, job done, but the results may not be as desired. In the worst case they may push the wrong person, leading the client to rethink the business relationship.
In other scenarios, we still alienate valuable resources. Suppose the blunt approach causes job dissatisfaction among the employees? If they leave, the result of us moving in and helping will actually hurt our client. Another negative side effect is evident when you consider the time it takes to make a change. If we anger the employees before the change is fully realized, we may lose access to the employees, thus making the changes even more difficult. The main challenge of this difficulty will likely be caused by lack of access to the domain knowledge that the employees can provide us with. We have simultaneously introduced possible problems for the client and problems with completing our own task. Using the concepts from the story, we can do better, right?
Of course! Let’s imagine a situation where we are hired to help upgrade a technology stack. Let’s also suppose that not all of the employees are interested in this stack change (or just that they are unfamiliar with it). How can we spend our time so that the client adopts this new stack? As the domain knowledge will likely be important, it’s useful to get familiar with the existing stack. Some of our time will be spent working on stories related to the older technologies, but also to begin to create a second project, which uses the new stack. We want to design this new project in a way which causes the two projects to be independent of each other (i.e. changes to one will not break the other, and vice versa).
We are beginning to introduce our change in a non-intrusive way -- people can work effectively with both stacks. This is our start, our so called stone soup. We’ve created something small which doesn’t do too much, but it allows our clients to have an easy environment for exploring the new tech stack (if they want to).
Since our clients are still a little leery of the change, we want to improve our stone soup just a little bit. We do this by starting to implement some of the domain logic from the old tech stack in our new project.
Before we started this process, the employees had the opportunity to play around with the new tech stack, but they still felt a burden in using the new project. Not only do they have to learn the new technology, they also have to recreate a lot of stuff they’ve already done with the old tech stack. So we build out our new project slightly more and we improve our stone soup. Already, the client is unknowingly providing ingredients for our soup -- they’ve provided domain knowledge as our next ingredient.
Now that we have a new project, which uses the new tech stack and replicates existing functionality, the switch from the old stack to the new is less complicated. Other developers can more easily learn the new stack by looking at how existing problems were solved with the new tool set. More ingredients are added in the ability of others to grow the new project.
You may run into other things as well. Perhaps the new stack makes things simpler, or it provides performance benefits. These are things that make our soup taste better, and the employees will be more likely to adopt the new tech stack.
And so we have our completed soup, and hopefully both sides can benefit from this. In this example, we switched stacks, but this isn’t the only application of the stone soup method. New products can be created by starting with something small that does a portion of the work, and others can help grow it in the future.
Sometimes the business may need to calculate and plan everything, which can turn a potentially simple and quick product into something that is complicated and time consuming. It is very likely that getting time for the base of the product may be easier, so instead of planning everything up front, we only focus on the main purpose. Develop that, then show it off. Hopefully others will like it and look to contribute to the product and so, over time, we end up with the product we envisioned from the start.
It may appear to be a deceptive practice since the villagers are being “tricked” into doing something. This is where the result becomes important -- we need the final result to lead to some benefit for the villagers. We want them to enjoy in the final product, to get a taste of our soup.
We also should not take the soup directly after getting the help from the villagers, otherwise we could ruin the relationship we built while cooking the soup. Similarly, when consulting, you do not want to damage a relationship with a current and potentially future client. The relationship that seems to deceive one party, ends up being beneficial to both. Our client ends with a product or some change in an existing product which helps them, and the consultant forms a business relationship, which may lead to more work in the future. Using the stone soup method, we can effectively combat a problem that exists all around us: resistance to change. People tend to naturally resist change (although in the technology field people may be more open to change), but change happens. Using this approach, we lead by example. We introduce change in a comforting manner. Gradually let people come to change of their own volition, and the result will generally end well.
Our book club plans to continue, and in fact, earlier I linked a Meetup event for our next book where we will be reading The Phoenix Project. Feel free to RSVP, and come join us for food, drinks, and good times where everyone can learn and grow.
