Bonus points are earned for things that have ridiculous infographics and/or provide absolutely no source or methodology. Since I started my career by analyzing Census data, things about demographics are extra special catnip.
This is a fun game to play, but it’s actually a real problem. The bar for what passes as credible when it comes to data journalism is incredibly low. There are some shining examples of quality — FiveThirtyEight releases much of the data that goes with their stories, and some are advocating for even greater transparency — but the overall level of quality is depressingly low. It’s just too easy to make an infographic based on shoddy original data or poor methodology and publish it, and there’s little to no repercussions if it isn’t actually accurate.
Academia has been battling this issue for years under the banner of “reproducible research”. Peer review has been a hallmark of academic publishing since at least 1665, but it hasn’t solved the problem. Still, there’s awareness of the issue, and some efforts to improve it: training, policies requiring data release in order to be published, etc.
It’s easy to take shots at data journalists and academics for shoddy methodologies or insufficiently reproducible research because their work is public, but the truth is that those of us in industry are just as susceptible to the same flaws, and it’s even easier to get away with. Most analysis done for private companies isn’t peer reviewed, and it certainly doesn’t have the wide audience and potential for fact checking that journalism or academic publishing has.
I’m as guilty as anyone else in industry when it comes to being less than perfectly transparent about methodology and data sources. I’ve even published plenty of tantalizing charts and facts and figures here on SvN that don’t meet the standards I’d like to see others held to. Mea culpa.
I’m trying to do better though, particularly with what I share internally at Basecamp. I’m footnoting data sources and methodologies more extensively, doing more work in Tableau workbooks that show methodology transparently, including my analysis scripts in writeups, and trying to get more peer review of assumptions that I make. I’m fortunate that the Basecamp team trusts my work for the most part, but I shouldn’t need to rely on their trust — my job is to bring impact to the business through responsible use of data, and part of being a responsible data analyst is being transparent and reproducible.
It’s not the easiest path to work transparently or to ensure reproducibility. It takes extra time to explain yourself, to clean up scripts, and so on, but it’s the right path to take, both for yourself and for your audience, whoever they may be.
Today we’re excited to announce the latest addition to the Basecamp team: Jay Ohms joins us as our lucky 13th programmer. He’ll be working with our mobile team on Basecamp for Android.
Android enthusiasts will know Jay as the one part of the duo behind Press, the popular Android RSS reader. Press arrived at a time when great design was hard to find on the platform. Jay’s focus on quality and eye for detail made Press a favorite and caught our attention, too.
After spending a week working with our Chicago-based Android team on a trial project we knew Jay, who also happens to live in Chicago (did someone bribe an alderman?), was a great fit. Jay makes us better on Android and we’re excited to show you what we’ve got in store for 2015.
Everyone, Jay; Jay, everyone.
Did y’all know you can share stuff directly to Basecamp from apps like Paper? Resident illustrator, Nate Otto shows it off.
Nate Otto and I made a new Basecamp homepage illustration based on a vector drawing I made in Adobe Illustrator. Initially I didn’t intend it to be hand drawn. I thought I’d refine the vector drawing. Somewhere in the middle it turned into “herding cats”. In the end the spirit of the concept was intact, but the result very different from what I’d envisioned.
Here’s how we got to the final idea: Basecamp helps you wrangle people with different roles, responsibilities, and objectives toward a common goal: Finishing a project together. First pass: Basecamp is a central hub. All the things going into it are like train lines.
Train lines are pretty boring. What if it was about herding cats? Lemme put some vector cat heads on there.The vector style doesn’t fit with the rest of the site. I work with Nate on the idea of Basecamp as being the ultimate “cat herder”. Give the cats some human accessories…Jason Fried is concerned that “herding cats” may come across as insulting. The idea of herding cats may be lost on some potential customers. Maybe we should just be clear.Final: Let’s add all the people involved in the process.
This process took about one day of back and forth (in Basecamp) between me and Nate. So, that’s how we made the illustration for the idea: Basecamp helps you wrangle people with different roles, responsibilities, and objectives toward a common goal: Finishing a project together.
About five years ago I consciously willed an art career into existence. At that point I had been working a social services job for about five years. I initially took the job because it wasn’t specifically art related. It was a job I could feel good about — helping people with disabilities — but it wouldn’t tap my creative juices. I had learned many years before when I got a job doing graphic design that being creative at work drained my creative life bars during my down time. This social services job would leave me with enough creative energy to work on my art when I got home, but in reality that wasn’t really happening. Furthermore, the job itself was becoming a frustrating dead end. I had learned that working in a large organization with seven direct bosses wasn’t an environment in which I would thrive. What would my next move be? I was grown up and competent. I felt as though I could do pretty much anything.
Nearly 3 years ago we asked “What would happen if a truck crashed into the datacenter?” The resulting discussion could be summarized as “Well we would probably be offline for days, if not weeks or months. We wouldn’t have many happy customers by the time Basecamp was back online.” No one was satisfied with that answer and, in fact, we were embarrassed. So we worked really hard to be prepared with an answer that made us proud.
This past Sunday, February 15th 2015, we demonstrated that answer in public. With one command we moved Basecamp’s live traffic out of our Chicago, IL datacenter and in to our Ashburn, VA datacenter in about 60 seconds. Chart: Traffic Swapping Between Sites
Not one of our customers even noticed the change, which is exactly as we planned it. A few hours later we ran one command and moved it all back. Again, no one noticed.
This probably qualifies as the least publicly visible project at Basecamp. And we hope it stays that way. But if it doesn’t, just know Basecamp will be online even if disaster strikes.
(There’s much to share about how we accomplished this and what we learned along the way. I’ll share the technical nitty gritty in future posts.)
Of the many axioms in the world of software, few rise to the occasion of Thou Shall Not Rewrite Your Application. Spolsky called it the “single worst strategic mistake that any software company can make” in his seminal 2000 essay Things You Should Never Do.
The Big Rewrite has been likened to all sorts of terrible things, but perhaps the most damning is its association with declaring technical bankruptcy. Basically, the only time it’s reasonable to embark on the terribleness of the rewrite, is when you’ve been profligate cowboy coder. When your mountain of technical debt is crashing down upon you.
So it’s the white flag, then. It’s giving up. Capitulation! The error of your inadequacy has finally caught up and will be taking you to the cleaners. Who the hell wants to be that sorry sob of a programmer!?
No wonder programmers are loathe to question the wisdom of NEVER REWRITE. Either they’ll reveal their own morally deficient ways, or they’ll be seen as apologists for others traveling that deviant path.
Now, axioms develop for a reason. Many a rewrite has been started and gone astray for all the wrong reasons. Either it truly was a result of technical bankruptcy, or, perhaps even worse, it was a result of perceived technical bankruptcy by a new team uninterested in learning why things became the way they are. As Spolsky quips, such a rewrite is basically the same software with more and different bugs!
But there are other types of rewrites. The one most dear to me is the “Don’t Try To Turn A Chair Into A Table” rewrite. It’s the one we committed when we launched the new version of Basecamp a couple of years ago. A full, start-over, everything-is-reimplemented rewrite of Basecamp because we wanted it to do different things.
Yes, Basecamp Classic and the new Basecamp both juggle many of the same ingredients of project management and collaboration, but they’re mixed together in very different curations. So while we could have gotten from A to B one carefully tested refactoring and commit at the time, it would have been a fool’s errand.
Starting over allowed us to question the fundamentals of how the application worked and how it was implemented. We were able to make leaps, not just skips.
A chair can indeed be turned into a table with enough effort. Both have four legs, and all you need to do is chop off the back of the chair, and somehow refasten it to the base to extend the surface. Oh, and maybe some new wood to raise the legs up higher. It can be done, but why on earth would you?
So we decided to leave the chair alone. People were using the chair, and still are – years after the new table premiered! And we got to build a beautiful new table that’s been serving us so very well for the last couple of years.
That’s really the bottom line here: We rewrote Basecamp from scratch and it turned out great! Better than great, actually. We got to leave well enough alone for people who had adopted and grown accustomed to Basecamp Classic, we got to offer a brand-new product to new customers that was the very best we knew how to make, and we got a greenfield codebase to enjoy as well. Plus-plus, would do again!
So what am I saying here? Rewrite willy nilly whenever you get blue over seeing a few modes of progress made cumbersome because of poor past decisions? Of course not. Embarking on The Big Rewrite is not a choice to be made lightly, but a choice it remains. It should be one of the options on the table.
If you’ve accumulated enough fresh ideas about how your application can be radically different and better, The Big Rewrite may very well be just what the carpenter ordered.
Whenever I dive into something new, I try to find at least one “why the hell not?” moment. And when I can, I try to leave evidence of that moment in whatever it is that I’m building.
When we launched our company (37signals) back in 1999, we launched a black and white, text-only site without a single piece of portfolio work to be found. All the other agencies we were competing with had very flashy pages, loaded with pictures of their work. So why black and white and text only? Because why the hell not lead with ideas rather than compete on pictures? We thought it could be better that way. It worked out well for us.
One of my favorite why the hell not moments was when we were writing REWORK. One of the things that always bugs me about paper books is that you have to leaf through a dozen or so pages before you arrived at page one of the actual text. You’ve got the testimonials, the table of contents, the dedication/acknowledgement page, the copyright page, usually a blank page, a title page, etc… THEN you get to the book. This is also one of the reasons I really like cracking into a new book on the Kindle – you start right at the text.
So when we were talking to our publisher about how we wanted REWORK to be organized and designed, I asked them if we could put the copyright page at the end, rather than the beginning. It would be one fewer page to leaf through up front, and if any page was ignored more than the others, it had to be the copyright page. So why the hell not just put it at the back?
Initially our publisher didn’t know how to respond. No one had ever asked that before and they’d never seen an example of a copyright page in the back. But ultimately they said yes, so today if you pick up a copy of REWORK, and go to the last page, you’ll find the copyright page right there in the back of the book on page 280:
You’ll also find the acknowledgement page on page 279, rather than right up front:
Whenever I’m struggling with a decision that seems “unusual”, I’ll look back at these two pages in REWORK and remind myself that just because everyone else does something one way doesn’t mean you have to do it that way. Sometimes it’s just worth saying why the hell not and going for it.
I watched in disbelief as the robot crashed into the mission model. It had run the exact same mission hundreds of times during practice. We never worried about this step; it was always successful. It was “dial-tone” reliable. We had practiced on multiple tables, under different lighting conditions, trying to chase out any strange bugs that might be lurking in our assumptions.
The Jet Team member in charge of the table grabbed the robot and put it back in base; extremely frustrated. With the clock running and the parents and other teams cheering; they had little choice but to try it again. Unfortunately, the previously rock solid mission was now failing as often as it was previously succeeding. It crashed into the mission model again. Once more, they incurred a 10 point touch penalty and brought the wayward robot home. Hands quickly and deftly replaced the attachment on the robot with the one for the next mission while the other team members yelled, “Skip it! Go to the next mission!” from the sidelines. 8 seconds later, the robot trundled out of base again, leaving 125 points unclaimed forever in the past, on its way to the next mission.
After the timer expired and the buzzer sounded, the team members collected the robot attachments and we made our way off the arena floor, mingling with the 7 other teams leaving the other tables, having experienced their own trials or triumphs over the last 150 seconds. Some kids looked to me for answers, utter confusion plain on their faces. “Mr. Anderson, what happened? Why did we miss the black line?!” Others looked at their teammates, “It never missed there before, did you load the right program?”
We were at the 2014 Kentucky State FLL Tournament. 47 teams had fought their way here through various regional competitions and we were all competing for a chance to go to the FLL World Festival in St. Louis.
JET Team at 2014 Kentucky State First Lego League Tournament
My mind raced back over the program they had written; I could see exactly where the program had been when it failed, but even if I knew the answer, I couldn’t tell them. Coaches don’t program in First Lego League; they shouldn’t even touch the computer or the robot. The temptation is too great to just “fix that that one thing”. So as we walked back to the pits, I fell back to my favorite activity; asking them to describe what they saw, not what they thought the robot did. Slowly, they talked each other through what happened, and the kids started to zero in on the problem.
The kids had written a line following program that would stop when the robot detected a certain reflected light intensity. It was pretty complicated, but they were very proud of it; and it worked very well. Without getting too technical, the robot measures a light intensity between zero and 100, zero being black, and 100 being white. Their program was instructing the robot to stop when it saw zero. There was no margin for error, and when the robot saw black as 1 (or more), it happily continued on its way, waiting for the magical zero measurement that would tell it to stop.
“Bump it up to five!” “Yeah, tell it to look for 5 or less!” Modifications were made, and the program tested once. We had another run coming up in 10 minutes, and had to get back to the arena. The kids looked hopeful as we walked back, confident they had fixed their issue and were going to put a respectable score on the board at last.
As the robot jerked to a stop at the beginning of the line it was supposed to follow, one of the team members looked at me. “It detected the green line as black, and stopped too early!” Resisting the urge to remind them again that the robot had no concept of “too early” and it just did what it was programmed to do, I nodded. Inside, I was ecstatic. They had seen the behavior of the robot and deduced the problem right away!
The sensor the robot uses to measure reflected light intensity uses a red LED. This leads to interesting effects when measuring the reflected light intensity of different colors. A good analog of this is the spy decoder devices that used red cellophane to reveal the hidden messages. Red shows up as white, and green is almost black. In bumping the value up to 5, they had inadvertently strayed into the “green range”.
This time, as we walked back to the pits, I didn’t have to ask anything as the team member who saw the problem explained what happened to the rest of the team. Various theories flew as to the best way to fix it, ranging from “rewrite the program” to “put it back the way it was”.
When we got back to our pit, rather than race back to the computer and start coding a fix, I had them talk through the observed behavior and the proposed solutions. Taking the ten minutes to talk about it, and analyze their options and situation proved far more valuable than spending those moments hacking at the code.
In the end, they decided they didn’t have time to rewrite the program, but they also couldn’t put it back the way it was with any confidence. Since they had bumped up to five, they decided to split the difference at two. They all agreed it was their best option under their time constraints.
3rd Table Run
The last run, due to their perseverance in tracking down this new bug and their acceptance of the time constraints they were operating under, turned out to be their best. Was it bug free? Nope. Did they get all of the points they hoped for? Nope.
Did they complete their problem mission? Yes!
Did they learn a little bit more about engineering, software development, hard deadlines, and deploying hot-fixes to production? Yes! After their last run, I had the opportunity to draw parallels between everything they had gone through during the last few hours and what we, as software engineers, do on a daily basis.
“I’m so exhausted!” exclaimed one of the team members, “I’m just mentally exhausted!”
“Congratulations on your first production deployment!”, I said. “They get better. Testing and practice are the best way to make them less exhausting, but they’re always exciting!”
In the end, we scored third place overall. No trip to the World Festival, but I got something better; I got to see the team become engineers.
In honor of The Distance podcast’s debut, I asked Basecampers what podcasts they’re currently enjoying and collected the responses. In some cases, you’ll see a recommendation for a particularly good episode to check out. (Basecamp is also sponsoring several podcasts, including Nerdette and Bullseye, which are mentioned below.) As I was compiling this list, I felt like I was naming every podcast in the world. But it’s just a sign of what a long and interesting tail there is in the world of audio. Here’s to discovering new things! And as a bonus, you’ll find recommendations for podcast apps at the end. Be sure to add your suggestions for any great podcasts (or apps) we’ve missed in the comments.
Business/Tech/Design/Productivity
99% Invisible: Shaun calls it “probably the best podcast about design out there.”
Accidental Tech Podcast: Marco Arment, maker of the iOS podcast app Overcast (and many other things), is one of the co-hosts.
Girl On Guy: The winsome Aisha Tyler chats with her guy friends.
How Was Your Week? with Julie Klausner: Author and performer Julie Klausner talks to smart and interesting people. Joan recommends this episode, which she says “contains a rant about Annie that is particularly amazing.”
International Waters: Yanks and Brits face off in a comedy pop culture quiz show.
The Adventure Zone: The McElroy brothers of My Brother, My Brother and Me (see above) play Dungeons & Dragons with their dad. Joan recommends Episode 2.
The Attitude Era: A look back at the World Wrestling Federation during the late 90s.
All Songs Considered: Jason Zimdars calls this show “the best place to hear about new music if you’re no longer 25.”
Bullseye: A pop culture show that’s also distributed by NPR.
U Talkin’ U2 to Me?: Adam Scott of Parks and Rec and Scott Aukerman of Comedy Bang! Bang! talk about U2.
We Hate Movies: James says this show is about “entertainingly terrible (but not terribly entertaining) movies torn apart by nerds.” Also, James has his own podcast about life in Berlin!
Wham Bam Pow: Movie reviews focused on sci-fi and action films.
Who Charted?: The latest in music and movies, featuring Los Angeles comedians.
