Archive for category: Technology

It took only eleven minutes on an otherwise ordinary Thursday to set off the latest internet firestorm. A Twitter support agent took advantage of his last day at the office to briefly disable the controversial personal account belonging to one Donald J. Trump, who just so happens to be the current president of the U.S.

Earlier today @realdonaldtrump’s account was inadvertently deactivated due to human error by a Twitter employee. The account was down for 11 minutes, and has since been restored. We are continuing to investigate and are taking steps to prevent this from happening again.

— Twitter Government (@TwitterGov) November 3, 2017

Those eleven minutes triggered the typical polarized reactions. A large swath of the internet celebrated that an account with a long history of bullying and sharing falsehoods was suspended; another substantial group, on the other hand, felt vindicated in their assertions that the tech companies are inherently against them.

The truth, of course, is far more banal than either group would like to believe: an employee with particular views took advantage of his or her access and the opportunity afforded by their impending departure to make a political statement they believed in.

Twitter the company did not intend to take any particular action or stance on Trump's Twitter presence that day, and while you can debate whether or not they should, the actual discussion online and in the media seemed to focus on what support agents can and should be able to do.

It is shocking that some random Twitter employee could shut down the president's account. What if they instead had tweeted fake messages?

— Blake Hounshell (@blakehounshell) November 3, 2017

Many of these betrayed a lot of confusion about what support agents at these companies are able to do, and most of the rest tried to prescribe solutions that made this seem like a simple problem.

I spent over five years working at Microsoft on OneDrive, which, as a document and photo storage and sharing service, had to navigate these problems regularly. While I don't pretend to be an expert, I learned that these kinds of decisions, about what a support agent can and should be able and encouraged to do, are some of the toughest conversations you'll have in a company whose business revolves around user-generated content. So let's talk about why this is so hard.

A few weeks ago I hit my six-year anniversary at Microsoft. In that time, I've worked with several teams building web services inside the company, and I've built a network of decent size at many of our peer companies. I've learned a lot about software engineering, both from my own experience and that of my peers. In all this time, perhaps the biggest thing I've understood is this: pretty much every engineer who works on a software project of any complexity hates their codebase.

Talented engineers faced with market pressures make tough choices that almost miraculously result in shipped software. It's well understood that those choices add up at a micro level as technical debt, and most great companies have figured out mechanisms for improving individual components over time. But it's harder to account for—and correct—choices that add up at a macro level.

Architectural debt is the sum of those macro-level choices. It affects every piece of your code base, and is usually the result of decisions that were made years ago. Importantly, those decisions may well have been the right ones at the time, both from a "getting to market" perspective and from a "right technical choice for this moment in time" perspective.

However, because it affects so much of your codebase, it's dramatically harder to revisit architectural debt, and the decisions that made sense once upon a time evolve into an albatross around the neck of the people who have to deal with them now. This is the source of the codebase hatred that pervades among engineering departments at companies; they are weighed down by two major factors:

1. The architectural debt has started affecting every aspect of their day-to-day work: everything takes a long time, functionality is fragile, ownership and accountability is hazy, etc.
2. The codebase is so large that making any real impact on the problem seems like an insurmountable challenge.

Back in the early days of Web 2.0 exuberance, all the hot new online services (Flickr, Delicious, and even Twitter) built largely open APIs and encouraged developers and customers to build mashups: fun but fleeting ways to juxtapose data from multiple sources on a single webpage. These companies seemed to believe that enabling people to create new and unexplored tools on top of their data would produce magical, unexpected innovation that would make the entire platform richer and ultimately accrue benefits to them. For a time, nearly every consumer startup seemed to launch with an API ready to go, even if their company didn't yet have enough usage to make developing on that API worth people's while.

Unfortunately, as the early mashup excitement waned, these companies figured out they had to earn money and exert more control over their platform. Watching Twitter stumble drunkenly through that process has been particularly entertaining, but the gradual falling into disrepair of many other companies' APIs may ultimately be worse for the web community as apps break and the features of the product diverge from the features of the API.

In recent years, though, a different approach to APIs has emerged. Companies like Twilio and Stripe are rehabilitating the idea of an API from the legacy of failed late-2000s startups and going "all in": the APIs these companies provide are not just important, but the core product that each of them sells.

These companies have figured out two fundamental things about APIs:

1. The best APIs aren't for your product but for a problem.
2. You must put as much effort into the user experience of developers who want to use your API as you do in all the other elements of your product.

According to TheKnot, a popular wedding planning website, the average cost of an American wedding in 2014 hit the mind-boggling number of $31,213 (though their numbers include the cost of the engagement ring). Any event with a budget to the tune of 30 grand inevitably becomes a complicated planning endeavor, with hundreds of tasks and projects, all of which add up to piles of cash leaving your wallet.

One of the big expenses that figures into that sum is a wedding planner, which isn't surprising: for many people, their wedding is the most complicated project management exercise they'll ever be involved in. I, on the other hand, consider project management one of my professional competencies. As my fiancee and I work to plan our wedding, I've found that we've been able to apply many of the tools I already knew and loved, and those tools have allowed us to reduce our stress levels, minimize our own amount of work, and save a good bit of cash.

While we looked at the fancy "official" wedding tools (like TheKnot itself), all of them seemed to have some fatal flaws. They make assumptions about what you want to do with your wedding and subtly encourage you to do more than you might care about (and therefore spend more money). But the biggest issue with common wedding planning tools is this: they assume one person (generally the bride) is handling all the wedding planning, and offer minimal opportunities for collaboration. Frankly this is just antiquated nonsense in 2015, so we rolled our own. Here's how.

If you keep up with the tech industry's latest social fads, you might have seen a new app blow up this week: Meerkat. The iOS-only video streaming app enables users to trivially kick off a live broadcast of whatever they may be doing, and share it with their Twitter followers.

On Friday evening, only a short while after the app began to draw hundreds of influential users, Twitter pulled the plug on Meerkat's access to their users' social graphs, preventing the app from drawing on people's existing networks of Twitter followers. Given that this comes as Twitter works to rebuild developer trust, it's a controversial move, especially in light of the announcement that Twitter has purchased a Meerkat competitor.

Given that Meerkat can still freely and automatically post to Twitter otherwise, it seems that Twitter has taken this stance primarily for competitive reasons, and I'm not entirely comfortable with Twitter becoming protective of the parts of my social graph that happen to be in its system today. While an outright block is probably too harsh a measure, I think Meerkat runs the risk of running afoul of Twitter and undermining its own growth for another reason entirely: the app is a prime polluter of Twitter timelines.

It's time for me to confess a deep, dark secret: when it comes to software, I can sometimes be a bit of a hipster.

When I was in high school and into college, I frequently went out of my way to use different software just for the sake of not using the typical apps my friends were using. In the world of IM, I might have used ICQ, AIM and MSN as the protocols, but it never took me long to jump away from the official apps: over the years I used Miranda, Pidgin, Trillian, etc. much more often than actual MSN Messenger, AOL Instant Messenger and ICQ clients. I spent nearly a year using MEPIS Linux as my primary OS on a mildly-antiquated laptop. And of course, I spent about a decade using Opera as my main browser, a fact that got me consistently mocked at Microsoft.

Towards the end of college and especially when I started my job at Microsoft, though, I found myself jumping full force in the opposite direction, going out of my way to use the official Microsoft apps like Photo Gallery, OneNote and of course OneDrive. (I still used Opera until they decided to give up work on their own rendering engine and switch to Chromium.) I also bought in to the Microsoft ecosystem, using Windows Phone as my primary OS and an assortment of Windows-based PCs–mostly Thinkpads–over the years.

Ironically, sticking to "the man" during that period was actually somewhat hipster in its own way: as Apple gained success with iPhones and iPads and Android began its spectacular growth, most people weren't buying Microsoft-based devices, and as a consequence weren't having the same computing experience I was. So in spite of my convergence to the safe, no-one-got-fired-for-buying choices, I was yet again in the minority.

On the eve of my five year anniversary at Microsoft, I found myself increasingly out of touch with what most of my peers were experiencing in their day-to-day computing life. I had never owned an iPhone (though I'd had the occasional experience with iOS through iPods and iPads), and I hadn't used an Android phone since the very early, very painful stages of that OS. I hadn't used Mac OS on a primary computer in about five years. Instead, I was quite familiar with Windows, Windows Phone, and–all hipster-like–Palm's tragically doomed WebOS.