If you've listened to the Working Code podcast for any period of time, you've no doubt heard me mention the fact that I work on maintaining a legacy platform at InVision. My role on the legacy team was originally focused on security, stability, and bug-related fixed. However, over the years, I've become increasingly aggressive about adding features and actively improving the legacy experience. This has caused no shortage of controversy both internally to the company, and more broadly within the Working Code community. In this episode, Adam plays Devil's advocate and gets me to justify a mode over operation that seems to be—at times—almost in opposition to my company's larger goals.
All that and more on this week's show:
... featuring these beautiful, beautiful people:
- Adam Tuttle → Website, Twitter, LinkedIn
- Carol Weiler → Twitter, LinkedIn
- Tim Cunningham → Twitter, LinkedIn
- Ben Nadel (that's me) → Website, Twitter, LinkedIn
With audio editing and engineering by ZCross Media.
For the full show notes and links, visit the episode page. And, be sure to follow the show and come chat with us on Discord! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. New episodes drop weekly on Wednesday.
Teaser Transcript via Amazon's AWS Transcribe
I was recently listening to another podcast in which someone mentioned using AWS Transcribe to generate transcripts for recordings. For funzies, I thought I would try to transcribe the teaser
The transcript doesn't add line-breaks or paragraphs (at least not in the one I generated); so, I have to add those in manually. Here's the text that AWS Transcribe gave me (with me adding line breaks and some slight adjustments):
One of the arguments that I used to get into with my manager - he would say that it's unfair to users that you build something on the legacy platform and then eventually they move to the modern platform and that thing isn't there anymore. And it's been hard for me to find a parallel where I can say that that reasoning makes sense.
You know, some of the metaphors or the analogies that I've used are franchises. Like, imagine that I was running a franchise and that franchise represents the legacy system. And my franchise was going to shut down in six months. And so then all the customers who came to this franchise location would have to start going to another franchise location. Would I spend those last six months not caring about my customers? Or, would I continue to find ways to innovate and and add value?
Like, oh maybe I can have free cucumber water or something; or, like four o'clock cookies at this franchise location. Does it matter if none of the other franchise locations have four o'clock cookies? Is that a reason for me to not do it?
I could just never come up with anything where someone could convince me that having to move users off of the platform was reason to not do anything for them.
ADAM: It's becoming very difficult for me to play devil's advocate because I feel like you're making a very strong case for your positions here.
So some of the frustrations that my co-workers have expressed to me are that I'm creating parity gap issues. Meaning that I'm creating features on the legacy platform that don't exist on the modern platform. And my counter argument to that is:
One, we've already done that as a company. We've already decided there are things in the modern platform that we don't want to replicate, regardless of whether or not people are using them.
Two, a lot of the times, it's probably not gonna be a problem because a lot of the stuff I build is crap. And, if I build it and it's crap and users migrate to the new system and they don't care that it's not there anymore, like no harm, no foul.
And three, I build something interesting on the legacy platform. People migrate to the new platform and then they freak out because hey, where's this nice thing that you guys built on the legacy platform, it's no longer here - that's really disappointing. And my perspective on that is that it's awesome because now, you know that users actually wanted it; and, how many times do we end up building something that users didn't want? And now you have users actually telling you that this is something that they want.
It took me like 10-minutes to add the punctuation and clean up some of the language mistakes. And, that's for a 2-minute clip of audio. It's a cool service, but definitely needs some manual loving.