Paul Saffo is credited with inventing the mantra, “Strong opinions, weakly held.” In 2008, he wrote1:
The point of forecasting is not to attempt illusory certainty, but to identify the full range of possible outcomes. Try as one might, when one looks into the future, there is no such thing as “complete” information, much less a “complete” forecast. As a consequence, I have found that the fastest way to an effective forecast is often through a sequence of lousy forecasts. Instead of withholding judgment until an exhaustive search for data is complete, I will force myself to make a tentative forecast based on the information available, and then systematically tear it apart, using the insights gained to guide my search for further indicators and information. Iterate the process a few times, and it is surprising how quickly one can get to a useful forecast.
Since the mid-1980s, my mantra for this process is “strong opinions, weakly held.”
The process he’s describing is iterative. At each step, you come up with the best forecast you can despite limited information, and then you act with confidence. Where others would be tentative, would delay action to perform more research, or would hedge their bets, you move forward.
However, your strong opinions are “weakly held.” You mix action with further investigation. You deliberately search for flaws in your strong opinions. You evolve to have new opinions. And of course, these new opinions are also strong opinions. You move forward again and repeat the process.
“Strong opinions, weakly held” is a dedication to taking a stand in the face of conflicting information and uncertainty. It’s also a dedication to continuous reflection and self improvement, a rejection of “legacy” thinking. It’s a rejection of clinging to old ideas just because nobody’s disproved them yet. If nobody else has disproved your strong opinions, you disprove them yourself.
Unspace is an opinionated software development company
We describe ourselves as “An opinionated software development company.” This doesn’t just mean that we have opinions. It means that we have strong opinions, weakly held.
It means that we have strong opinions about the best way for us to build world-class software for our clients, even though the entire software development industry is built on a massive pile of uncertainty. We don’t think we know the One True Way to develop software. We know that software engineering is still in its infancy as a practice. Great software has been written in Assembler, Lisp, C, Visual Basic, Perl, Haskell, and yes, PHP.
We don’t think that other opinions are wrong. We aren’t divas who refuse to subject ourselves to anything less than some narcissistic “standard of perfection.” But we do think that based on the evidence we’ve gathered and the experience we’ve gained, our tools and practices are useful, the equivalent of Paul Saffo’s “useful forecast.” We know they’re useful: We’ve iterated over them repeatedly, and we continue to iterate over them.
One of the sources of our strong opinions is the belief that the whole is greater than the sum of the parts. Consider the opposite of strong opinions: The belief in “best practices.” Best practices are the standard procedures that other companies in the industry are following.
Strong opinions vs. best practices
A naïve way to follow best practices is to survey companies and ask them how they develop software (If you are a CIO, you can save yourself the trouble and purchase the survey results from “analysts” who make a living charging vendors for the privilege of being named as leaders in—I am not making this up—something called a “magic quadrant”).
For each element of software development practice, you collect statistics. Thus, you can determine what the most popular hiring interview questions are, the most popular text editors or IDEs, the most popular source code revision systems, the most popular issue tracking systems, the most popular programming languages, the most popular project management methodology, the most popular test frameworks, the most popular QA process, and so forth.
The flaw in this approach is that these decisions are not independent variables. Some practices work well with others, some conflict. If you follow a waterfall project management practice, you will get very poor results if your developers practice YAGNI. If you practice continuous refactoring, you need to also practice continuous integration and especially automated testing.
As noted above, doing whatever seems to be popular—even if it’s using fashionable tools like Coffeescript or Node.js—is symptomatic of having weak opinions, not strong opinions. And our experience is that the results are also weak: The aggregate result of choosing popular tools and practices is that some work well with each other but some actively hamper each other.
Unspace is in the business of lowering risk
Why do people do this? Because there’s a lot of uncertainty about the best way to develop software. Gather a bunch of really smart people in one room and ask them how they do it. If you have ten people, you’ll emerge with fifteen opinions. As an industry, we can’t even agree on whether strong typing is a win. Simon Peyton Jones and Anders Hejlsberg say it is. Paul Graham and Alan Kay say it isn’t.
Nobody ever got fired for following “best practices.”
Given the uncertainty, social safety beckons in the footsteps of others. Nobody ever got fired for following best practices.
As “safe” as it may seem for someone’s career to pick and choose the best practices, we are not in the social safety business. We are in the shipping software business. Think about our business model for a moment. Why do clients engage us? To develop software, of course. Why don’t they do it themselves? Because it’s more advantageous to hire us than to do it themselves.
So how do we make it more advantageous to hire us than for our clients to do it themselves? Well, there are two basic business models we can follow. One is to be less expensive by charging less. If we can charge clients less per hour than they would pay for their own developers to do the exact same work, it’s cheaper to hire us than to develop software in-house.2
The other way to be more advantageous is to be less expensive by lowering the risk. Since working with Unspace means less risk than doing it themselves, clients insure against the possibility of disaster by hiring us. Given the enormous expense associated with failed software development projects, our clients save a tremendous amount of money when they hire us.
Lower risk saves money in two ways. Obviously, averting disaster is an incalculable savings. A project that seems cheap at the outset wastes everything if it fails. But not all failures are massive disasters. Some projects end up taking a lot longer than expected. Some are fraught with gotchas along the way that require continuous rework. Lowering risk throughout the project avoids the disasters, but it also lowers the cost of projects by wasting less time and money on things that don’t work.
Obviously, we like the “lower risk” model. It avoids disaster and is less expensive. But to make it work, we can’t simply do the same thing that everyone does. We can’t afford to have weak opinions, to use whatever hodgepodge of best practices seem to be surfing the hype wave this week. For that reason, we have strong opinions. We select people, tools, and practices based on how well they perform separately and together.
We accept that there isn’t enough (or any!) unbiased, empirical research answering questions such as whether C# and Linq is better or worse than Ruby and ActiveRecord, and we accept that popularity is not a substitute for wisdom. But we make our choices and we make them strongly. We invest heavily in learning our tools. We study, we practice, we debate, we examine. We place our code in the public eye3 and learn from the feedback we obtain.
Risk and project management
Our strong opinions extend to more than just tools. We have strong opinions about having an iterative, agile process. Given our business model of lowering risk, this makes perfect sense. The entire mantra of strong opinions, weakly held is to continuously iterate in the face of uncertainty. What could be more uncertain than the outcome of a software development project at its outset? The “strong opinions, weakly held” process is the process of forecasting and iterating to improve your forecast until it is a good forecast, until you’ve driven the uncertainty out.
We start every project with a great deal of uncertainty. But do we attempt to develop a “telephone book” specification in a vainglorious attempt to eliminate the illusion of uncertainty? No. We come up with the best estimate we can given limited information. In other words, we have an opinion. And then we start work. That’s what makes it a strong opinion: We commit to it, we don’t hesitate, trying to pad our estimates out with details that make them look impressive without significantly reducing risk.
Our opinions are weakly held. We do not put the plan in a glass case. We iterate. We review. We probe and test. We work with clients to develop prototypes and alphas and other manifestations of working software than can be poked and prodded and tested to see if our strong opinions need to be revised or even discarded.
This is an incredibly important foundation for how we reduce risk for our clients. Many of our clients approach us with a draft specification and two questions: “How much?” and “How long?” Answering those questions as best we can and then blindly following “the plan” does not remove any risk from the project.
The client begins the project with a tremendous amount of uncertainty, and answering those questions gives the illusion of reducing the uncertainty. But in fact, the uncertainty is still there. It is only by constantly re-evaluating and recalibrating our expectations that we reduce the actual risk in the project.
Unspace. Yes.
Others have popularized the notion that being “opinionated” means saying “No.” We believe this is true, and that saying “No” is a good thing. Another way to put it is that being opinionated means being focused. Our clients are more successful when they say “No” to non-critical features. Those same clients are saying “Yes” to delivering software earlier with fewer defects. Those clients are saying “Yes” to iterating more quickly and thus reducing uncertainty and risk. We try to take the same approach in everything that we do. Less is more, and the way you achieve “Less” is by saying “Yes” to less by saying “No” to more. Relentlessly.
Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away—Antoine de Saint Exupéry
But we do not fall in love with the sound of the word “No.” Our strong opinions are weakly held. We attack our own opinions. We question them. Today we use Haml for nearly all of our projects, to the point where a recent project was using Haml in the browser, performing the rendering in Javascript. Tomorrow we may discard Haml as a tool that was right for its time and place, but not for this time, not for this place.
That doesn’t mean we’ll swap Haml for something a little bit better, or even a lot better. It means we’ll think about our entire tool chain, our entire process, and ask ourselves which piece or pieces no longer fit, and what changes need to be made everywhere to continue to offer our clients a tremendous advantage.
Having strong opinions, weakly held isn’t about saying “No,” it’s about the right way to say “Yes.”