You might have heard that Jason Fried and DHH have a new book out called It Doesn’t Have to be Crazy at Work that pushes back against the toxic culture of overwork and unhealthy ambitions that’s driving much of the modern workplace. In the latest episode of the Rework podcast, I sit down with David to talk about the book’s genesis, its intended audience, and the role of responsible software design in fostering calm work environments.
The second part of this interview will air next week. In the meantime, we’re taking your questions for David and Jason to answer in an upcoming mailbag episode! Leave us a voicemail at (708) 628–7850 and you’ll be entered into a drawing for an autographed copy of It Doesn’t Have to be Crazy at Work.
A while back we bought a duvet cover from Brooklinen based on, of course, a glowing Wirecutter review. We’ve been happy with it (it’s super comfy!), but sometime in the last couple months the teeniest, tiniest of holes appeared in it.
This wasn’t a big deal, but this tiny hole could eventually turn into a big gaping tear sometime in the future, so I wanted to get it fixed up. Thankfully, Brooklinen offers a lifetime warranty.
I sent them an email with a few details, and with zero fuss we had brand new replacement duvet sent to us for free. And on top of that, they told me to just keep the torn one so I didn’t have the hassle of shipping it back.
And with just that one small interaction, they’d secured me as a customer for life. The product is great, their service was outstanding, and the prices are fair (especially given how they stand behind their products). Why would I even bother shopping around in the future when they’ve done right by me in every way?
In absolute terms they lost a bit of money on this single transaction with me. But beyond the short term, they’ve setup potentially thousands of dollars of future sales from both me and word of mouth goodwill. I know I’ll be back for sure.
On the flip side, I recently ordered a couple pillows from Tempurpedic. They’re a well known brand in the bedding space and on the high end of the price scale.
I honestly didn’t think much about their warranty and return policy when I bought the pillows. I had just come off the Brooklinen experience and just kind of assumed a high-end brand like Tempurpedic would be as good if not better on the customer service front.
I gave the pillows an honest shot for about a week, but they just weren’t for me. There was nothing defective or wrong with them, but I found them uncomfortable. I decided to return them.
Wups! Their return policy clearly states that they don’t accept any kind of returns on pillows.
Now to be clear, this is 100% my fault for not checking the return policy before buying. And this also isn’t a product defect. They are well within their rights as a company to have a policy like this to protect their business. Objectively I have no problem with any of that.
But subjectively I was surprised and a little irritated. It left a bad taste in my mouth, especially coming off the Brooklinen experience and knowing they have a far more generous return policy (as do Leesa, Casper, and others in their industry). Surely they could be more lenient with this policy to take care of their customers?
Now could I have emailed them and finagled my way into a refund? Yeah, probably. But it hardly seemed worth the effort. From just reading their policy, I got the feeling — right or wrong — that emailing with them was probably going to be a huge pain in the ass. I didn’t bother.
All said and done, I doubt I’ll ever buy another Tempurpedic product again. I wasn’t really happy with the product and on paper the company didn’t seem to really care if I was happy. Why would I ever support this company again with my dollars?
They landed $80 from me this one time, but it sure seems like they missed out on a long-term relationship with a customer.
At Basecamp we try to be ultra-clear about our refunds. Yeah, we’re not making multi-thousand-dollar physical products, but treating customers the right way and making them happy is our golden rule.
And beyond what our public policy says, there is a singular philosophy that we follow when helping out customers at Basecamp: if you have even the slightest doubt on what to do, just do right by the customer. The trust and respect we gain by making a customer happy — even if it means “losing” a few bucks today — is immeasurably more valuable in the long run.
A famous guy once said, “Pay no attention to that man behind the curtain!” But he was a grifter. In fact, going behind the scenes — whether it’s a factory tour or cooking show — can be a valuable experience for both visitors and guides. In this episode, we crash a middle school field trip to the Method soap factory on Chicago’s South Side. We also hear from Basecamp’s CEO Jason Fried on his YouTube series on making design decisions and from the managing partners of Zingerman’s Bakehouse in Ann Arbor, Michigan on why they don’t believe in secrets.
If you leave a comment, be sure to tell us whether you prefer yeast or cake donuts!
It’s our first mailbag episode! Jason Fried and DHH answer listener questions on topics like the role of luck and timing in starting Basecamp; how they approach pricing (spoiler: It’s something called “ass pricing”); hiring in the early stages of a business; and more.
We’ll have Part 2 with even more questions next week, so be sure to subscribe to Rework via Apple Podcasts, Google Play Music, or your favorite podcatcher so you don’t miss it.
If you have a question for Jason or David to tackle on a future mailbag episode, leave us a message at 708–628–7850. We’re also collecting stories about meetings for a future episode. I heard from someone whose CEO held monthly 8-hour Skype meetings. Yes, they were eight hours long (with only two breaks under 20 minutes each) and consisted of him reading aloud some Google Docs. Do you have a similar story? Or—shudder—one that tops a recurring 8-hour Skype call? Call us or send an email to firstname.lastname@example.org.
Ben and Larry are longtime owners of two different music-related businesses, a payroll service for musicians and an auctioneer of rare classical LPs. They don’t know each other, but they have something in common: They’re both still running their businesses on custom software written in the 1980s by the same developer. This episode features the soothing, nostalgic hum of a dot matrix printer, variations on “Three Blind Mice,” and more!
WAILIN: Do you remember your first computer? Ben does. He got his first computer in 1986, when he hired a programmer to write some custom software for his business.
BEN: I was frightened beyond reason and little by little, I got the hang of it. Those computers at that time were just old DOS machines.
TROY HENIKOFF: It was a Compaq desktop, and the reason it was a Compaq was because the IBM PC ran at 4.77 megaherz, but the Compaq ran at 6 megaherz. So it was original Compaq with a 20 MB hard drive in it and an amber monitor. The amber monitors were the best. They were better than the green ones.
WAILIN: That’s Troy Henikoff, the programmer who wrote the software that Ben started using in 1986 — and still uses today. Welcome to The Distance, a podcast about long-running businesses. I’m Wailin Wong. On the last episode of The Distance, you heard about how Troy ran his software consulting business for six years before selling it to a big corporation. On today’s show, you’ll meet two of Troy’s earliest customers who are running their businesses on 30-year-old software.
TOM: The Distance is a production of Basecamp. I’m Tom, 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.
BEN: I’m a musician and 95 percent of my tax clients are musicians: Chicago Symphony, Lyric Opera. I’ve worked for local orchestras. They wanted someone who can work on musicians’ tax returns, who knew the types of deductions they would be able to take, and by word of mouth I got another phone call, another phone call, another phone call, and I got all these clients.
WAILIN: Ben, who asked that we not use his last name, has a one-man business in the Chicago area doing payroll and taxes for musicians. He estimates he’s been doing this for around 45 years, but he doesn’t remember the exact year he started his business. It’s called Tempo, which stands for The Equitable Musicians Payroll Organization. When Ben got introduced to Troy via a friend in 1986, he was about a decade in and using a typewriter.
BEN: People kept asking me, “Why are you doing this? Why don’t you get a payroll program? Why don’t you get a computer?” I didn’t have anything. I just used a typewriter. They told me that Troy graduated from Brown with an engineering degree and he’s going into IT so I gave him a call.
WAILIN: At the time, Ben also owned a currency exchange in Chicago and Troy went there to meet him. He was Troy’s first customer.
TROY: So I had never been to a currency exchange, and the currency exchange, of course, has bulletproof glass, but you have to be able to get behind the bulletproof glass and they have a thing — I think it’s called a gang door. Apparently, this is to prevent like a gang of people from rushing the back of the, of the currency exchange. There are actually two doors and the space in between the doors is only big enough for one relatively slender human, and the first door has to be closed before the second door is physically able to open. And so he’s trying to explain to me that I’m gonna go into this gang door in order to see him and he’s yelling through the bulletproof glass, “Go over there! Open the first latch!” And then I get in and then the door closes and you’re totally claustrophobic. And then I sat down with him in the back of this currency exchange and he’s helping customers and then he’s interrupted and he’s trying to explain to me about union reports and W2s and 1099s and I knew nothing about any of it. But he just gave me a bunch of sample reports and said, “Look, it has to look like this.” And I asked a lot of questions and if you ask enough questions, you start to understand. I laid out a system for him, gave him a quote, and went back and programmed it.
BEN: He set up a program on DOS, MS-DOS, before you were a gleam in your mom’s eye. That’s when I started to use it and it was marvelous.
WAILIN: Not long after doing the job for Ben, Troy was introduced via a string of connections to another customer with a business called Polyphony.
LARRY JONES: I’m Larry Jones and I sell out-of-print classical recordings. I’ve been doing it since 1978, so in my 40th year now. I think anybody who begins selling things to collectors began as a collector him or herself. I don’t know why else you would do it. I began collecting classical recordings in my mid teens and by my late 20s had a fairly substantial collection.
TROY: Larry had a very interesting business. So most of the businesses that we were writing software for in the early days were businesses that were very unique, where there wasn’t something off the shelf that would help them accomplish what they needed to do.
Larry started Polyphony with just a typewriter and a record collection in a small office. Several times a year, he would print up catalogs and mail them out. Customers mailed back their bids, indicating how much they were willing to pay for the records they wanted. Larry would then figure out who had the highest bid on each item, fill out invoices for the winning bidders, collect payment and mail out the records.
LARRY: It took off very nicely. There was a lot of demand for these things at that point and a lot of responses to advertising in various musical publications and I developed a clientele. Iit was profitable from the start. This was my very first catalog, miserable little thing here. How many items were on this one? 265.
WAILIN: By the time Larry met Troy, around 1987, the Polyphony catalogs had gotten much larger. But Larry was still running his auctions with pen and paper. He showed me a file for the last one he did before getting a computer.
LARRY: 2,600 items on this catalog. This graph paper lists every one of them. At the end of the auction, I have circled the winning bidder and his, his or her, although it’s usually males, also on graph paper, it’s very well organized, you see? This was back in the day when I had 700 people bid on that catalog, nothing like that anymore. But! Then, that’s what I had to do is go back to somebody’s bid sheet. I fill out which ones they were successful on and which ones they were not. Here’s a total, a subtotal, a postage fee and a grand total, I mail that back to them with a return envelope and they send me a check. That is what ended up being computerized a year later, and it was just night and day. It knows who bids what and it figures out who won what for me. I hit a button that says create invoices and there they are! It’s just spectacular compared to what I was just showing you.
WAILIN: The new software meant that Larry no longer had to sit hunched over a piece of graph paper, writing down bids from hundreds of people and scanning the sheet to figure out who won what. The program also digitized his inventory so he could search his collection more easily and spend less time recording information for each new LP that came in. With the time savings, Larry could run six auctions a year instead of four.
LARRY: Well, it was just a matter of volume, really. They asked me at one point, maybe a year or two in, could I quantify how much this had sped up my process. And I think even at that point, I said it had doubled my speed, and that was really before the inventory had kicked into the point where it was recognizing thousands of things.
WAILIN: Ben and Larry were satisfied with their software — so satisfied, in fact, that neither of them wanted to upgrade, even as MS DOS started to become obsolete. They would get new computers over the years, and today Larry runs his program on a virtual machine on his Macbook Pro, where he presses a button and the display switches over to the vintage blue screen of his DOS program. But neither Ben nor Larry were interested in new software. That’s what they told Troy when he called to check in, sometime in the late 80s or early 90s.
LARRY: I heard from Troy saying, “You know, we’re not gonna be writing DOS programs anymore. Windows has taken over, so this is your last chance for any changes or anything you want to do.” I think I asked him at that point, “Does it make any sense for me to go to Windows?” They said, “We can’t retrofit this. You’d have to start from scratch and it’d be very expensive.” I was like well, why would I change something that’s working just fine as it is and getting faster every time there’s a new upgrade with respect to hardware speed?
BEN: He said, “Listen. I can’t run your program anymore because we’re switching up to Windows and DOS is no longer going to be a very popular item. It’s going to be very expensive if you want to switch, and I wouldn’t blame you if you didn’t want to switch because I know you know the thing inside and out and you’re so comfortable you could do it in your sleep,” and he was right. So I kept doing it and I hadn’t seen him for maybe 15 or 20 years since then until my printer broke down.
WAILIN: In those 15 or 20 years since Ben and Troy last spoke, Ben had kept going with Tempo, his payroll business, while playing clarinet and saxophone on the side. Troy had sold his software consulting firm to Medline, a big manufacturer of medical products, and become a venture capitalist and mentor to tech startups. But earlier this year, Troy got a call from his first customer.
TROY: Ben called me frantic. And he was frantic because his checks weren’t printing right. And he couldn’t really articulate for me what was wrong, but they weren’t printing right and when I tried to ask him, he just got, he got a little bit flustered and he said, “You have to come over.”
BEN: The printer broke down and I couldn’t make a connection and I was out of business for God knows, about a month. So I called him, you’ve got to help me, I’m in terrible shape here, so he came over.
TROY: And it turned out that it was really just a simple hardware problem. He had a combination of a printer that was 30 years old and the tractor feed wasn’t feeding very well, so he needed a new tractor feed and a switchbox — those old mechanical AB switchboxes to switch between printers? Those wear out after time, and so the switchbox wasn’t working. I had an old parallel printer cable that I knew worked and we connected it directly and everything worked. We ordered him a new switchbox, got him all set up. Oh, it was amazing to see it still running. I mean, to see the text screens of the DOS and to hear the printer printing,
WAILIN: Ben actually has two dot matrix printers. I asked to see them in action, so he fired up Troy’s program on his desktop and filled out a sample check, made out to my name.
BEN: 2017 is the year, and then I go to banking. And my password. And there’s today date…and Wong. Save the above check, yes. Press P to print the check. That printer selector is marvelous.
WAILIN: In the bottom right corner of the check, there’s a musical staff with Ben’s signature overlaid on it, a little visual flourish that Troy programmed into the printer itself back in 1986.
TROY: When we wrote the program, he didn’t like having to sign the checks manually. It’s an OkiData printer and it had this graphics mode. I learned about it and I made it so that the printer it actually prints his signature using the dot matrix graphics mode, which I’m sure no other company ever supported, and so if he can’t find a replacement OkiData printer, he’s gonna be out of business. Like you can’t just run that on anything. This is running in MS DOS and so even if his computer dies that he’s running it on, it will be difficult to find a computer that we actually can still run MS DOS on. While it’s great that it’s been running for 30 plus years, it’s a little bit risky at this point.
WAILIN: Ben’s not too worried. He’ll probably retire within the next couple of years, and he’s stocked up on both ribbons and paper for his dot matrix printers. He found the ribbons at Office Depot.
BEN: I bought a whole case of it because I knew that eventually I was going to run out. It’s right down here, take a look. And here’s some ribbons. For example, I have some extra ribbons for the Epson, which is that one there. Here’s some mouthpieces for the saxophone, and I have other ribbons for this one.
WAILIN: Larry is getting ready to retire too. He’s had a good run, continuing with his auctions even though he estimates the market for used classical recordings peaked in the mid 90s. He’s been paring down his inventory, getting rid of the items he knows won’t sell.
LARRY: There was a very famous — famous among the aficionadi, but not well known otherwise — Russian conductor named Nicolai Galavanov who made some very obscure recordings in the early 50s that were available at that time really only on very hard-to-find imports. They were not regularly distributed in this country. And when I began, if I had a collection or someone had managed to get ahold of some of these things, they were very, very valuable, even crummy Russian pressings which were not frequently very good. So I found a group of these in a collection that I acquired, maybe 10 years ago, and I was real excited because I hadn’t seen very many of these things. But then I thought, I wonder if these things have been digitized? My wife has Spotify and I said I’ll type this guy’s name in. They all had been digitized! Unless you really want a poorly pressed Russian record from 1955 because that is exciting to you in and of itself as the object, you’d rather listen to a nice digitization of it on Spotify, you know? So that’s the sort of thing that’s happened in classical music. Subsequently, it got to the point where I was buying a record collection, I was donating or discarding two thirds, three quarters of it because it simply had no value in the current market. And that’s very much the case now. The market is very, very narrow and very quirky. But I still get a huge kick out of it. I still go into somebody’s basement and look at a couple thousand records and it is just very exciting. Maybe I’ll see something I’ve never seen before.
WAILIN: As for Ben, he loves playing music, which is what he wanted to talk about instead of his payroll business. Ben’s father played violin to accompany silent movies, and after the advent of the talkies, switched to playing clarinet and saxophone in an ensemble for weddings and bar mitzvahs. Ben learned clarinet and saxophone too, and found his passion.
BEN: I was drafted into the army. I auditioned for the Army band and played in the Army band for two years in Fort Carson, Colorado. See, this is much more interesting than doing payrolls!
WAILIN: What year were you in the Army?
BEN: ’57 to ‘59 — that’s 1857. So then, one day I was in the band room and there was no one in there and there was a piano in there and I didn’t know anything about piano, so I sat down and I kind of played with the keys and everything and I realized, my God, I found myself playing Three Blind Mice. And then as I was sitting there, I started making variations on it and I’ll play it for you.
TAPE — LARRY — When I was 28 years old or whatever, the notion of doing anything 40 years later was completely so far beyond the horizon that I don’t think I had any concept of it. If you had asked me, is there something else that you want to do? Is there something you would prefer doing, I don’t think I ever felt that way, no. I like what I do. I liked it and I like it.
The Distance is produced by Shaun Hildner and me, Wailin Wong. Nate Otto does our illustrations. Big thank you for Troy Henikoff. He put me in touch with Ben and Larry, neither of whom he had spoken to in a while, and I’m very appreciative of him making those connections so we could get this fun story done. You can find The Distance on Apple Podcasts, on Google Play Music, Stitcher, or wherever you find your podcasts. We’re on Twitter. I’m @VelocityWong, Shaun is @shildner, that’s S H I L D N E R, and The Distance the podcast is @distancemag, that’s at distance M A G. The Distance is a production of Basecamp, the app for helping small business owners stay in control of projects and reduce email clutter. Try Basecamp free for 30 days at basecamp.com/thedistance.
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.
Today I was chatting with someone looking for opinions about project management software. It would have been easy to weigh in with a list of reasons why that person should try Basecamp.
But what if that isn’t the right way to help them?
Instead, I offered the following list of questions that I use when trying out something new. The answers to those questions might lead her to Basecamp, they might not.
What problem am I trying to solve? How does this help me get there?
This question is an old friend. A constant companion as I muddle my way through life. What am I trying to do? Do I know? Child questions spawn, dragging me closer to an imperfect answer that works for now. There is something powerful about the way asking a question reveals flaws in my understanding, or illuminates new avenues to explore. The beautiful thing is, behind each answer I find more questions.
Am I looking for something to help me do my work, or am I looking for something to change how I work?
How often do you really challenge the underlying assumptions about why you work the way you do? Picking up a new piece of software, or looking at a new process is a great time to pause and reflect. Are we doing this because it’s the right thing to do, or has it “always been that way”?
Does using this result in better work? How do I measure that?
This is one of the child questions that comes from asking what problem I want to solve. How am I going to know if making this choice is worthwhile?
Not all complexity is anathema. Taking something complicated and turning it into something simple is a noble endeavour. Deciding not to do something is incredibly freeing. And yet, there is a place for complex processes, if they make life better at the end.
Does using this save me time?
This doesn’t do X. Does that matter? Could we do without?
When considering a move to something new, I often catch myself discounting a product because it doesn’t do something I’m used to. I’m trying to get better at ignoring that impulse, and being more open to changing how I work.
Are there any questions I’ve missed? Do you have a personal favourite you ask when looking at a new piece of software, or a new way of working? Let me know!
At Basecamp, we’ve got so many questions, and we’re having a blast trying to find the answers. We love questions so much, we built automated questions into the latest version of Basecamp. If you are looking for a calmer way to work, why not grab the questions above, and see if Basecamp 3 is the answer?
In a perfect world all of your servers are hard-wired to each other in a room. There would be one opening with which the world connects to your little slice of the Internet. That way all of your cross-service communication into databases, infrastructure and other services happens within the single set of servers all directly connected.
In the modern world we often have to reach across the Internet to access services and applications. This can be an awkward feeling and presents some unique problems. However, there are a few techniques and patterns you can use to make it a little less frightening. Let’s talk through some of the bigger concerns and what you can do about them.
One big reason reaching across data centers, even for first-party systems, can be an issue is the matter of security. There’s a base level of security you lose sending data and commands across the Internet where anyone can glance at your requests and try to decode the data or alter what’s being sent. All someone needs is a basic understanding of networking, attack techniques like Man-in-the-middle and perhaps Wireshark to unpack your cross-service request, see sensitive data, tinker with the request and send an altered request to the final destination. Fear not, however, there are some standard techniques to mitigate this risk:
Always communicate over SSL when you’re sending requests back and forth over your systems. This is a straightforward, standard way to secure communications between two services or entities on the Web. Under the hood, SSL uses Public/Private Key encryption to secure the body of a request between two entities. Reddit, Facebook and all of your financial institutions use SSL (HTTPS) to communicate with your browser, and likely when they communicate between internal services. Its become far easier and cheaper (free) to get SSL for your services as well thanks to organizations like Let’s Encrypt.
2. Request Signing
While communication over SSL is somewhat secure, it can fail. Or perhaps you don’t need SSL to prevent snooping, but you do want to ensure the data wasn’t tampered with. At Highrise we decided to utilize a drafted standard that is being worked on currently under IETF, which outlines a method for signing a request. This means you can use an encryption algorithm and set of keys that you configure to define a formal verification for the content of your request. Let’s say I want to ensure that the Digest, Authentication and Date headers were specifically never altered. By following this protocol I would: Set up the request, retrieve the signature (using signing keys) for the specified headers, add the signature to the request and execute the request. This standard allows for specifying what keys you used to sign the request (via a KeyId parameter), which headers were signed, and which algorithm was used to do the signing. The recipient server can use this information to verify the contents of those headers were not altered during transport. The details of this freshly forming protocol go a fair bit deeper and are worth understanding. There will be a followup post directed at this topic shortly.
These two protocols give us a stronger confidence in the things being sent over the wire to other services.
Speed of accessing external services due to network fluctuations as well as actual downtime are facts of a cross-data-center world. Obviously, both types of issues can compound themselves and start making whole services virtually unusable. You often won’t be able to stop these things from happening so you have to prepare for them. Let’s talk about four mitigation techniques:
1. Local caches, Avoid making requests
Caching or intelligently deciding when to request across services can cut down on the number of actual requests you need to make. Things like eTags can help with this as well as expiration headers or simply not requesting data unless you absolutely need it to accomplish your task. If the thing didn’t change from the last time it was requested let the client reuse the data it already has.
2. Timeout Retry
I mentioned earlier that slow responses from external services can create a compounding problem for your system. You can mitigate this risk by planning for it to happen and wrapping specific patterns around your communication. Specifically, set reasonable timeouts when you make external requests. One problem with timeouts is that you can’t tell if it ever reached the server. So you should plan to make your endpoint idempotent whenever possible. Idempotent endpoints make retries simpler as well, since you can just keep hitting the endpoint and expect no unexpected change. Finally, you maybe should slow down rescheduling the request to give some time for a system to recover or avoid hammering the service. This is called exponential back-off.
At Highrise, certain important requests have a timeout like 1 second. If the request fails it will be retried 3 times before it stops trying and starts messaging our team about issues. Each time it will schedule the job to retry further out: 3 seconds after failure, 9 seconds after failure and 27 seconds after failure, because of the exponential back-off algorithm. In cases where something is, for instance, sending an email via an external request, idempotency is a very serious concern so that you avoid sending the exact same email 3 times because of retries. You can accomplish something like that with a key that the server uses to decide if that operation has already been accomplished.
3. Circuit Breakers
Circuit Breakers paired with timeouts can help you both better handle full-service degradation and provide a window for recovery. A Circuit Breaker basically lets you define a set of rules that says when a breaker should “trip.” When a breaker trips you skip over an operation and instead respond with “try again later please,” re-queue a job or use some other retry mechanism. In practice at Highrise, we wrap requests to an external service in a circuit breaker. If the breaker trips due to too many request timeouts, we display a message to any users trying to access functionality that would use that service, and put jobs on hold that use that service. Jobs that were in-flight will presumably fail and be retried as usual. A tripped breaker stays tripped for several minutes (a configured value) and thus keeps us from hammering a service that may be struggling to keep up. This gives Operations some breathing room to add servers, fix a bug or simply allow network latency to recover a little.
Upchecks, Health-Checks and the like are very useful to get a basic understanding of whether you can reach a service. Libraries standardize some of this for you so you don’t have to think much about what to provide. Really what you want is to understand whether you can reach the service and if its basic functions are operational. Upchecks paired with a circuit breaker can help decide whether to show a maintenance page or to skip jobs that won’t work at the moment. These checks should be extremely fast. At Highrise for our first-party, external services we check once on each web-request for the livelihood of a feature about to be accessed. Again let’s say we have an external emailing service. If someone goes to the email feature we wouldn’t check at each email operation, in the code, that the service is up. Instead, we would check at the beginning of the web request if the email service is up. If it is up continue to the feature, if it isn’t display a basic “down, please try later” message.
Act like it isn’t yours
When it comes to external services, even if you wrote it, you have to act like you have no control of it. You can’t assume any external service will always operate normally. The reality is you have limited control, so you have to design a system that explains issues to your users as they happen and mostly recovers on its own. Protect what you can control and avoid requiring humans to repair issues like this. The more your computers can recover on their own, the more you can worry about the next feature, the next user or the next beer.
I’m a Software Engineer at Highrise (@highrise). Follow me on Twitter to tell me what you think, as well as find more ramblings about Software and the world by me @jphenow.