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?