"The Least Disruptive System"

Travis — Fri, 17 Dec 2021 17:35:41 +0000

My freshman year of college, I took a Systems Analysis class. It was by far my favorite class. The college I was attending did not have a Computer Science program (it was 2000, computers were still a novelty apparently), but was in the process of creating one. So I majored in Political Science and took the two “technology” courses available to freshmen. One was “Computer Skills”, which really should have been called: “Learn the Office Suite¹.” The other was Systems Analysis.

When I look back on all the computer science courses I took, it’s really hard to pinpoint any single lesson I learned from them. I’m sure I learned a lot and still rely on that knowledge today, but nothing sticks out in my memory the way that Systems Analysis class does.

There’s one lesson in particular that I reflect on a lot. It’s a lesson I don’t think I truly understood how to apply until later in my career, but one that I now think about every time a new request comes across my “desk.”

The Midterm

For the midterm, we were split into groups and the professor give us a business problem to analyze. The assignment outline was straightforward: 1) define the problem, 2) develop a solution, 3) implement a proof of concept. The last instruction of the outline was:

“Your task is to develop the quickest to implement, least disruptive, and most cost-effective system to solve the businesses problem. You will be graded on these three criteria.”

Every group failed the midterm.

The Problem

The business was an automotive scrap yard, “Buddy’s Scrap Yard” (I don’t remember for sure if that was the name, but it sounds good). Buddy kept his inventory in a large paper ledger. Each line in the ledger was a part in his multi-acre yard. When a new part came in, he updated the count in the ledger or added a new line. When a part when out, he did the same. Buddy didn’t use or have a business or personal computer, everything was on paper.

Once a month, Buddy had a “Pick your own part” day. People would be able to wander around the scrap yard and pick any part they wanted and pay a reduced rate for the part. Because the reduced price, these “Pick you own” days were very popular and accounted for a sizable portion of Buddy’s income. But with the increased volume, Buddy was unable to update the inventory ledger in real-time and his ledger was always out-of-date. He was losing regular business because he was never able to be certain if he had a part he promised a customer.

The Wrong Solution

My group’s solution was to develop a software inventory management system. Each part would have a barcode. Parts could be indexed by multiple facets. The yard would be split up into zones so that each part was easy to find. For the “Pick your own part” days, additional staff would be hired to help customers find parts, pick them from the yard zone and scan the parts during checkout to update the inventory. We built a prototype in Microsoft Access. All of the other teams proposed a similar solution.

Least Disruptive

We had all missed the most important part of the assignment outline: “least disruptive.” Everyone in the class was interested in technology. Almost everyone knew how to code. Everyone loved computers. We all read the problem and immediately thought: “How can software solve this problem?” None of us considered how disruptive a software solution would be to a company that only used paper and didn’t even own a computer. Sometimes the unintended cost of the best solution makes it the wrong solution.

It was a strong lesson in thinking critically not only about the problem but also your solution. It’s something I try to remind myself every time I build something new. Am I solving the right problem? Do I understand what the problem is? Have I considered what my solution will cost the user? Is my solution the least disruptive to the current system?

It’s hard to keep Buddy in mind when developing a solution. Throughout my career, I have often forgotten this lesson. I’ve built the solution that I wanted, the one I found interesting or mentally challenging, instead of the least disruptive solution. It unfailingly creates more problems, more work, takes more time, and leads to more burnout.

The “Right” Solution

The solution our professor proposed was maddeningly simple. Paper tags, a card catalog, and Buddy’s existing ledger. A card with a unique number would be affixed to each part. An index card with that number and a location of the part in the yard would be filed in a card catalog and an entry would be added to the ledger with the number a description of the part. Every time a part was taken out of the yard, the index card would be taken out of the catalog. On “Pick your part” days, the tags would be collected throughout the day and Buddy would update the card catalog at the end of the day. The least disruptive system.

¹ When we got to the FrontPage part of Office, I got a D on my website design project because I refused to build it in FrontPage. I wrote it in HTML like any sane person. I was furious. I went to my professor and protested. He said, “you didn’t do the assignment.” When I asked how he knew I didn’t use FrontPage, he said: “The website looks too good. You can’t do that in FrontPage.” Well worth the D.

10 years ago, one tweet from @ConanOBrien changed my career

Travis — Wed, 11 Mar 2020 21:45:02 +0000

One tweet, 10 years ago today, by @ConanOBrien changed my professional life in the most amazing and unexpected ways.

// Detect dark theme var iframe = document.getElementById('tweet-10326418664-429'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=10326418664&theme=dark" }

I remember that day vividly. Conan was going on tour and I had been asked to build a site to accompany his social media presence. The initial plan was for Conan to tweet a link to the site at 9:00 am. I spent the night before running performance tests, optimizing the server, projecting traffic based on his social following, and mentally preparing for the next morning.

Back then it was just me in my apartment. I was the lone developer and did all the ops work myself. I wasn't overly concerned or worried about the launch. I had spent the past three years at Yahoo!, working on sites with hundreds of millions of pages views a day. I was confident I had planned accordingly.

// Detect dark theme var iframe = document.getElementById('tweet-10327747292-249'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=10327747292&theme=dark" }

It... didn't go as planned. Conan ended up tweeting at 7:21 am (not that it would have made a difference if he had tweeted at 9 am). Luckily I had woken up at 6:30 to go for a bike ride and caught the tweet before I left my apartment.

The site had crashed almost immediately after the tweet. Turns out I had the right capacity for our projected traffic, but I was a bit off on the projected traffic. Apparently, people were more interested in what Conan was up to during his "television hiatus" than I though.

// Detect dark theme var iframe = document.getElementById('tweet-10331814436-829'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=10331814436&theme=dark" }

I spent the next few minutes franticly spinning up more servers, getting them into rotation, and restarting servers as they failed. After about 20 minutes, things leveled off and the site was stable. I spent the rest of the morning glued to my monitor, watching the logs, tweaking Apache and making sure nothing else went down.

Later that day, I heard from Team Coco. I was terrified I had ruined the launch, torpedoed the tour and they would never want to work with me again. It was the exact opposite; the tour was close to being sold out, Conan enjoyed the "exiting rollercoaster" of his first big website launch and the team was excited to begin work on the next iteration of teamcoco.com.

Over the ensuing ten years, I have had the privilege of launching several successful projects (none of which crashed on day one) for , build out a full cloud infrastructure, digitize and release Conan's full late-night archive, win two Emmys, worked with some amazingly talented people and watch Team Coco grow into the powerhouse it is today.

...and it all started with a tweet!