Dogfooding is an important part of software development. Google “dogfooding blog post” and you’ll have reading material for weeks. But what do you do when it’s tough to dogfood your own product? What do you do when dogfooding your own product isn’t even a viable possibility? The first company I worked for wrote practice management software for doctor’s offices. That’s a fancy way of saying we wrote a program that helped deal with the business part of having a doctor’s office. That meant we did things like scheduling patients, billing insurance, and keeping track of the payment statuses for the patients. In a situation like this, dogfooding our own stuff would be tricky, as that company, like most companies really, didn’t have a medical practice sitting in the lobby. The second company I worked for was a government contractor working on a defense contract. I’ll leave the difficulties of dogfooding that product somewhere along the lines of if we used our software in a dogfooding context, we’d probably have broken several laws.
Dogfooding is important, it forces you to understand what your users deal with in trying to do anything with your product, so any difficulties dogfooding makes it hard to actually understand just what you’re putting your users through. What are developers to do when there’s no good way to use their own product? Or what’s probably worse, what’s a developer to do when there’s no good way for anyone in their company to dogfood their product? While we’re on the topic, how do you thoroughly dogfood your software when you also have multiple degrees of separation from the developers and the users?
There are some people who advocate using your software for anything it can be used for, even if that isn’t the point, sort of “off-label” usage in a way. While that would certainly get you to use your own software, I’m not totally sure that’s the best way to go about testing your code internally. The idea behind dogfooding is to make your software really awesome through actual usage. Deviating from how your software is actually is actually used could lead to developers focusing on all the “wrong” things from a user’s perspective simply by exposing pain points that aren’t visible during a normal user’s workflow. This gets even worse when such changes exasperates actual pain points that you don’t encounter when you use your own software other than as intended.
“Off-label” usage of a product could also mean that you’re not using the optimal solution for a problem. Don’t get me wrong, if you’re product is designed to do a certain job, then you need to be using it to do that job internally because that’s the only way you’re going to turn it into the best option for that need out there. However, for a profession that likes to preach about “using the right tool for the job” in things like choosing a programming language for a project, selecting which library to use, or picking a database to hold your information, “off-label” software usage seems a little hypocritical.
If you use dogfooding to help drive development of your software, and “off-label” dogfooding could possibly drive development in a direction other than its intended purpose, does “off-label” dogfooding cause a pivot for your product? I have no idea what the odds of that happening are, but it’s probably something for businesses to be aware of. Given how part of the being a successful business means pivoting as the situation/market/etc. demands, “off-label” dogfooding is probably the best way to gauge the adjustments needed. Your engineers have a better gauge of just what kind of good they’re doing (nothing motivates people like an indication of progress), your code is better tested (because it’s getting a lot more use before your customers have to put up with it), and you have a better domain knowledge of whatever problem your code was built to solve (since you’ve transitioned to something that you can better field test).
This is probably a net good thing if you’re willing to go for it, but could also be a big impediment if you insist on “off-label” dogfooding without allowing that to possibly change just what it is you do as a company. In that case, what dogfooding you are doing is either useless (because you’re ignoring what you encounter since it doesn’t mirror real-world usage while at the same time not using your product in a real-world manner), or harmful (because it’s distracting development from important things while fixating on irrelevant details. Either way, I’m guessing you should probably approach dogfooding software other than how it’s intended to be used with caution.
All of this leads me to wonder, are software development shops the best way to go about writing code? After all, there are a lot of problems that can’t be dogfed without working day in and day out in an entirely different industry other than software development. Sure, pure software development shops can write great software to solve lots of problems, primarily communication, data collection, data management, or data analysis. But what about things like medical practice management and billing? Or intelligence applications? Those are the kinds that can’t really be used well by anyone other than customers.
Maybe the future best practice for software development will be a very small number of developers at a company working in-house talking to a few other developers working in-house at other companies, trading notes and putting together some open-source code designed to work at all their companies, and it does, because they, and their co-workers at those companies, use and perfect it every single day. Their code is not only being dogfed, it’s being dogfed in a real-world context. They know exactly what their target users are going through, because they’re sitting somewhere between “are the target users” and “are down the hall from the target users”.
Even if dogfooding your own software is feasibly possible, how many companies do it, especially if they’re not building something their developers would use in their day-to-day life? I guess this is how the whole idea of dogfooding “off-label” started, but if this isn’t really a problem you run into day in and day out, perhaps that’s a sign you’re the wrong kind of person to be tackling that particular problem. Maybe this passing idea of the best software is open source and done by in-house developers within the same industry, or at the very least developers with as few degrees of separation between themselves and their users.
Ultimately, I think the real problem dogfooding is trying to solve is too many degrees of separation between developers and users. And to be honest, having developers double as users does eliminate that problem, but that only works when developers are accurately behaving as users, not just trying to force using their software into their day-to-day work. Dogfooding also has to inform development direction and priorities, otherwise you’re just ignoring the results, which defeats the whole purpose of the exercise. If you can’t dogfood well, then there’s a couple of things you may want to consider. The first, is that you’re not the right group to approach that problem domain. The second is that your approach may be wrong. After all, how can you tell if you’re actually solving a problem if you can’t accurately test your idea? In that case, you need to let your dogfooding change the direction of your company to something you can better test and experiment with. Maybe this leads to a new way of developing industry-specific software, maybe not. All I know is, good dogfooding is hard, and maybe that’s a sign we’re approaching it the wrong way.