Vitaly Sharovatov

Posted on Dec 7, 2022 • Originally published at qase.io

Designing a team that would produce software of good quality: set up dogfooding

Many successful companies employ Dogfooding practice:

Eating your own dog food or "dogfooding" is the practice of using one's own products or services.

In 1980 Apple wanted to dominate the computer market. To achieve that, among other measures they introduced dogfooding:

"EFFECTIVE IMMEDIATELY!! NO MORE TYPEWRITERS ARE TO BE PURCHASED, LEASED, etc., etc. Apple is an innovative company. We must believe and lead in all areas. If word processing is so neat, then let's all use it! Goal: by 1-1-81, NO typewriters at Apple... We believe the typewriter is obsolete. Let's prove it inside before we try and convince our customers."

Michael Scott and Steve Jobs wanted all their employees to become the first users of Apple products: the dogfooding practice emerged.

Any practice or process activity should have a rational reason.

This article explores the rationality of Dogfooding practice. The way how problems are generally solved needs to be reviewed first.

Solving problems

A customer comes to the shop at 11 am and purchases a burger.

A customer then comes to the shop at 8 pm and cannot purchase a burger as the shop is closed.

Is there a problem?

Did the customer stay hungry?
Did the shop lose money?
Both?

How can the shop solve the problem?

What does it even take to solve a problem?

Wikipedia says:

Problem solving is the process of achieving a goal by overcoming obstacles

The mathematical representation of this thesis would be: y=f(x)

Where:

y is the goal,
x is the context containing chosen obstacles/constraints,
f is the solution: the way we operate with the context to achieve the goal.

All the variables in the equation need to be defined:

constraints need to be chosen
goal has to be picked
a way to operate within these constraints to achieve the chosen goal should be found

NB: Those familiar with BPM will notice interesting similarities:

Picking the goal is very similar to describing a to-be model
Choosing x the context looks like building an as-is model
Designing f process is the main area studied: the synthesis of a transition from one state to another.

Choosing the constraints

The context always contains an infinite amount of constraints. The practicality requires picking those that are important.

x transforms into a set of variables: x = {x1, x2, x3, ... xn }.

Choosing the essential constraints demands a good knowledge of the current state of affairs.

For example:

x1 should be the information source: how do we know of the problem and how many customers are affected
x2 might be shop economics: how profitable it is, how much money can be invested
x3 can be laws and regulations: from labour law to licensing
x4 may be shop position in the market: how good its reputation is, how well known it is

Ignoring (or not knowing) some of the constraints might make achieving a particular goal not possible or optimal, e.g.:

If x1 is a guess, then any investment in solving the problem is high-risk,
If x3 is ignored, and the 24 hour license cannot be obtained, changing the schedule might not be an option,
If x4 is ignored, and there’s a McDonald’s opening at a stone’s throw soon; achieving certain goals might not be optimal.

Picking the goal

Picking the goal is deciding what the new system should be like.

Most managers call this their ‘vision’: a guesswork or intuition (so-called implicit knowledge).

Coming up with a goal is pure synthesis.

There are even methods designed to help with goals’ synthesis, e.g., TRIZ.

Different goals might be chosen for the shop example:

y1 — clients don’t come at night
y2 — clients are served 24/7
y3 — clients cook at home when the shop is closed

Defining the transition for each goal

Goal y1 — Clients don’t come at night

What are the ways to achieve this goal within the chosen constraints?

The simplest way would be to inform the clients of opening times, f1.

y1 = f1 (x1, x2, x3, x4)

This might reduce clients’ frustration (affect x4) as they won’t try visiting the shop at night.

The transition will not require any changes to the way the shop operates ( x2 and x3 won’t change). Most likely additional revenue will not be generated.

Goal y2 — Clients are served 24/7

What are the ways to achieve this goal within the chosen constraints?

One way would be to start working 24/7, f2.

y2 = f2 (x1, x2, x3, x4)

This will require quite a significant change to the way shop operates, and x2 and x3 constraints should allow these changes, while x4 may influence generating more revenue:

laws should allow purchasing 24/7 license, and its price should be affordable,
hiring more staff is required to introduce night shifts,
shop reputation and marketing expenses need to attract enough clients at night.

Goal y3 — Clients cook at home when the shop is closed

What are the ways to achieve this goal within the chosen constraints?

One way would be to start selling ingredients for clients to cook their favorite recipes at home, f3.

y3 = f3 (x1, x2, x3, x4)

This way will require an insignificant change to the way the shop operates. x2 might afford this easier than in f2 case. This transition might also positively affect the shop’s reputation x4 and generate more revenue x2.

Comparing the solutions

The solution to the problem is the goal and the transition.

Some goals might be picturing a brighter future than others, while the corresponding transitions might be riskier or more expensive. Some goals might be modest, while the corresponding transitions are cheap and low-risk.

A solution should be weighed with the constraints.

Naturally x2 (the economics) constraint’ weight is taken into consideration, but in most cases, people tend to turn almost a blind eye on x1:

x1 should be the information source: how do we know of the problem, and how many customers are affected?

What are the possible ways to see the problem or find out about it?

Lean manufacturing has the practice of Gemba walks, where management comes to the production facility and works in the process:

if you want to improve your business, you need to learn more about your processes, your people, your customers, you need to go and see for yourself.

Managers and business leaders today are often so separated from the actual work by corporate structures. They have not seen the process. They have not spoken to any customers. And they don’t even talk to the people who do the work daily.

Everyone, from CEO downwards, has the responsibility to spend time on the shop floor watching how to produce the product or service

Gemba pays special attention to the production process inside the company.

Gemba doesn’t help much with providing context on what’s beyond the walls. Gemba suggests the employees talk to the customers, yielding just one link in the information flow chain.

There’s an inherent information loss in every act of communication, and the fewer links in the information flow chain, the better.

It’s also possible to have zero links in the information flow chain: the employees might become the customers themselves. The dogfooding practice emerges.

Dogfooding

Dogfooding in the shop example context discussed above would potentially imply:

an engineer living in that particular area where the most shop customer reside
an engineer becoming one of many customers of the shop, following their usual shopping and behavioural patterns.

The engineer becomes an average customer, knowing all the peculiarities and fully understanding the customer’s context.

It is much easier to organise dogfooding in software development. As soon as the engineer becomes the first customer of the product or service, they begin to see the domain area's problems. The engineer becomes the trustworthy source of x1.

Good examples of companies implementing dogfooding practices are 37signals, Apple, Microsoft, and Gitlab.

Gitlab states dogfooding as the company value:

We use our own product. Our development organization uses GitLab.com to manage the DevOps lifecycle of GitLab itself.

Our entire company uses GitLab to collaborate on this handbook. We also capture other content and processes in Git repos and manage them with GitLab.

When something breaks, doesn't work well, or needs improvement, we are more likely to notice it internally and address it before it impacts our larger community.

37signals went even further, they build products for themselves first:

we built Basecamp out of desperate necessity. We needed it bad. Without it, we were embarrassing ourselves.

Dogfooding significantly reduces the information loss in defining x1 constraint, building the base for problem solving. When the presupposition of x1 constraint is wrong, any investment in problem solving is high-risk.

Engineering is problem-solving:

Engineering is all about solving problems using math, science, and technical knowledge. Engineers have solved a lot of problems in the world by designing and building various technologies. We have everything from machines that can breathe for you in hospitals to suspension bridges to cross rivers to computers we use every day. All of these things were once designed by engineers using the engineering design process.

Solution quality depends on the synthesis of the optimal goal and transition based on the chosen constraints.

Dogfooding culture helps reduce information loss in choosing the most important constraints.

Additionally, the dogfooding practice reduces ‘work alienation’.

This study discovers the seriousness of the work alienation problem:

work alienation is defined as a disengaged, negative and even painful outlook on one's job, or simply as “estrangement or disconnect from work”. Unsurprisingly, this state is empirically linked with poor performance, low commitment, career dissatisfaction, substance abuse and turnover intentions, and should therefore be avoided at any cost.

NB: Negative effects of high turnover are covered here.

Another study suggests that if the employee identifies with the role, they are not alienated:

We believe that people who are extensively committed to work not only identify with the work role, they are also engaged in the world of work

Dogfooding reduces alienation of work as the engineer sees and feels how their efforts resolve real problems, the daily problems they witness.

Dogfooding limits of applicability

Any practice has limits of applicability: conditions where the practice is suboptimal or even negatively affects the system.

Public tender contracts often disallow dogfooding; extensive requirements specification is provided instead.

Certain domain areas make dogfooding almost impossible or very expensive to practice, e.g.,

airplanes are not operated by engineers who design and build them
doctors use medical equipment on patients

Management needs to check if the dogfooding practice is viable to adapt.

How to start

If you decide that dogfooding practice might benefit your company processes and culture, there are two approaches: ‘revolution’ and ‘evolution’.

Apple used the ‘revolution’ approach in 1981: managers replaced the typewriters in the office with Apple II computers. The employees had no choice but to use the product.

Enforcing such a change might yield markedly undesired results if company culture resists the change.

A good example would be the culture of strict specialisation, where people are discouraged from partaking in activities outside their predefined role.

Introducing dogfooding will require slowly changing this culture. Managers must promote dogfooding and provoke employees’ interest in using the product.

Good leaders are role models; showing the employees how the leaders use the product daily might be a good idea.

The ‘evolution’ approach demands a slow but steady pace. Taking employees’ feedback — and acting upon it — is a must. As soon as people see their voices ignored, dogfooding is doomed.

References: