098: Experience First Development

This Frontsider panel episode explores what virtues go into making quality software, such as having tests, making sure software is performant and accessible, and why you should try to avoid technical debt.

Transcript:

CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 98. My name is Charles Lowell, developer here at The Frontside and your podcast host-in-training. With me today, we’re going to have a round table, a Frontside round table. With me today is Elrick.

ELRICK: Hey.

CHARLES: Joe.

JOE: How you doing?

CHARLES: And of course, Will.

WIL: Hello, hello.

CHARLES: Welcome, y’all. We’re going to be talking today about some of the things that we do around here, aside from trimming the shrubs and making coffee and snacking on Altoids. Like, way too many of them. Yeah. I was thinking we could talk a little bit about software qualities of relative things, like this software has these qualities. And I think that that kind of lofty goal of software quality is comprised of having a bunch of little qualities. The quality of having fewer bugs or the quality of having these things. And so, talking about all these things that we do and kind of what we do to make sure that we continue to do them. Or the ways that we can ensure that our software has these things. So yeah, we can just start really anywhere.

WIL: Yeah. So, one core thing is obviously tests.

CHARLES: That kind of falls under we want to have – really, there’s two qualities there that we want, right? Is we want to have…

WIL: Maintainable software.

CHARLES: We want it to be maintainable. We want it to be resilient to change. And we want it to work properly, right? Yeah, so we put tests in place to make sure that that happens.

JOE: Tests also inform design in a really positive way. A lot of the time, anyway.

WIL: Another thing that we like to include in our apps is responsiveness.

CHARLES: Yeah. And just making sure that you have – that it works on a multiplicity of devices, right?

WIL: Yeah. And not just the devices, but browsers as well.

CHARLES: Yeah. And it turns out it’s actually really hard to do that after the fact.

WIL: Right.

JOE: Yeah.

CHARLES: Making sure that lots of browsers, lots of devices. Because yeah, sometimes you have some weird screen width that is on some weird device, and making sure that that works. I guess there’s some overlap with testing there, too, isn’t it, right? Like you want to be running your tests on those devices at those resolutions to make sure that they’re going to work. This is something that we aspire to but I don’t think we’re quite there yet. It was making sure that our applications are accessible.

WIL: Yeah.

JOE: I’m very excited to learn more about this as we get into this, yeah.

CHARLES: Right, right. And asking the question, how is it that we actually can ensure our applications are accessible? We have very paved roads for making sure that our applications are resilient to change and that they have low bug rates and that they’re well-designed via testing. But what is the analog of testing for accessibility? What’s the way that you can put those guardrails in for accessibility? I have no idea. And that’s an ongoing conversation here at Frontside.

JOE: So, I guess I’m curious as to what technologies are actually involved in accessing a web application in – would it be reasonable to say a non-traditional way? I know there’s such things as screen readers, but is that all we’re talking about? Or what is the ecosystem that we have to consider supporting?

CHARLES: I’m certainly not an expert on this. We’d have to get Rob in here to chew our ears off this.

JOE: Yes.

CHARLES: But from what I’ve picked up from him and from our conventions with Marcy Sutton and some other folks that we’ve had on the podcast, it’s a big umbrella. So, it’s anyone using an application in a non-traditional way. So, whether that can have to do with limited vision, hearing, movement, range of movement, cognitive ability, it’s a gigantic whale of a domain.

WIL: Yeah. The topic of accessibility can definitely be several podcasts on its own.

CHARLES: Yeah. One thing that we’ve talked about is it would be great if you could drive your test suite through a screen reader or something like that. What would that even look like? There are a couple of open source ones out there, but they’re Windows-only. I think it was NVDA was the big one. And then you have a screen reader that then drives the applications in your operating system, so it’s going to vary per operating system. So, making sure that it’s accessible on Windows, at least as I understand it, is very different from making sure that it’s accessible on a Mac.

JOE: Yeah, it’s like a whole other layer. And it’s like BrowserStack outside of the browser.

CHARLES: Right.

WIL: There are things that you can do from the beginning that will make it easier when you get to that point. It’s just like using semantic HTML, knowing when and how to use proper aria labels. All these things, if you do it from the beginning, it’s not as big of a task as bolting it on afterwards.

CHARLES: Right. And I think we do have a leg up when it comes to web applications. It’s within our power to change. There are cross-platform of those technologies. But as you said, it’s important to put them in from the beginning. Because as we’ve seen, for each one of those categories, you’re accumulating debt if you don’t address it. So, there’s technical debt. But I think that technical debt can [inaudible] into a bunch of different areas. So, there’s technical debt in terms of the internal quality of your architecture, the way your software components talk to each other. And I think that that’s what people mostly think of when they talk about technical debt. But I think in terms of responsiveness debt, there’s a slice of the technical debt pie that has to do with making your application responsive. And so, if you don’t address making your application responsive, you’re accumulating debt and you might not know it. And if you’re not making your application accessible, then from the beginning you’re accumulating debt. So that if you have to go and try and figure out your accessibility story six months, a year, two years, you might actually uncover and say, “Whoops. I’ve been swiping the accessibility credit card. And holy crap, with all this. All my fines and penalties and compounded interest. Now I’m accessibility bankrupt.” And that can be scary, right?

WIL: Yeah. And a lot of people don’t realize with all this debt after the fact is they think they’re going in and adding things like responsiveness and accessibility and tests. But really, you’re also taking away previous work that’s already there, things that need to be refactored. If you put these things off, you’re not just adding a few hours of time. You’re inflating your time exponentially.

CHARLES: Right. Right, exactly. It can be intimidating but I think it’s also empowering, because technical debt is like a scary subject. But if you’re like, “Oh, we can actually slice our technical debt into a bunch of different categories and address them individually,” just knowing that this is an area where debt can accumulate, that’s half the battle. Because the worst thing is debt you don’t even see.

ELRICK: Yeah.

WIL: I mean, [inaudible] is big. That’s a big part of accessibility, that, is most people don’t think of accessibility. So, that is a huge debt that a lot of companies don’t see.

JOE: What about something like internationalization where I feel like I’ve never been in an application where that wasn’t punted on to some degree. That’s kind of a well-known problem, but it still takes a back burner. Do you think that if accessibility had more exposure as a concern, would it actually get the attention it deserves or is it kind of destined to, “Oh, we’ll get to those yaml files later. We’ll send those off for translation later,” that type of thing.

ELRICK: I don’t know. Sometimes I feel as though people feel as though they’re trading speed away when they’re building applications when they go to implement these things. Like, “Okay, well we’re not really going to touch on these right now because that’s going to slow us down from pushing out features.” Which is not really true. Because if you don’t settle on these things early, you’re not really building a solid foundation for your application in the long haul. So, I think people are like, “Oh, we’ll just do it later.”

CHARLES: Right.

ELRICK: And, “We’ll just ship features now.”

CHARLES: Right. I think that’s exactly right. It has this kind of secondary effect where not only do you develop the debt but you develop a culture of accumulating debt, right? Like when it comes to people getting a hold of their finances, the first thing that they have to change is they have to change their spending habits. And that can be the hardest thing. It’s not just balancing the equation. It’s like saying, “I need to readjust my thinking about this.”

ELRICK: Yup.

CHARLES: So that I’m not consistently put in this situation again.

JOE: So, there’s an operative word there, right, in personal finance in that usually if a company is addressing technical debt especially down the road, something that they’ve punted on for a while, it’s far from personal. There’s a board of directors or there’s a special interest group involved. There’s people who want features that are putting money into it. There’s a lot of pressure as the company grows and more people are involved. Priorities are more likely to be lost, I guess.

CHARLES: Are you saying it can be hard when your culture is spread over that many people, it can be hard to shift?

JOE: Absolutely, yeah. And I guess to keep with the dash-first thing, ideally were we starting a company, we would want to start a culture for this company. A culture that recognizes the vulnerability that we all have to technical debt as applications grow. We want that upfront. But the reality is, you know, startups are eager to get things out. Companies that have been around for a long time have high-paying clients that they depend on that want certain things. And yeah, I guess I’m just saying that it has to come in from the beginning.

CHARLES: Yeah. And I think that – I don’t want to completely disparage technical debt entirely, because technical debt like actual debt, like financial debt, is a powerful tool that you can wield. But it’s also, it’s like a table saw. You can also easily slice your finger off. It doesn’t mean that it’s not a useful tool, right? If anyone’s bought a house, it’s really great that you can borrow money to buy a house. It’s great that businesses can borrow money and get small business loans to get bootstrapped. And that benefits us all to have that community. I don’t think that – yeah, startups definitely, they need to have technical debt as a tool that’s available to them. But they just need to understand the consequences of it and be able to get a hold on it.

JOE: That’s a super interesting take. I never considered it that way before.

CHARLES: Yeah. It’s definitely not my take. I actually think the person who coined the term ‘technical debt’, that was the original idea. But then people realized that technical debt can also get way out of hand.

WIL: It’s just like real debt. If you’re not paying down a certain amount every so often, it’s going to keep growing.

CHARLES: Yup. You’re going to have to declare bankruptcy at some point and throw out the piece of software if you don’t pay a down. And that’s going to be more expensive.

ELRICK: Yup. That’s definitely true. So, I have a question. And we see this all the time repeating itself at various companies, whether it’s a startup, a large company, where they put off testing and mobile-first, user-first, accessibility-first. Like all the firsts, they just toss it to the side. Why do you all think that that happens so frequently?

CHARLES: I think it comes into people not understanding that if you don’t address it from the start, it won’t happen naturally. There is a prime motivator that has to happen. If you don’t imbue something with those qualities when it’s tiny, when it’s a tiny seed, a tiny crystal, you’re going to have to drill through layers and layers and layers of core to put it at the crystal to begin with. I like to think of software as kind of like a tree. And we eat the fruit of the tree, and that’s the features that users use. And we can tell that a fruit is delicious merely by placing it in our mouths. And we can tell what fruit is bad. But we can’t really look at the fruit itself to say what caused this fruit to be good, what caused this fruit to be bad. We have to look at the tree. And I think that that’s what people miss when they’re developing software, is that what you really want to do is you want to build a tree that builds good fruit. You can’t just take the fruit off the vine and say like, “Hey, I’ve got this peach but it doesn’t have enough sweetness. So, I’m going to take a syringe and I’m going to inject glucose around it and make it less tart.” You say, “I want a sweet fruit,” right?

ELRICK: Yeah.

JOE: You could probably actually do that.

CHARLES: You could. And that might be a strategy. And we see a lot of software that has those qualities of, “Oh, we’re going to make this accessible,” or, “We’re going to try and make this beautiful.” I happen to think that pigs are adorable animals and look great in lipstick. But that [laughs]… you could put lipstick on a pig but people can tell. And you can say, “Oh, this peach needs to have softer fruit,” and you can whack it with a mallet to actually make the meat more tender. But people are going to be able to tell. So, what you really need to do is you need to care for the peach tree rather than worry so much about the fruit. Because if you have a healthy tree, then you will have healthy fruit, right?

ELRICK: Yeah. So, you want to plant good seeds.

JOE: Yeah.

WIL: Back to you question, Elrick, about what motivates startups and other companies to put off these things. I think the biggest thing is just time and money. They have this misconception where they’re saving a little time and saving a little money now just to add it back later. But in reality, it’s going to cost them tenfold time and money for adding it later, versus just spending that little bit of time and money and all that to begin with.

CHARLES: That’s true.

JOE: It could also boil down, as far as just personal intimidation. Not so much like a business side of a thing but maybe just, think of all of the things that you listed, Elrick. It was almost a dozen dash-firsts in there. If you’re sitting down at a startup that you started with three friends and just approaching these things for the first time, that’s a lot to tack on right upfront. It’s intimidating.

CHARLES: It is intimidating. I think my message to those people is I’ve felt intimidated by that. I think my message to those people is like, the nice thing about it is if you attack those, if you tack all of those things from the get go, the features will take care of themselves and feel more effortless as you go on. You say like, “Oh, well actually, I don’t worry about a high rate of bugs.” I want to say recidivism, but that’s not the right word. A high rate of return, not on money but on – or high rate of bouncing your users. You don’t want that. And if you bake that in from the beginning, parts of the software development cycle that were stressful before just aren’t stressful anymore. So, if we say, “We want to have a system that is easily maintainable, well let’s put that in from the very beginning.” We say that a lot. We deploy to production on day one. But what that means is, we say we have this value that we want the system to be easily maintainable. And so, we’re going to do it from day one. That means that we actually – it’s not something that we worry about so much on down the road. Whereas that used to be very stressful. I don’t know. I remember when I started my career, there were these long release cycles where every six months, you’d release software. And the last month was just absolutely terrible as you try to stand this thing up and get it into production and then realize it’s not monitored. There’s no one checking the health of this thing. So, it’s pissing off users at one in the morning. And…

WIL: Beepers.

CHARLES: What’s that?

WIL: Beepers.

CHARLES: That’s actually a great – there’s a story there. The one time I got a beeper, I went canoeing in the canals of London and I tipped over my canoe and I dropped both my cellphone and the beeper that they’ve given me.

ELRICK: What?

CHARLES: I never got put on pager duty again.

[Laughter]

JOE: I’m going to use that next time [inaudible] with an on-call position. That’s a good move.

CHARLES: I remember, I definitely remember how sour my manager’s face was when I turned [inaudible] the cellphone that was like, dripping with water.

JOE: He was eating bad fruit, probably.

CHARLES: Yeah. [Laughs]

So, the other thing is we like to build beautiful applications, right? So, you have to – that match the user experience. You have to spend that time on design and beauty upfront. You will not have a beautiful application after the fact. You just need to bake it in.

ELRICK: And accessible design.

CHARLES: Exactly.

ELRICK: Don’t forget that one.

CHARLES: Don’t forget that, right? A responsive design.

WIL: Yeah, accessibility-first in design. Yeah, responsive and all that starts in design phase, yeah.

CHARLES: Yeah, all that, right? So, you want a great experience. You want an accessible experience. You want a responsive experience. You want a quality experience. You want a performant experience. That’s another quality that you say. Like, “We’re going to make sure that this is performant.” If you want that – and that’s something that we’re not always great about, right? We don’t actually put in benchmarks for our software from the get go. But maybe we should. But there’s perhaps a hidden cost there that we might be actually accumulating performance debt that we don’t even know about.

JOE: That’s true.

ELRICK: Interesting.

JOE: So, things that pop up that are new. Like, accessibility wasn’t probably always a thing in computing. Internationalization probably wasn’t always a concern. Beautiful certainly wasn’t a concern if you look on Wayback machine. You will see that to be true, right?

[Laughter]

JOE: So, all code is tech debt, I would argue. Or at least has the potential to be. And yeah, as the ecosystem as a whole evolves, being responsive to that, having plasticity in that respect, sort of like meta-first.

CHARLES: Right.

JOE: That could be the real challenge.

WIL: Yeah, Charles is mentioning all these experience things. And so, I was thinking X-first is simply experience-first. You want you users to experience a certain quality of your app. That experience needs to start in the conception phase.

CHARLES: Yeah.

ELRICK: That’s true. And even your developers coming in, developer experience.

JOE: Yeah.

CHARLES: Right. And I think the core of that X-first, that experience-first, is you need to pick which experiences. Because you can’t have everything.

JOE: Right, yeah.

CHARLES: One, there is going to be too much. You have to say, “I’m going to sacrifice on knowing that this is a performance thing. I’m not going to include that in the core DNA of my application.” And there’s just going to be things that you don’t know about yet that are just unsolvable problems or that don’t necessarily work. And you can say, “You know what? Hypothetically, I’m not going to make this an accessible – I’m not going to focus on accessibility.” But then you need to own that. And you need to know that you’re accumulating a huge amount of debt around that. And then I think that is a particularly bad trade-off because someone’s always going to come along and you’re going to have to know that your application is accessible. I think once we clamp down on that, that’s going to be something that we have a strategy for and we include at the beginning on every single application, right?

ELRICK: Yeah.

CHARLES: But I think you need to have, almost like holding the cards in your hand, say, “These are the cards. These are the X’s that I’m going to have in my hand. And they are going to be core to my app.” And they’re going to be part of the DNA of that tree. So that I know that the fruit is then going to have those qualities.

JOE: And then you as an engineer, that goes through an iterative process as well. Just starting out, you have no idea what that DNA should look like. And short of learning from people who are wiser than you who are around you, and reading blog posts and whatnot, really the only way to know the pain of strong-arming internationalization for instance into a 15-year-old Perl application, is to go through it. And then, you know, future trees will not have this DNA.

CHARLES: Right. Right. And that’s the other thing. Is if you are going to include, if you are going to try and splice something into the DNA, there’s a lot of work. And you just need to go for it. You acknowledge that it’s going to be a lot of work. And you need to, you just need to own it and go for it. And pay that expense of actually getting it deep, deep, deep into your application’s core values. So that then, you don’t have to worry about it anymore. Otherwise, you’re going to be paying – you’re just basically signing up for a lifetime of debt. Right?

WIL: Yeah. And then to make the debt analogy even more, it’s like people don’t understand the total debt. The end debt. People get a $30,000 loan with a 4% interest and they think they’re paying back that $30,000 loan. But really, they’re paying back $36,400 after all the amortization of their interest. The debt is higher than you can see, always.

CHARLES: Right.

WIL: And it’s true in tech debt, too. React is the new hot thing now, but in 10 years we’re going to be on React debt that we’re migrating away from.

JOE: I hope so.

[Laughter]

CHARLES: Maybe less, I think less than 10.

WIL: Yeah. The debt is always there. And people don’t realize how much they have to pay on top of what’s visible.

JOE: Yeah. It’s an invisible vig.

CHARLES: What’s a vig?

JOE: It’s interest, in the mafia.

CHARLES: Oh.

JOE: Sorry. Yeah.

CHARLES: I forgot you’re Italian.

JOE: Yeah.

ELRICK: So, for people that are listening, they might be in a situation where they need to advocate to the powers that may be these X-first values. What do you all think that some of the approaches that they should take to say to whomever it is that, “We need to do this first”? Because there’s times where you might say, “Hey, we need to do this first,” and people just look and say, “Oh, maybe not.” Then you need to push back on that.

CHARLES: In my experience, I find that the tech debt argument is a good one. Because I think it can be, it’s both limiting and empowering. Because sometimes it really is the right call to pull out your credit card and put something on it. If you need to buy water and you need to buy food and you don’t have any other means, man, put it on the credit card. Right? Seriously. Even if you have no idea how you’re going to pay it back. Like, whip that sucker out and stick the chip in. And it doesn’t matter how much it costs. And so, sometimes that is the right call. But I think draining it of a moral or a value as a human person thing, and approaching it from a business decision and saying, really trying to attach a cost to it. Because then I think if you can drain out the emotion of it, because people really want something. They’re striving to go get it and trying, give them tools to think about it rationally. That I think is a good strategy, to just say, let them know that there is a debt that’s being paid here or that’s being accumulated here. And it’s really large. And maybe even say, “Look, if we were to put this off by six months, this might cost not twice as much. It might cost ten or even a hundred times as much.” So, by saving $5,000 now, you might actually be accumulating $50,000 worth of debt. It’s [bigger] than you think.

But I do like – so, I think that’s one important tool. But I think then also the other important tool is to say, “If we are going to attack this, let’s drive it home. Let’s put it at the core. Let’s make this a value that we hold so that the tree can take care of the fruit itself.” So, if we say that we’re going to put in accessibility – because not all projects are greenfields.

JOE: Absolutely not.

CHARLES: So, what’s the message to them? Sorry. You’re just SOL. I think if you’re a year into a project, two years into a project, and you realize, “Oh no. We need to do internationalization,” recognize that that might be something that’s – that’s a pillar of your architecture. Or, “We’re going to make this application accessible,” don’t half-ass it.

WIL: Weave it in.

CHARLES: Say, “We’re going to transform this. We’re not going to add accessibility. We’re going to transform what we have into an accessible application.” Or, “We’re going to transform what we have into a beautiful application.” Otherwise…

WIL: Yeah [inaudible].

CHARLES: I would say leave it ugly and focus your efforts elsewhere on things where you do have your values straight. Because you’re never going to have everything in line.

JOE: No.

WIL: Treat software like immutably. You don’t add something to it. When you want to add accessibility, you’re creating a whole new accessible app.

ELRICK: Ooh. That’s deep.

CHARLES: Yeah.

JOE: So, having seen – I don’t know. I think it was very apt, looking at it as a business decision. I’ve seen it go the other way. Because at least among engineers and people on the technical side of it, this can become a very strong moral issue that people feel very strongly about.

CHARLES: Because we have to live with the consequences quite honestly, right?

JOE: Exactly. And that’s a hard thing to translate to say an executive board that may be three levels abstracted away from you and is making those decisions. I’ve seen people attack or approach this I guess with that emotion built in, with the, “This is the right way to do it. Everybody else is doing it wrong.” It gets nowhere, basically. What needs to happen I think, so you talk about having this beautiful tree. But that also requires beautiful gardeners. And so, where the moral thing or the interpersonal thing comes in is there needs to be kind of an inclusive and encouraging environment that is fostered among the people tending to the tree. And that’s a totally separate thing than selling the business value of it. Those things should be completely divorced.

CHARLES: Yeah. It’s funny. It’s always hard to reconcile those two things, right? Because on one you have, “You have to take care of the raw consumption of material and the output of product.” But then also trying to – so, there’s some baseline math that has to happen but making sure that that goal, it doesn’t slice people. And can enable them to be happy and feel like they’re doing good work. And that the things that they’re doing is having meaning. It’s probably an insoluble problem that we’re going to be dancing around for as long as people are around. If there’s one thing that we’ve come to recognize around here, and we’ve stated it many different ways from a bunch of different angles through the course of this conversation, and I would say through the course of this podcast, but that is if you want to see something in your software, make sure that you attack it from the get go.

ELRICK: Intertwine it in your DNA.

CHARLES: Exactly. And then you can actually experience the fruit, rather than trying to always, always trying to jam it and change it and get it into the taste you want after the fact.

So, I guess that’s it. Thank you so much y’all, for this conversation. I really, really enjoyed it. For those of y’all listening, if you want to continue the conversation, you can get in touch with us we are @TheFrontside on Twitter. Or you can drop us an email. We’re contact@frontside.io. So, thanks Elrick. Thanks, Joe. Thanks, Will.

JOE: Thank you.

WIL: Thank you.

ELRICK: Yup. It was great.

JOE: It was fruitful.

[Chuckles]

ELRICK: Frontside-first.

CHARLES: And well, we’ll see y’all around.