Translate

August 4, 2017

The "Eat your own dog-food" fallacy

Why having people eat their own dog-food doesn't accomplish anything sustainable.


Summarising

Having somebody eat their own dog-food doesn't necessarily make the improve its taste but might make them get used to the taste instead. Awareness of the (lack off) quality in one's work is important when transitioning from a Dev/Ops organisation towards a DevOps organisation. But experiencing a lack of quality first hand is often not the way to do so, or even an option. Agile transformations are only possible by means of cooperation.

There's a common understanding in the world of organisations that are transforming from Dev/Ops towards DevOps organisation that this works best when the devs are forced to eat their own dog-food. It's a reaction from the Ops people towards the Dev people.

Basically it means that once you've got the Devs supporting their own products, they'll make sure that those products are of a high quality. Common believe is that since they, those Devs, don't want to get called Sunday night at 3 AM because their software crashed. Which makes perfect sense, who does want to get called Sunday night at 3 AM because something they created crashed? I wouldn't, would you?

So, if you want those Devs to focus more on quality, on less crashing software, you have to make them support that same software themselves. In other words, turn those Devs into Ops people and that'll show them.

About a year ago, I joined a team at one of my customers to help them transform selected development teams into more agile teams utilising Continuous Delivery mechanics and move towards, lord forbid, DevOps. One of the slogans we used to get the necessary buy-in was:

"Eat Your Own Dog-Food"

And later we added "And Clean Your Own Shit!". Totally convinced that this is how it works. Make people feel the pain they're causing and they'll become better persons. If you would do a little time-travel and rewind about 2 years, you'll hear me saying that "one should feel the pain they're inflicting".

I think you'll recognise this when you've been in that situation where you want to move from Dev/Ops towards DevOps. Or become more agile. Or maybe you need to convince people that agile or DevOps is the way to go.

It makes total sense. People with kids know this. You want them to stay away from the fire, let them burn their fingers. Or those people with dogs shitting all over the place... let them clean that shit every time their dogs drop their poop in the playground. It works, really does.

But there's a huge problem in this, I'll get to that. First I want to ask you if you've noticed that slightly grumpy undertone in me mentioning of the "Eat your own dog-food" slogan and everything associated with it.

Agile and SCRUM in particular are developer driven ways of working. It's the developers that want to change things. Reason, obviously, is that developers want to develop software that people are using, so they want to get create something that is as close to what is usable as possible. Meaning that they want so put something in the hands of the user as quickly as possible and then make adjustments and put that into those same hands. And again. And again. And again.
Our organisations are such that specialised Ops people are managing those applications when in the hands of those users. And they need to keep up with all those adjustments... You understand the predicament those Ops people are in.
So when you tell these Ops people, that you want on your side while transforming into agile organisations that those Devs should eat their own dog-food. Ever tasted dog-food? So how do you think that this resonates with those Ops people? Pretty awesome, don't you think?
That connotation of dog-food is getting the nay-sayers called Ops on your hand, shouting "Yay" instead of "Nay". Mission accomplished. You're done.

Well forget it. That's the "Eat your own dog-food" fallacy. It's a fallacy because it doesn't solve anything and it certainly won't help you in your agile transformations. Considering your organisation has separate Dev and Ops teams, and considering that the reason for this is a more efficient Ops team because they will support many products. Because supporting a quality product is not a full-time job. Read my post on this topic. There's no way that having the Devs eat their own dog food will improve quality. Which was the premise in the first place, remember? And now you should say that in fact it doesn't make sense at all. Because there's an Ops team and for a good reason. So what makes you think that anybody in the organisation will just allow the Devs take over the Ops jobs? Ain't gonna happen. No way. Meaning that whatever you're trying, the Devs won't even get the opportunity to eat their own dog-food, even if they would want to. You can fix it by job-rotation... in certain situations, in certain organisations. Fallacy explained.

Considering the above, how would you need to address the agile transformation? How to move towards a DevOps setting? The answer is quite simple and probably extremely hard to implement. The more alluring the "eat your own dog-food" approach is, the harder it will be to do the correct thing. The sustainable approach, let's call it.

If you want the developers to develop software of a higher quality, you need to make them aware of the problems they are causing because of the lack of quality in the software. And you do this, by introducing them to their operations colleagues. Let them work closely together. Geographically close. As in side by side. Not pair programming close, but across the desk close.
What will happen is that the colleague from Ops will complain to his Dev colleague about a problem instead of to his Ops colleague. Feedback loop is tiny and closed. And most likely, it's friendly constructive feedback, because it's directed to the immediate colleague from across the desk. That person with whom lunch is shared. Not bottled up feedback. It becomes a feedback loop in which the Dev can immediately ask the Ops person why it's such a huge problem, this tiny thingy.
Getting the Dev and the Ops to work at the same desk, allows them to become aware of each other's work. And generates understanding. Understanding towards their respective worlds. It creates an atmosphere where the Dev will improve the quality of the product, because otherwise the Ops colleague is called Sunday morning 3 AM, and that's not something the Dev wants.

As a parting gift, another tip: Make sure that Devs and Ops don't huddle together when you put them in the same room. Instead put the Dev next to the Ops, side by side, hand in hand. When you allow them to huddle together, you should put them in separate rooms. Just to make sure that their respective complaining is not effecting them during work hours.
By allowing those to blood-types in your organisation to become aware of each other and befriend each other, you'll pave the way to become a true agile organisation with a smooth transition towards a DevOps mindset.

Here's an exercise for you: See how it works the other way around. Feel free to use the comments to discuss.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect