Appy Hour Recap: Nordstrom

Last night’s Appy Hour was one of the best we’ve had so far! We were thrilled to co-host the event with Nordstrom, the world’s leading fashion retailer and one of Apptentive’s wonderful customers.

The event was held at Galvanize, an incredible new education company, school for data science and web development, and co-working space in Pioneer Square.

For our community members who couldn’t make it out to the event, we want to make sure you’re still able to take away a few key learnings. Below is a quick recap of last night’s talks, along with some additional links to keep your brain juices flowing.

But before diving in, be sure you never miss another Appy Hour by signing up for the meetup group here.

Enjoy the recap, and hope to see you next time!

Appy Hour Recap: Nordstrom and Apptentive

Moderator: Robi Ganguly, CEO of Apptentive

Panelists: Jeremiah Johnson, Nordstrom iOS Architect; Graeme Harnish, Nordstrom Android Architect; Diana Sutlief, Nordstrom Android Developer

Q—Robi: I hear you’re doing TDD? How are you using it, and how’s it going?

A—Jeremiah: So TDD is Test Driven Development, and we’re being very literal with it. We start by writing a failing test, then write the most simple code possible to make the test pass, and then refactor if needed. We’ll follow this process and iterate constantly on a feature or bug until it’s done. You might have heard this called Red-Green-Refactor.

As far as how it’s going, there are multiple levels to that. One of the coolest things about this, I think, is what the process does to your code. If you’re doing the most simple thing that will work in your code, then by definition, your code is simple. It’s lean, concise, and (mostly) easy to read, and refactoring is very simple because there isn’t a lot of it. When you see code like this, it gets absorbed quickly and your team can make modifications easily.

It’s not all rosy, though. One of the challenges we have with TDD is that a lot of our codebase is legacy—it isn’t covered by test and wasn’t designed with test in mind. Modifications are risky because we don’t have tests telling us that we broke anything. The philosophy we subscribe to here is “cover then modify.” Basically, you add tests at the level you can to verify that the software still works as it did originally. Then, you start adding tests for your mods, and these tests might be in conflict with the “legacy” tests you created, which is ok. Once you have tests in place, you can start modifying code and be confident that it’s doing what it’s supposed to be doing. When the tests are passing (or failing, as the case may be), you can start removing code as needed, which is always great.

Q—Robi: What kind of architecture do you have on the Android team, and what kinds of things do you use to help in your development?

A—Graeme: We use a lot of modern libraries to help and really accelerate our development. For anyone who’s been with Android over the last few years, you’ve probably noticed how much developing for the platform has changed. We’ve evolved in our build tools, IDE’s, libraries, etc. We use a lot of new libraries such as Retrofit and GSON for JSON parsing. Of course, we’re using a lot of the new material design widgets to give our app a nice, modern look.

One of the biggest wins in our project was utilizing RxJava for our async calls. A common scenario you see is having a series of networks calls happen and then no real good way of handling when they all return. I’m sure a lot of you have been in broadcast-listener hell with big if else statements for the returning calls. RxJava allows you to neatly compose services into each other. It also really helps remove call back issues, as well. Rx is being adopted in a lot of large projects. The only downside is that moving to a reactive programming model takes a mind shift, especially for Java developers like myself.

Another area where we have really grown is testing. Believe or not, we say we write tests and actually do. I know most shops I’ve been in, testing is virtually non-existent. Luckily, Android Studio has really matured in that department, things like Espresso and Mockito make testing very reasonable in the framework. In the beginning, we had a lot of large integration tests that would break left, right, and center. We were using live data and making them way too large. The actual Android framework makes it very difficult to write small unit testable code. So much logic ends up in the life cycle method and it sucks. We’ve managed to take a lot of the logic out of those methods and make them small JUnit or Espresso tests. Utilizing Mockito, were also able to easily mock out or JSON objects and not be reliant on the real servers. As far as rapidly getting our builds out with some quality, we have our continuous integration server run the unit and integration tests on each check in.

I’m excited to watch development for the platform change so rapidly and it’s a tad hard to keep. I’ve written some blog posts detailing a lot of what I’ve talked about. Feel free to check them out as they’re on the Appy Hour invite.

(Wait right there, readers! No need to head back to the Appy Hour invite to check out Graeme’s blog posts. You can view them all here.)

Q—Robi: As a newer member of the team, what has been your experience with pairing?

A—Diana: I had some concerns coming in about pairing…first I wondered how it could work logistically in terms of breaks to take care of phone calls, emails, etc., but I discovered that everyone has the same needs and we all take the breaks as needed. We all have laptops in addition to the pairing stations, so it’s easy to take care of things on the side as they come up.

I also wondered if I could handle being with people all day long or if there would be a lot of conflicts philosophically between developers. Neither of those have really been a problem. I found that pairing actually fosters more of a focus on the success of the team rather than of the individual.

One thing I miss is that there’s a little less time to explore the code individually but one can still carve out that time if they try. On Wednesdays, we receive a half day of unstructured time to work on our personal growth as a developer, which helps alleviates some of that.

What attracted me to paired programming is the high degree of knowledge transfer amongst people who’ve been working in the mobile space for several years. I also really like the commitment to building quality into the code up front.

I hope you enjoyed the content covered at last night’s Appy Hour. A huge thanks to our friends over at Nordstrom for making the evening a success!

If you think the content is good in blog post-form, wait ’till you see what it’s like in person. Be sure to catch our next Appy Hour by signing up for the meetup group here.

We’ll see you in August!