In this interview, TJ Usiyan, an instructor with Iron Yard, talks about whether development and testing teams need to be on the same page. He also explains how subjectivity influences our systems and applications and why teams overlook subjectivity.
Josiah Renaudin: Welcome back to another TechWell interview. Today I'm joined by TJ Usiyan, an instructor with the Atlanta-based company Iron Yard and a keynote speaker at this year's Mobile Dev + Test Conference. TJ, thank you so much for joining me today.
TJ Usiyan: Thank you for having me.
Josiah Renaudin: Absolutely, and before we actually dig into the meat of the abstract of your keynote, can you tell us just a bit about your experience in the industry?
TJ Usiyan: I started programming in iOS seriously probably about eight or nine years ago and I worked on a couple of apps for myself and went to a bunch of meet-ups. I was fortunate enough to bump into Aaron Hillegass, actually. Big Nerd Ranch. We chatted a little bit. He, in passing, mentioned that they were looking for people and I never let him forget that until I graduated and bothered a few other people as well. I was there for a few years and now I teach for Iron Yard, still in Atlanta. I have, in that time, mostly been teaching but I have worked on a couple of contract apps and done some map ... Mostly I'm a teacher. Mostly I spend my time trying to explain how to write apps and use all the tools.
Josiah Renaudin: Gotcha. Your keynote itself, it covers how our ideas and assumptions impact the applications we develop, which is a really interesting topic that I haven't heard too often. So to kick things off, what are some of the actual benefits of human subjectivity when it comes to influencing our systems and applications? I mean, of course people make applications but I think sometimes people forget about, so what can subjectivity really mean for applications?
TJ Usiyan: One of the nice things that can occur is that you can ignore things that don't actually matter to your user. If you know the problem space really well, you know to some extent what the user knows and what they care about. You can place emphasis on things that you know will delight the user and remove emphasis from things that the user doesn't actually care about. Sometimes you do that without realizing it, so that's a benefit of subjectivity and making assumptions, and sort of having in-built assumptions that you just go with.
Josiah Renaudin: Of course, there's always the other side to that coin, that because our assumptions and ideas are really magnified in this space, how could you actually see that being detrimental to development? Especially since, like you mentioned before, sometimes we don't even realize how much our subjectivity is influencing the stuff.
TJ Usiyan: Yeah, that's kind of the main point, that the benefit that we get often is a double-edged sword because we think that we are being efficient and cutting out the fat, so to speak. You can always later on find out that we actually trimmed a little bit too much—the user, it turns out, sometimes does care about this, or there's a user who you simply had not considered.
Josiah Renaudin: It's funny, I used to review products for a CBS site, and all the time you would get this strange complaint, like, "You've added too much subjectivity, you've added too much of your own opinion to this review," which inherently doesn't make a lot of sense. Because a lot of the complaints you get about people not realizing how things are subjective ... We talked about it a little before, but why do you think we so often overlook the subject of nature of software development? Why do you think we push that to the side and say, "That's not really a part of it," when in reality, of course, if you have a small team of, let's say, three people making something, the choices you make or what you might like or what you think people like are going to absolutely influence it. Why do we overlook that?
TJ Usiyan: Because we're not presented with people when we interact with the software usually. Usually we open up our computer and we see screens that, I guess if you pressed me, I would realize or admit were written or arranged by some person somewhere, but I don't know what they look like, I don't know what they sound like. They don't know me, and that, coupled with the fact that usually when we talk about programmers and programming, there's this element of math and this element of algorithms and code being this thing that eventually can almost think for itself.
Josiah Renaudin: So much of software today is talking about agile, DevOps, and the idea of really working together. The testing and development teams working together in a lot of ways. How can different thought processes and assumptions between these development and testing teams impact that actual success of an application? Do you need to be on the same page within a team with your assumptions and opinions on things in order to move forward? Or is there value to this dissonance where you can bounce off of each other and come to a compromise?
TJ Usiyan: That's a good question, and how can different thought processes ... Usually, hearing someone who is on a different page early in the process can help you expand what you would actually consider and make decisions about what you actually want to emphasize and not emphasize, right. One thing that I want to warn people against is that I'm not advocating that you actually have to consider every single person all of the time in all scenarios, but you have to know that you have a made a decision not to support this user in this way. Having a conversation early on with as many people with as many views as you can, can help you understand where you've fallen in the relation to certain decisions that you can make, and you know whether or not you have to be on the same page ... You don't actually have to be on the same page in the beginning, but I do think that by the end of your process, you should be on the same page.
Josiah Renaudin: As a teacher, have you seen a lot of times where not being on the same page at the start doesn't eventually lead to a compromise at the end? Where a team will actually break up because there's so many differences that seem insurmountable.
TJ Usiyan: Yes, yes, and there are probably two different explanations for that. I guess I can talk about them now. One of them is that you don't realize that you aren't on the same page throughout the whole process, and then you get to the end and the product that comes out displeases both of you or one of you, just because you never really reconciled that thing which you didn't know that you needed to reconcile. The other scenario is where sometimes you find out very early on that you don't agree and that you have different desires and you never come to a compromise just because there is no compromise to make. Or no compromise that will please both of you or something along those lines where, if we basically realize that we want to make different products, that are related but not the same, then there's no way to make that work.
Josiah Renaudin: That's, as you mentioned, an almost unsolvable issue in many cases when you're just on completely different sides of the fence and you're trying to make different things. Have you seen, over the course of your career in software, have you seen one consistent theme amongst different development teams that's holding them back, that you feel like is solvable? That you can change that frame of mind and actually help them succeed?
TJ Usiyan: Yeah, there are a few. The simplest one, which is not actually all that simple, is I would challenge very strongly the idea of what we are talking about when we talk about company's culture or a company's ethos and basically our ideas around diversity, because I think it's not as complicated as it could be yet. We don't hold in our heads the many ways that people can be diverse and hopefully should be diverse on a team, and when we allow more diversity, I think we will actually achieve a more sympathetic software development process.
Josiah Renaudin: Yeah, absolutely. Of course, I don't want to give away your entire keynote, but I'm still going to ask you a big question here. More than anything, what's kind of the central message that you want to leave with your keynote audience? If they only want to take one thing away from your discussion, what do you hope that is?
TJ Usiyan: Be more mindful and consider how you are being mindful. Yeah, more than anything, that is the statement.
Josiah Renaudin: All right. Fantastic. Thank you very much, TJ. I really appreciate the time. I'm looking forward to hearing the full thing at Mobile Dev + Test this year.
TJ Usiyan: Thank you, and I'm looking forward to actually delivering that talk.
An instructor with Atlanta-based Iron Yard, TJ Usiyan is a teacher, writer, musician, and software developer, excited about crafting interesting work and helping others do the same. TJ has two degrees—one in electronic production and design and the other in creative writing. He entered software development through musical and pedagogical interests and has spent the time since exploring and modeling musical structure and the language of music in Objective-C and Swift. TJ developed and released the iOS app Chordal Text and the Additive Synthesizer Audio Unit (Partial).
