There’s a term we use in software design called the happy path. It describes a best-case scenario, in which customers use a product exactly as intended, without bumping into any edge cases or uncommon problems. This includes the interface you see when you sign up, setup steps you have to complete, and so on.
For software designers, a happy path is also an extremely powerful psychological tool that allows us to control people’s behavior and direct them to do whatever we want.
If that sounds surprising—and slightly terrifying—think about how many times you’ve blown past a lengthy software license agreement and clicked the Agree button without looking.
Were you thinking deeply about what you were doing?
Probably not. And you’re not alone! Research shows that humans have a natural aversion to decision making. As Smashing Magazine describes it, people simply don’t like to make choices unless they have to:
Making an explicit decision requires effort, after all. Time, thought and consideration are often required to determine the best choice. It turns out that people are remarkably sensitive (and averse) to the amount of effort that making a choice demands.
And therein lies the trouble.
If you pay close attention, you’ll notice something else about software happy paths. Like a tell in a poker game, they subtly reveal a company’s underlying motives.
Since designers know you’ll probably avoid making difficult decisions, they take advantage of your passivity and coax you into doing anything they want.
For example, if you’ve ever installed the Facebook Messenger app, you were likely encouraged to continuously upload all of your phone’s contacts to the service. This is framed as a way to help you text people quickly.
Look at that screen for a moment. There’s no opt out button! You can only choose OK or Learn More.
And who wants to Learn More when they’re signing up for a chat app? Almost nobody.
I’m guessing at least 80% of Facebook’s users just tap OK and move along immediately. There’s even a little animated arrow encouraging you to tap OK, in case you momentarily considered doing something else.
But let’s say you’re among the 20% that happens to pick the Learn More button. You’ll get a cutesy second screen:
This screen finally has an opt-out button, in plain text, buried underneath some repetitive copywriting that vaguely implies you’re wrong for questioning any of this.
Tapping that OK button is a trivially small decision. It takes just one minuscule tap of your finger. It’s done in less than a second.
But the impact is quite large indeed! You’re implicitly agreeing to send Facebook little bits of info about everyone you know. Now imagine the network effects when you multiply that by the millions or billions of users who also tapped OK in the blink of an eye.
This little happy path is feeding a massive data beast, which probably has details about almost everyone on Earth. And Facebook had ample space — two separate screens! — in which to mention anything about this.
So why didn’t they?
Because endless growth and data collection is the foundation of their business, and that necessitates doing gross invasive things to their users.
They need you to feed the beast, and they certainly don’t want you to think about it. So they use cartoon animals and sneaky happy paths to make sure you stay blissfully ignorant.
Now, of course happy path design also happens at companies that don’t have any nefarious hidden intentions.
When you sign up for Basecamp, we don’t trick you, coax you, or collect any more information than we need to get your account working properly.
However, we’re also a for-profit software company, and business performance is one of our considerations when we design our interfaces. When you sign up for Basecamp, we encourage you to take actions that give you the best chance of having success, and (hopefully) becoming a paying customer.
The difference is, our approach is fully above board. If you have success with Basecamp, your life gets a little easier, and we earn a new paying customer. We promise to support you and protect your data. You pay us for that. Cool for everybody.
Using software is inherently a handshake agreement between you and the service provider. It’s not unlike paying for a physical service.
The problem is, many of the dominant software makers are abusing your handshake in increasingly dastardly ways. They treat their customers like sitting ducks — just a bunch of dumb animals waiting to be harvested. And when growth slows, they resort to deceptive and creepy tactics to keep the trend lines pointing skyward.
So what can we do, as consumers?
First, keep your eye out for sneaky manipulation, especially when you’re first signing up for a service. If you’re asked to share personal information or forced to commit to something that makes you feel uncomfortable, you’re probably being used.
Second, slow down and thoroughly consider the choices you’re making. You’ll end up discovering weird, surprising things about services that you thought were harmless.
Third, be wary of any “free” software platforms. Sure, you’re not giving those companies any money directly. Instead, you’re giving them something else they’ll use to get money — your attention, your time, your personal information—all things that are arguably more valuable than money.
And finally, pay for software! When you pay real money to software creators, you’re supporting them, and they’ll support you in return.
More and more independent software makers are standing up and defending users against data misuse and manipulation. Recently, Feedbin significantly altered their tech to protect their users from being tracked by the likes of Facebook or Twitter. That’s a great example, and there are many others like it.
Vote with your wallet, and support the people who really do have your back.
For years we’ve used Basecamp To-Dos to track all of our design and programming work here at Basecamp. They help us make sure that nothing slips through the cracks.
However, for some projects, tracking to-dos isn’t enough. When you have dozens or hundreds of tasks, you need a way to see the bigger picture. Is the project going to be done on time? Are we making progress on the right tasks? Which things need to be solved now and what can be deferred until later?
To solve this problem, we built an entirely new idea into Basecamp To-Dos. It’s a 10,000-foot view of our projects that answers the hard questions about where things really stand.
Introducing the Hill Chart.
Progress is not a number
“42% of the tasks are complete.” What does that tell you? Very little.
For creative work and software projects, you can’t describe progress with a number. Why not? Because tasks on a project aren’t all the same. If the team gets stuck or starts to run out of time, it matters which tasks are in that 42%. The strategy for getting unstuck depends on where you’re stuck.
More than that, we don’t actually know every task in advance. As we roll up our sleeves on a project, we discover more detailed tasks to track than we had in the beginning. A raw percentage count would show our progress going backward instead of forwards when that happens!
What we really want to know is where the work stands. Has the team figured out how to do it? Are there unknowns that will block us ahead? What’s solved and what’s still full of uncertainty?
Work is like a hill
We found a metaphor for talking about this at Basecamp. Every piece of work has two phases. First there’s an uphill phase where you figure out your approach. You have a basic idea about the task, but you haven’t figured out what the solution is going to look like or how to solve all the unknowns.
Then after you’ve explored what works and what doesn’t, you reach a point where there aren’t any unsolved problems anymore. That’s like standing at the topof the hill. You can see clearly all the way down the other side. Then the downhill phase is just about execution.
Work on the two sides of the hill is very different.
Uphill work is hard to estimate. You might go in circles searching for the right approach. And as long as unknowns remain, there’s risk. The programmer thinks it’ll be a quick change but the API is different than expected. Or the interaction design seemed like a quick fix but there’s no room for the button on the mobile version.
On the downhill side, the world is certain. You’ve solved the problems, figured out your approach, eliminated the unknowns. All that remains are steps of execution to finish the project.
A human data point
No calculation will tell you how many unknowns are on a to-do list. Or how hard the remaining problems are. That’s why we built a way for teams to communicate, in a human way, exactly how they feel about where the work stands from unknown to known using the metaphor of the hill.
Here’s a demo to show you how it works.
A Hill Chart from a real project
Each of our development projects in Basecamp is made of a set of To-Do Lists. We create a To-Do List for each piece of work that we can make progress on independently.
Now to track progress, we turn on Hill Chart tracking for each list. This will reveal a Hill Chart on the top of the To-Dos screen with a dot for the list we’re tracking.
We did this for three lists. Next we click Update on the Hill Chart and drag the dots for those lists into position.
Now anybody who checks on the project can see the status of these three lists. Two of them are over the hill — full of certainty, with just execution left. One is still on the uphill slope, which means there are unsolved problems or open questions.
Note how that the status is human generated, not computer generated. This reflects a real person’s feeling of the work at this moment. And because the status is attached to lists, not individual to-do items, we gain a higher-order perspective on all the work at once.
Hills make history
Every time someone updates the positions on the hill, a new snapshot is saved to the project’s history. This enables managers to immediately acquire a ton of context about what is moving on the project and what isn’t without peppering the team with questions. People on the team can optionally annotate each of their updates with commentary. You can even comment on or Boost someone else’s Hill Chart update. This enables a new level of fast, asynchronous communication about high-level progress on projects.
More well-defined work
Sometimes trying to position a list on the Hill Chart helps you to better structure the work. On a recent project we were building a feature to notify people when an Event in Basecamp was rescheduled.
That dot sat there for a few days without moving. Something was wrong. Why weren’t we making progress? After a short talk with the team, we realized that it was unclear where to place the dot because part of the work was fully figured out and part wasn’t. The back-end code to deliver the notification was fully solved. But there was some more design work relating to the emails and Hey! menu that we hadn’t figured out. So where should the dot go?
In a case like this, the hill is telling us to break up the list. We renamed the original list to “Notification: Delivery” and moved it over the hill to show where it really stood. Then we created two separate lists to track the front-end work that was still uphill.
Redefining the To-Do Lists like this made it easier to see what was actually going on in the project and what needed to be done next.
Flexible, per-list setting
For each project, you can choose which To-Do Lists appear as dots on the Hill Chart. It’s a per-list setting, so you can still have regular To-Do Lists mixed in with your tracked lists. We usually keep a list called “Chowder” at the end a project for loose ends that don’t fit anywhere else, and we don’t plot that one on the hill.
From unknown to known, and known to done
Instead of counting tasks, the Hill Chart shows where the work really stands. From unknown on the far left, to known at the top, to done on the far right.
Since we adopted the Hill Chart internally at Basecamp, our teams have been communicating about progress at a level never before possible. Our intuitions are the same, but now we have a visual way to immediately show each other where the work stands. And because of the Hill Chart history, we don’t need to call meetings to catch up on a project’s status. It’s no longer a challenge to see what’s in motion and what’s stuck. We can have quick, substantial conversations asynchronously about where to focus next or how to break up a problem.
That’s the kind of thing Basecamp is supposed to do: make you more organized, give you more time, and put everybody on the same page.
We hope you can experience the same benefits we have by trying the Hill Chart on your next Basecamp 3 project. You can use the Hill Chart on any project today by navigating to a particular To-Do List and choosing “Track this on the Hill Chart” from the Options menu (•••) in the top-right corner.
New to Basecamp? Learn what it’s all about and start a 30-day free trial over at Basecamp.com.
For years people have been asking us how. How do you design things? How do you code things? Why do you do it this way vs. that way? How do you think about writing? How do you think about what makes it into a product and what does? How do you decide which features to build and which ones not to? How do you stay up on everything that’s going on in your business?
We’ve written about these topics for years — and we’ll keep writing about them — but we want to bring some show to the tell. So we started a new YouTube Channel called Getting Real. To start, DHH and I will be posting occasional videos of actual day-to-day work. Down the road other people at Basecamp may join in.
In 2017 we made web accessibility a priority at Basecamp. It was long overdue.
Over the past year, I made it a personal mission to make Basecamp 3 more accessible for people with disabilities that affect how they use the web. It’s something we’d been meaning to focus on at Basecamp for a while. But as with many unfamiliar and seemingly immense tasks it was just too easy to put off! Which is exactly what we did, for years.
In the end, it took the mix of a personal search for meaning, the reward of learning something new, and a bit too much downtime to finally make some progress.
Excuses had been easy to find. “Why spend time improving something that only a seemingly small subset of our customers would benefit from?” After all, we’ve always found it important to say no to feature requests that could bloat the product or be useful to only a slice of our customers.
Making Basecamp accessible was different, though I didn’t realize it at first. Back in early 2017, I was about to hit my eight year anniversary with Basecamp and the itch for a new challenge was real. I needed to find something I could learn and grow around, and at that, a project which possessed some inherent meaning. Not to discount the value of the quality assurance (QA) work that I’d been doing at Basecamp for the last five or so years — I know these efforts have a real impact on a tool that lots of people use to run their projects. But there’s just enough of a separation between me and them to dilute the potential energy of that truth. I needed to find something with more resonance.
I had recently experienced firsthand the compromising effects of losing one’s eyesight, and learned about some of the assistive technologies available to help. My grandmother, an avid reader throughout her life, was suffering from macular degeneration. It became impossible for her to pick up a book or newspaper as she’d done for so many years. But with the aid of a digital talking book player provided by the National Library Service and an enlarger acquired through The Chicago Lighthouse, she was able to retain her independence and connection to the outside world.
Our QA process at Basecamp could be described as a “black box” or exploratory affair. QA doesn’t generally participate until a feature has been built-out to the point where it can be used like a customer would. Only then do I storm in with my fellow QA’er Ann Goliak to hammer on what the development team has been cooking up. We search for bugs and evaluate the new feature from the perspective of a customer. Our fresh eyes can often spot things the deeply embedded development team cannot.
Then, since we work on a schedule of six-week development cycles, the feature ships, a new cycle begins, and our bug-hunting frenzy is often followed by a whole lot of downtime for team QA. It was during one such lull back in early 2017 that I finally gave in, flipped on VoiceOver (Apple’s screen reader built into macOS) and started pressing tab on my keyboard to navigate though Basecamp. And then I cringed listening to the confusing way each item on the page was being described by the screen reader 😬
As I found things that didn’t seem right during that initial run through I started making to-dos in our “Basecamp 3: Bugs” project in Basecamp, like we do for all bug reports. But back then I didn’t actually know how a given element, like a simple button, was best described to someone using a screen reader, nor which keyboard interactions were expected to go along with it. I quickly realized that if I couldn’t clearly communicate to my colleagues what specifically needed to be tweaked, the likelihood anyone would pick up these bug reports was slim. No one likes being assigned a research project!
So I took on the necessary research to understand what the Web Content Accessibility Guidelines (WCAG) defined as the proper and expected way that any given thing on a web page should look and behave in order to be accessible. I opened up my code editor, made some tweaks, and tested locally to see if I was on the right track. I was actually implementing these fixes! And they actually worked! I had dabbled in a couple of Rails and other programming courses over the years, though never with much traction. Now I finally understood the satisfaction that comes from writing software code – and I was hooked.
Incorporating feedback about web accessibility into our existing QA process is in large part why we we’ve been able to build traction. During new feature development, we treat accessibility concerns just like any other type of bug. Over time, these bits of technique help to inform our designers and developers how to build with a focus on accessibility from the start.
Several years back during an all company meet-up one of our designers, Jason Zimdars, played a recording that a customer had made to demonstrate using Basecamp with a screen reader. It was both enlightening and incredibly embarrassing that this aspect of product quality had completely escaped us. A few years later, one of our interns Nathan Petts conducted a general screen reader evaluation, once again highlighting many areas where we were coming up short. Both would spark the conversation about accessibility improvements, but each time the result quickly became a huge pile of problems with no clear place to start. We would make a few tweaks, then shelve the topic for another couple of years.
In contrast, over the past year all new features we’ve shipped have been designed and tested to be accessible!
We still have a ways to go before Basecamp 3 can be declared fully accessible. But I can say with certainty that everyone at the company agrees how important it is that we make time for these improvements.
I have gratitude for being with a company like Basecamp that values the space and autonomy for ongoing learning and growth. This made it possible for me to jump from customer support to QA back in 2011, and now it’s created the circumstances for this new undertaking in web accessibility.
In future posts, I’ll share some of the specific tweaks we’ve made to make Basecamp 3 more accessible, and the techniques we used to get there.
If you have specific questions, or want to hear about something related that I didn’t cover, add a comment and I’ll be happy to share more details down there or in a future post. Thanks for reading!
When you work on really long projects — say 3, 6, 9 month projects — or projects that don’t have any end in sight, “we can do that later” typically means you’ll get to it eventually, as part of the current project. Long time frames give you invisible space to pack away unrealistic amounts of work. Since later is so far away, there’s no harm in kicking the can down the line. In other words, later makes a pile at the end.
Gnarly problem you can’t figure out how to solve yet? Punt it into the later pile. Design not coming together quite right? Toss it in the later pile. Taking on lots of technical debt as you go? Push it into the later pile.
But then as you near the end, you run into this big pile of stuff you said you’d eventually deal with, fix, redesign, tighten up, etc. But there rarely seems to be enough time at the end, so you either end up guiltily ignoring it entirely, or hastily patching it together with duct tape. And when you hastily patch, you often end up creating another fix-it-up project later.
But, when you work in six week cycles, or relatively short time frames, later means something else entirely. There’s no time for later. It’s now or not. Later doesn’t mean we’ll get to it at the end of this cycle. It means we’ll drop it. Later means another time, not this time. Later isn’t a obligation, it’s a maybe. Later isn’t a cage, it’s freedom. It’s not a debt to pay off, it’s an asset. There’s no pile, there’s no guilt, there’s no feeling of late nights and crunch time ahead. Later simply means not now, not soon, and not for sure.
Why Agile Isn’t Working and What We Do Differently
Agile started off as a set of values. Values are subtle and abstract, so as agile spread, what spread wasn’t the values but the practice of working in cycles. Cycles are easy to explain and easy to copy.
People in our industry think they stopped doing waterfall and switched to agile. In reality they just switched to high-frequency waterfall.
Agile became synonymous with speed. Everybody wants more, faster. And one thing most teams aren’t doing fast enough is shipping. So cycles became “sprints” and the metric of success, “velocity.”
But speed isn’t the problem. And cycles alone don’t help you ship. The problems are doing the wrong things, building to specs, and getting distracted.
Claiming there’s a True Agile™ somewhere in the past or future doesn’t help either. When your team struggles with shipping, you need practical steps you can apply here and now. Not just an ideal.
Cycles are good. We work in cycles at Basecamp. But in addition to cycles you need three other practices to ship on time and in good health.
Deliberate resource allocation
Designers and developers can’t make progress if people constantly pull at their attention. It doesn’t matter if support finds a bug or sales needs a new feature. Allocating resources means dedicating resources. Whoever allocates the time and money to build a feature must also protect the team so they can do what was asked. It takes a mandate from above to secure the team’s time and attention. The team is doing this and only this during the cycle.
At Basecamp we start each cycle of work with a team of three: one designer and two programmers. They have nothing to do but this project. If you feel you must fix bugs the moment they arise, then dedicate resources for that. If you have tension between sales and product, make a choice for this cycle. If you don’t have enough people, rotate cycle time among departments.
Only management can protect attention. Telling the team to focus only works if the business is backing them up.
If a team works to a spec, there’s no point in iterating. The purpose of working iteratively is to change direction as you go. Defining the project in advance forces the team into a waterfall process. If every detail of the plan must be built, teams have no choice when they discover something is harder than expected, less important than expected, or when reality contradicts the plan.
At Basecamp we kick off each project with a core concept. We do our homework on the strategy side to validate that some version of the idea is meaningfully doable in the time we’re allocating. We’re also sure that less than 100% of the concept will ship. Not everything will make it but the important things will. If we aren’t sure, we’ll slot something else into the cycle and come back when we’ve honed the concept enough.
To start teams off with a concept like this, you have to separate the core from the periphery. Separate the things that are absolutely important from the things that were just “ the idea we had for how to do it.”
In practice, this means giving the teams power to redefine scope. Some things are essential and other things aren’t. The team must be able to know the difference and make calls accordingly. To reinforce this, we give teams low fidelity hand-drawn sketches when a cycle starts and spend more time on motivation than the specifics of design and implementation.
Teams that track “velocity” and “story points” treat development as if it’s linear labor. Software development is not like moving a pile of stones.
If work was like that, you could count the stones, count the time to move one, do the math and be done.
Work that requires problem solving is more like a hill. There’s an uphill phase where you figure out what you’re doing. Then when you get to the top you can see down the other side and what it’ll take to finish.
The uphill phase is full of false steps and circles and dead ends. It’s where you encounter the unexpected. The programmer says “yeah that’ll take two days” but then they start touching the code and the reality is more complex. Or the designer says “this interaction will be perfect” and they test it on the device and it’s not what they hoped.
The most important question for a team isn’t “what is left?” but “what is unknown?” Can you see the edges? Have you gone in there and seen everything that needs to change? The only way to gain certainty is to roll up your sleeves and engage with the reality of problem.
At Basecamp our teams seek out the areas with the scariest unknowns and work on them first. This uphill work requires strategies. We wrote about these in Getting Real. Open the code, spike something that works, load it with real data and try it. When the whole feature is too big to prototype, factor out the most important pieces and spike them.
The uphill work is where you learn what’s hard and what’s possible and make value judgements. Here’s where you make decisions about those mutable requirements because you’re seeing the real costs and opportunities in the implementation. Learning uphill requires the focus and time given to the teams by deliberately allocated resources.
We’ve done this informally for years, focusing on unknowns and chipping at them first. We recently started formalizing this with the Hill Chart. A question we often ask these days is “where is that on the hill?”
Here’s a snapshot from the Search in Place project that shipped in October.
And here are some moments in time from the To-Do Groups project.
It takes a whole business to ship
Whether teams work in cycles or not is just one part of the story. An “agile” team isn’t going to get very far if management doesn’t protect their time. And if they don’t have flexibility to change requirements as they learn, late nights and late delivery are guaranteed.
Designers and developers can learn the uphill strategies from Getting Real to gain certainty instead of crossing their fingers. Whoever sets requirements can give teams the room to push back in the uphill phase. And resource allocators can take more responsibility to guard the focus of their teams.
We’ve been doing it for 15 years. Hopefully sharing some of these techniques will help you do it too.
Since this article was written, we built and released a feature in Basecamp 3 so you can make your own Hill Charts. See all the details here:
Ruminations on the heavy weight of software design in the 21st century.
Recently I took a monthlong sabbatical from my job as a designer at Basecamp. (Basecamp is an incredible company that gives us a paid month off every 3 years.)
When you take 30 days away from work, you have a lot of time and headspace that’s normally used up. Inevitably you start to reflect on your life.
And so, I pondered what the hell I’m doing with mine. What does it mean to be a software designer in 2018, compared to when I first began my weird career in the early 2000s?
The answer is weighing on me.
As software continues to invade our lives in surreptitious ways, the social and ethical implications are increasingly significant.
Our work is HEAVY and it’s getting heavier all the time. I think a lot of designers haven’t deeply considered this, and they don’t appreciate the real-life effects of the work they’re doing.
Here’s a little example. About 10 years ago, Twitter looked like so:
How cute was that? If you weren’t paying attention back then, Twitter was kind of a joke. It was a silly viral app where people wrote about their dog or their ham sandwich.
Today, things are a wee bit different. Twitter is now the megaphone for the leader of the free world, who uses it to broadcast his every whim. It’s also the world’s best source for real-time news, and it’s full of terrible abuse problems.
That’s a massive sea change! And it all happened in only 10 years.
Do you think the creators of that little 2007 status-sharing concept had any clue this is where they’d end up, just a decade later?
Seems like they didn’t:
People can’t decide whether Twitter is the next YouTube, or the digital equivalent of a hula hoop. To those who think it’s frivolous, Evan Williams responds: “Whoever said that things have to be useful?”
That’s not what they originally built. It grew into a Frankenstein’s monster, and now they’re not quite sure how to handle it.
I’m not picking on Twitter in particular, but its trajectory illustrates a systemic problem.
Designers and programmers are great at inventing software. We obsess over every aspect of that process: the tech we use, our methodology, the way it looks, and how it performs.
Unfortunately we’re not nearly as obsessed with what happens after that, when people integrate our products into the real world. They use our stuff and it takes on a life of its own. Then we move on to making the next thing. We’re builders, not sociologists.
This approach wasn’t a problem when apps were mostly isolated tools people used to manage spreadsheets or send emails. Small products with small impacts.
But now most software is so much more than that. It listens to us. It goes everywhere we go. It tracks everything we do. It has our fingerprints. Our heart rate. Our money. Our location. Our face. It’s the primary way we communicate our thoughts and feelings to our friends and family.
It’s deeply personal and ingrained into every aspect of our lives. It commands our gaze more and more every day.
We’ve rapidly ceded an enormous amount of trust to software, under the hazy guise of forward progress and personal convenience. And since software is constantly evolving—one small point release at a time—each new breach of trust or privacy feels relatively small and easy to justify.
Oh, they’ll just have my location. Oh, they’ll just have my identity. Oh, they’ll just have an always-on microphone in the room.
It all sounds like an Orwellian dystopia when you write it out like this, but this is not fiction. It’s the real truth.
See what I mean by HEAVY? Is this what we signed up for, when we embarked on a career in tech?
15 years ago, it was a slightly different story. The Internet was a nascent and bizarre wild west, and it had an egalitarian vibe. It was exciting and aspirational — you’d get paid to make cool things in a fast-moving industry, paired with the hippie notion that design can change the world.
Well, that motto was right on the money. There’s just one part we forgot: change can have a dark side too.
If you’re a designer, ask yourself this question…
Is your work helpful or harmful?
You might have optimistically deluded yourself into believing it’s always helpful because you’re a nice person, and design is a noble-seeming endeavor, and you have good intentions.
But let’s be brutally honest for a minute.
If you’re designing sticky features that are meant to maximize the time people spend using your product instead of doing something else in their life, is that helpful?
Or are you a glorified Huckster—a puffed-up propaganda artist with a fancy job title in an open-plan office?
Whether we choose to recognize it or not, designers have both the authority and the responsibility to prevent our products from becoming needlessly invasive, addictive, dishonest, or harmful. We can continue to pretend this is someone else’s job, but it’s not. It’s our job.
We’re the first line of defense to protect people’s privacy, safety, and sanity. In many, many cases we’re failing at that right now.
If the past 20 years of tech represent the Move Fast and Break Things era, now it’s time to slow down and take stock of what’s broken.
We know we have a big responsibility on our hands, and we take it seriously.
You should too. The world needs as much care and conscience as we can muster. Defend your users against anti-patterns and shady business practices. Raise your hand and object to harmful design ideas. Call out bad stuff when you see it. Thoughtfully reflect on what you’re sending out into the world every day.
The stakes are high and they’ll keep getting higher. Grab those sociology and ethics textbooks and get to work.
If you like this post, hit the 👏 below or send me a message about your ham sandwich on Twitter.
Since unit testing and test-driven development burst onto the programming scene in the early 2000s, too many programmers have deluded themselves into thinking that they could ship high-quality software with automated testing alone. It’s a mirage.
Don’t get me wrong. The industry took a big leap forward when the tooling and conventions for automated testing got put in the spotlight. But in many corners, it also threw the baby out with the bathwater. Automated testing does not replace “testing by hand”, it augments it.
Testing by hand, or exploratory testing, is a crucial technique for ferreting out issues off the happy path. It is best carried out by dedicated testers who did not work on the implementation. Those pesky auditors who have the nerve to try using the application in all the ways a real user might.
None of this is news, of course. I remember reading a statistic long ago saying that Microsoft had three testers for every developer. That sounds wild to me, but I suppose if you’re trying to keep three decades of backwards compatibility going, maybe you do need that sort of firepower.
What it is, though, is forgotten wisdom. Especially in the small and mid-sized shops. Propelled by the idea that automation could take care of the testing, dedicated testers weren’t even on the menu in many establishments.
For many years that included us at Basecamp. Yeah, sure, programmers and designers would sorta click through a feature and make sure it sorta worked. Then we’d ship it and see what users found.
But we leveled up in a big way when Michael Berger became the first dedicated tester at Basecamp several years ago. He’s since been joined by Ann Goliak. And between the two of them, we’ve never shipped higher quality software. Far more issues are caught in the dedicated QA rounds that precede all major releases.
What Ann and Michael bring to the table just cannot be replicated by programmers writing automated tests. We still write lots of those, and they serve as a very useful guide during development, and form a strong regression suite. But they’re woefully insufficient. And it doesn’t matter whether they’re unit, functional, model, or even system tests. They’re no substitute for a fresh pair of human eyes bent on breakage.
I hope we start seeing a renaissance for human testers at some point. Not just as something to do if there’s time, but something for dedicated individuals to do because it’s effective. Long live manual testing!
Troy Henikoff was a college student in 1984 when he wrote his first program, a piece of software to help his grandfather’s steel warehouse manage their inventory. That summer project led Troy to start his own software consulting business a couple years later. This is an atypical Distance story about beginnings, endings and unexpected legacies.
WAILIN: Troy Henikoff describes himself as an unintentional entrepreneur. Today he’s a well-known figure in Chicago’s tech scene, but when he began dabbling in computer programming and setting up his own business, there was no established startup culture for him to absorb. No networking events, no hoodies, no cliches about hustle or crushing it or changing the world. Troy’s story starts in 1984, at his grandfather’s steel warehouse on Chicago’s south side. He had just finished his sophomore year of college.
TROY HENIKOFF: So that summer when I got to Chicago, I was given a bunch of tasks to get done, all the things that they hadn’t gotten around to, so getting quotations to get the roof fixed on the warehouse. The air conditioner in the office wasn’t working well. I had to find someone who could repair this like antique air conditioner. It was 1984 and my uncle actually was the one who said, “You know, these computers, these PCs are getting to be powerful. Maybe we can move our inventory from index cards” — literally three-by-five cards — ”onto a computer.”
WAILIN: Welcome to The Distance, a podcast about long-running businesses. I’m Wailin Wong. Today’s episode is a little different from the kinds of stories we usually do. For starters, we’ve never featured a tech entrepreneur on The Distance, mostly because I’m more drawn to things like embalming fluid and tofu. But I really wanted to tell Troy’s story. So stick around, you won’t be disappointed.
ROSA: The Distance is a production of Basecamp. I’m Rosa, a programmer at Basecamp. Basecamp is the better way to run your business. It’s an app for communicating with people and organizing projects and work. If you’re feeling overwhelmed by email, chat and meetings, give Basecamp a try. Sign up for a 30-day free trial at basecamp.com/thedistance.
TROY: There used to be computer stores. There was ComputerLand and Entre, and I went to all these stores and asked, “What software do you have to help me manage inventory?” And it was all software designed for what you’d think of a hardware store. You have a certain type of product—a hammer, a screw—and you’d have a quantity of that product, and when you ran low, you’d order more of that product. The problem was, in my grandfather’s business, every single thing that came in the door, they did a chemical analysis of it to find out exactly how much chromium and zinc and nickel was in the steel. When people needed specialty steel, they’d call them and say, “What do you have that’s high nickel, low chromium?” So they never replaced inventory with something like it. Everything was unique, and so none of these software programs worked. And I was about to give up and I was at a ComputerLand and I saw a guy entering into an inventory system for them and I said, “Well, what program is that?” And he said, “Oh, I wrote that. That’s in DBase.” I said, “Well, what’s DBase?” And he started telling me about it and he’s like, “Let me show you the code.” And he did and it looked really similar to Pascal. And so I went back to my grandfather and my uncle and I said, I don’t think there’s a program out there that’ll do what you need it to do, but I think I can write one.
WAILIN: Troy had taken one computer science class at Brown University, where he was studying mechanical engineering. That class was in Pascal, so he felt like he could figure out Dbase. The next step was to actually buy a computer.
TROY: I just went to the Yellow Pages and started calling and trying to get the best deal I could ’cause I was afraid it was too expensive and my grandfather wouldn’t pay for it. And so finally, I found this place called MPK Computing and this guy named Michael, and he had the best price by about a thousand dollars, really cheaper. It was a PC with a hard drive, an external thing called a Bernoulli box made by Iomega with external hard drives, um, a printer, a monitor and a copy of Dbase.
WAILIN: The guy who sold Troy the computer was named Michael Krasny, and he delivered the system from the trunk of his car. It cost $6,000. Troy studied the Dbase manual and started working on the inventory program. When he got stuck, he called Michael for help. Troy got it done in four weeks.
TROY: I worked really late nights and long hours, but I got it running. And by the time I went back to school, it was working. It was printing out their inventory. It was managing the inventory. They were afraid to go entirely onto the computer, so what they had happen was the secretary — they had secretaries back then — would enter the steel as it came in and it would literally print out three-by-five cards that would go in the card file, which is how the salespeople were used to accessing the data. Except this time, instead of scribbling stuff out and erasing what was on the file when you sold stuff, it would get entered into the computer and a new card would get printed out.
WAILIN: The next summer, after his junior year, Troy got another software job through a connection of his father’s. He wrote a program for a manufacturer of EKG electrodes to track raw materials and finished products, and he bought the computer from the same guy, Michael at MPK Computing. Troy went back to Brown for his last year, and then it was time to graduate. He had a mechanical engineering degree but was unsure what he wanted to do with it.
TROY: You’re a mechanical engineer, what could be cooler than designing submarines and helicopters? So I was interviewing with General Dynamics and Sikorsky Aircraft and actually I got a job offer from General Dynamics and they were so excited. And you walked into this building that was just seven floors of football fields filled with cubes. It was horrible and you know, the manager sat in a little bigger cube at the front of the football field filled with cubes and he proceeded to try to woo me by telling me about this amazing project he had just worked on and how he had spent 18 months working on it and it was amazing. He had designed a hinge for a submarine door for 18 months. I couldn’t run out of there fast enough.
WAILIN: Troy had another offer, from a small software consulting firm in Boston called DesignOptions. He liked the vibe of that company much better than General Dynamics, but he realized he wanted to be in Chicago.
TROY: So I just turned to the only person I knew in the computer industry in Chicago, which was the person I’d bought our PCs from in the last two years, this guy named Michael. I told him the long story, I got this job at DesignOptions but I want to be in Chicago. Is there a DesignOptions in Chicago? And he says, “No, you should start one.” And I laughed out loud on the phone. And he said, “No, no, no, I’m serious. Why wouldn’t do it? You’re 21 years old, you have no mortgage, you have no car payments, no kids. You have the power of zero. The worst thing that could happen is you’d hate it and six months from now, you’d be 22, looking for a job. By the way, my company’s growing. I have four employees. I need a new accounting system. I’ve seen the work you’ve done in the last two summers. I thought I’d get a job cleaning up after this dumb college kid. I’ll be your first customer.”
WAILIN: Troy moved home and into his parents’ suburban basement. He had about a thousand dollars, which was well short of the three thousand dollars he needed to buy a computer. But he figured he would work on his clients’ computers. So he paid a visit to customer number one, MPK Computing.
TROY: I knock on Michael’s door. He says, “What are you doing here?” I said, “Well, I’m here to talk to you about your accounting system.” He said, “You mean my new accounting system? I just bought a Unix based one. It’s right here.” He had totally forgotten and he had gone out and bought an accounting system. So I lost my first customer before I was in business. It was definitely disappointing, but I wasn’t going to do this because I was going to write that one system. I was going to do this because I wanted to have a career in building things. You know, it was a very slow couple of months trying to get that first customer and the first customer came to me through — it was actually a friend of my parents, who we’re talking at dinner and said, “Oh, I have a friend who needs a computer system. You know, maybe Troy can help him.”
WAILIN: Troy’s first customer was a man named Ben, who specialized in doing payrolls for musicians. Troy bought a computer, wrote a custom payroll processing program, and delivered the computer with the software to Ben. Then he got a second job writing a program for an investment firm. That client had a bunch of PCs at their office, including one dedicated to Troy’s project, so he camped out at the investment firm and worked the same hours as the employees there. But it meant he couldn’t take on a second client. So he finally got his own computer. Once again, he went to Michael at MPK Computing.
TROY: January of ’87. I was probably three or four months in and bought what was an original IBM PC with a 20 megabyte hard drive, which seemed huge. Just to put it in perspective, so that would store three photos from my iPhone and it would be full, three photos. And it had a color monitor. I sprung for the color monitor. It was probably around $4,000 for all of that. That was a big leap because it was every dollar that I had made so far and it felt like a commitment. Now it’s not going from something like, oh I’ll do this for a couple of weeks or I’ll do this for a couple of — like, I’m gonna do this.
WAILIN: Troy’s next customer was a man named Larry, who had a business running auctions of rare classical LPs. Troy wrote a software program for Larry to manage his auctions, and from there, his technology consulting firm kept growing. Troy called it Specialized Systems and Software. He brought in a partner, a friend of his from high school and college, and moved out of his parents’ basement into his own office. Meanwhile, his old friend Michael’s business was growing rapidly too, and he renamed it from MPK Computing to Computer Discount Warehouse, or CDW. The company would later go public and hit a billion dollars in sales, and they finally became clients of Troy’s.
TROY: In 1992, so we’re six years into it, had about a dozen professionals, having a ton of fun, had just beat out Andersen Consulting, which became Accenture, for Hyatt’s worldwide purchasing system and we’re doing great. We’re having a ball. We had done probably 10 or 12 projects for CDW. We had done work for Abbott Labs, McDonald’s. And we liked the bigger clients. The bigger clients tended to be bigger projects, more money over a longer period of time, so it was easier to schedule and manage.
WAILIN: One of those bigger companies was Medline, a manufacturer of medical products like bedpans and hospital linens. Around 1992, they wanted to digitize their old paper invoices, so Troy went to the Medline offices in the northern suburbs of Chicago for a meeting.
TROY: It was in the boardroom at Medline, the big boardroom, and there were probably about 10 people around the table and I was up at the front, giving a little presentation to try to build credibility. And as I was doing it, I talked about how we had just completed Hyatt’s worldwide purchasing system. And the CEO of Medline, who was one of the founders, Jim Mills, stopped right then. And he pounded his fist on the table and he said, “You did purchasing for hotels? Well, then you could do purchasing for hospitals. Hospitals are just like hotels, only the people, they don’t feel so good.” And I looked at him and I said, “Well yeah, of course, I’m sure we could.” He said, “Okay, I want to hire you.” And I said, “Well, who do I talk to to write a proposal for the purchasing system?” He said, “No, no, no, you’re not listening to me. I want to hire YOU. I want you to come here, work for me.” And I said, “Well, I can’t. I have partners, I have employees, I have customers.” And he said, “Okay, then I want to buy your company. How much?” And I didn’t know how to respond. I looked at him and I said, “Well, it’s not for sale.” And he got angry. He said, “Everything’s for sale. Everything has a price, how much?” And we hadn’t contemplated any of this and we said, “It’s not for sale.” And so he asked me a couple of questions, how many people we had, how much revenue we had, and he made me an offer right there on the spot and I said, “Well, thank you, but we’re really not interested in selling.” And he stormed out and then his brother who was the president, John Mills, kind of followed him out and then a couple of the other people around the table, and there were two people left — and I wanted the business. I didn’t care if it was the business we came for, doing the invoice scanning system, or if it was doing this new purchasing system, I didn’t even know what was involved but I’m sure we could write it. But literally I was asking people, “Who do I talk to about this proposal?” And they’re like, “I don’t know, we’ll get back to you,” and I clearly had disrupted the entire meeting.
WAILIN: Troy went back to his office. That afternoon, he got a call from John Mills, the president of Medline.
TROY: And John said, ‘You know, my brother was serious. He really wants to buy your business.” And he made another offer and I said, “John, I’m really flattered. That’s really nice, but we’re not for sale.” And we really weren’t. We weren’t thinking about selling. I mean, we weren’t building the company because we wanted to build something and flip it. We were building the company because we were having a lot of fun. And then he called me back again the next day. He said, “You know, you’d be able to play in a much bigger ball field.” And I remember him, he said, “You’re playing in Little League now. I want you to come play in the major leagues.”
WAILIN: That pitch from John Mills caught Troy’s attention and finally, he and his partners decided to sell Specialized Systems and Software to Medline.
TROY: It was about loving what we do. It took a decent price and arrangement for us to decide to sell. So we would not have sold had it been a cash-only deal. Part of the attraction of selling was we got a lot more resources and we felt we’d be able to do more of this fun stuff, and so, you know, we went from 12 people to 55 people over the course of a couple years. John was right. We went from the little leagues to the major leagues in a very real way and that was as attractive, if not more attractive, than the cash.
WAILIN: Troy’s business, Specialized Systems and Software, became Medline’s software division, and he negotiated the deal so that they could retain an entrepreneurial feel. They had their own office, in a separate suburb from Medline’s corporate headquarters, and they got a share of the profits they generated. Troy stayed at Medline for five years. After that, he founded or ran a series of companies. More recently, he’s become an investor and a mentor to other entrepreneurs. He founded an accelerator program that’s like a three-month bootcamp with funding for Chicago tech startups. Today he’s managing director at MATH Venture Partners, a venture capital firm he helped establish in 2015.
TROY: When I started that first business, I had no idea what I was doing. I literally did not know a balance sheet from an income statement. What I was doing was going into businesses and asking lots and lots of questions. And when things didn’t make sense, I asked more questions and I asked more questions because I had to understand how the business worked in order to write a system that would support it. And in hindsight, I probably learned more running that very first business to set me up for what I do today — coaching and helping entrepreneurs, investing in companies — than anything else I could have done. Because I got to look under the covers. I got to see everything about how businesses worked. I saw their accounting, I saw their finances, I understood their processes and it was such an array of different businesses.
WAILIN: I know this isn’t a typical Distance story. We usually feature independent businesses that have been running for over 25 years. Troy’s consulting firm is long gone, having been absorbed into Medline in 1992. But I wanted to tell you his story because some of the software he wrote way back in the 80s lives on in two of his earliest customers. One of these business owners is Ben, his first-ever client, who specializes in doing payrolls for musicians.
TROY: A bandleader would have done a gig at a wedding and then would get a check for $2,000 and would call up Ben and say, “Hey Ben, I did a gig, it was $2,000. I want you to pay Joey $150, Mary $200, and the rest of it, you know, send back to me in a check. And they would send him the check for $2,000. He would do all of the payroll, the withholding, union reports, and whatever was left over, he got his fees out of it and he returned the rest to the band leader. He called it TEMPO and I forgot what TEMPO stands for.
BEN: The Equitable Musicians Payroll Organization.
WAILIN: The other business owner is Larry, who runs auctions of rare classical LPs.
TROY: Larry was a reference from…I don’t remember.
LARRY: I don’t actually know. I had to ask my wife. I knew it was through my wife and it was through an acquaintance of hers who simply heard that I was in need of a computer system for a small business, and he said in effect, “I know a guy,” and the guy he knew was Troy. I sell out of print classical recordings. I’ve been doing it since 1978, so in my 40th year now.
WAILIN: Ben and Larry started their businesses when Troy was a teenager, and they’re still running their companies on the software Troy wrote for them. In the case of Ben, who handles payroll for musicians, he’s even kept the same hardware.
BEN: Dot matrix pin feed, you know what that is?
WAILIN: We’ll be bringing you Ben and Larry’s stories on the next episode of The Distance, coming up in two weeks.
We just built our first software integration. Here’s why…
“Make it easy, make it a routine.”
This is one of our core beliefs at Know Your Company. If something’s a burden, no one will do it — including you. Especially if that “something” is feedback in the workplace. Asking for and giving feedback to your team has to feel natural, easy, and be regular.
Because of this, we built Know Your Company to deliver questions via email. Email is a universal tool, in many ways. Most people use it, and you typically don’t have to teach anyone how to use it. As a result, when you use Know Your Company, it doesn’t feel like you’re using a separate piece of software… It’s feels like you’re using email.
But what if a company doesn’t use email? Over the past few years, we’ve noticed more of our customers moving away from email as a means of communication. They’ll tell us, “Hey, we actually use Slack — we don’t use email anymore.”
I hear ya 🙂
In the spirit of making it easier to ask for and deliver feedback, I’m excited to share we’re releasing a Slack integration for Know Your Company.
Here’s how it works: If your company uses Slack instead of email, you can turn on our Know Your Company Slack bot. The Slack bot sends a direct message to each person when there is a new Icebreaker or question to fill out, or when a new question summary has been delivered.
Here’s what it looks like for a team member to receive a Know Your Company question in Slack:
This way, if your company doesn’t use email, Know Your Company can still be helpful tool for you.
I won’t lie: At first, I was resistant to the idea of building a Slack integration.
I was worried that pinging people in Slack to respond to a Know Your Company question was going to create too much urgency around answering a question. One of the beautiful things about Know Your Company is that we purposefully give you 24–48 hours to answer a question before publishing the answers and sharing them with everyone else.
So if you don’t want to answer right away, you don’t have to. You can take a day or two to think about your answer, say, to a question like, “If someone asked you to describe the vision of the company, would a clear answer come to mind?”.
However, the neat part of this integration is that we designed it as “ a soft nudge.” We’re not pinging people to answer the Know Your Company question directly in their Slack channel right away. Instead, the Slack bot merely prompts you to open a browser to answer a question, on your own time – so you still have a day or two to chew on an answer to a question (if you want!).
It makes things easy, while still maintaining the integrity of the product and helping people do what they want to do.
That’s the point, after all: You’ve got to make it easy.