JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

075

075 JSJ Maintainable JavaScript with Nicholas Zakas


Panel

Discussion

01:24 – Nicholas Zakas Introduction

02:19 – What Makes Maintainable JavaScript?

  • Code Layout
  • Clever Solutions (“Chicken Blood Solutions”)

04:39 – Formatting

07:33 – Architecture

14:11 – ‘High Performance Javascript' and the balance between short-term and long-term knowledge

19:17 – Important conventions for a team to follow

  • Styles
  • Mini Design Patterns
  • Readability

26:14 – Tools & Techniques

  • Style Guide

28:31 – Breaking the continuous integration build

31:14 – Linting

32:35 – Developing skills for architecting things

  • Experience
  • Personal Trait of Curiosity
  • Component-based and Systems-based software engineers

37:52 – Architecture and Maintainability

43:28 – Creating common conventions that will apply across projects

Picks

Next Week

Meteor.js with Marcus Phillips and Fred Zirdung

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the frontend of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out at JetBrains.com/WebStorm.] CHUCK:  Hey everybody and welcome to episode 75 of the JavaScript Jabber show. This week on our panel, we have Joe Eames. JOE:  Hey, everyone. CHUCK:  AJ O’Neal. AJ:  I can hit unmute. I’m here. CHUCK:  Jamison Dance. JAMISON:  Hello, friends. CHUCK:  Merrick Christensen. MERRICK:  Hey, guys. CHUCK:  I’m Charles Max Wood from DevChat.TV. This week, we have a special guest, that’s Nicholas Zakas. NICHOLAS:  Yup, you got it. CHUCK:  So, since you haven’t been on the show before, do you want to introduce yourself? NICHOLAS:  Sure. I’m a software engineer that is working for Box currently. I think a lot of people probably know me from the books that I’ve written, mostly on the topic of JavaScript and the talks that I’ve given also on that topic. And a lot of that relates back to my work when I was at Yahoo. I was there for about five years and was the lead on the Yahoo homepage redesign. And a lot of what I do is really just try to solve problems in real life and then share what I did with everybody else in whatever way I think is most appropriate – writing or speaking or coming on podcasts. CHUCK:  Yes, you’re being modest. You have a book, Maintainable JavaScript. NICHOLAS:  I do. JOE:  Which is an awesome book. NICHOLAS:  Thanks. CHUCK:  I have to go see if I can get my hands on that. I’m wondering, what in your opinion makes Maintainable JavaScript? NICHOLAS:  Really, the idea behind Maintainable JavaScript or really maintainable anything is that somebody other than you has a fighting chance at maintaining it later on. So, you’re programming not just for yourself or to get this feature done or to meet a deadline, but you’re programming with an idea that somebody else is actually going to be taking this over in the future. And given that, how can you make sure that that person basically doesn’t want to hunt you down and just be [inaudible] because of what you’ve done. CHUCK:  [Chuckles] NICHOLAS:  There are a few things that go along with that. One is that when you look at the code, it’s laid out nicely. You’re playing by the rules that have been set down at your company or on your team. One of the biggest things that annoyed me in my career was when I would go some place and you have five people on the team and they’re all writing codes slightly different. How many times have you ever opened up a file and before you did anything, you just reset all of the formatting. Like, I need this indented my way so that I can start to understand what I’m looking at. And that’s a very small example. On the other end is people who create solutions that are incredibly clever. And by clever, I mean only they will ever understand this thing in the history of the world and celebrate that without realizing that once somebody else has to look at it, they’re just going to be completely lost. And that’s when rewrites end up happening sort of accidentally because somebody goes in and says, “I really don’t know how to do this. I’m afraid of touching it. I think I’m better off just creating something completely new,” which wastes a whole bunch of time and effort and so on. CHUCK:  I call those ‘Chicken Blood Solutions’ because you see the solution, it works and there’s chicken blood and feathers on the altar next to it. [Laughter] JAMISON:  I think it’s really interesting that you brought up formatting too because I feel like I’ve gotten madder at coworkers over formatting issues than bringing down [inaudible]. For some reason, it just brings out the rage in me when there’s inconsistent formatting. There’s like extra mental effort that shouldn’t have to be expanded. NICHOLAS:  That’s exactly what it is. If you’ve read this book ‘Thinking Fast and Slow’, it’s a fantastic book and it talks about basically how our brains work in different situations. And one of the things I got from that which I’ve experienced and I would tell people about it, I don’t think anybody really believed me, is that your brain gets used to certain patterns. And when you detected anomaly in that pattern that you’re used to, you’re switching to a different mode in your brain and that kind of gets you upset. So, it completely makes sense what you just said. And when I was consulting before I worked for Box, I would actually get hired by companies to go in and help them figure out their code conventions. It wasn’t that these weren’t people who had an idea about how they wanted code to be written, but it was a bunch of people who could not agree amongst themselves how the code should be written. I’m a very big believer in the Broken Window Theory where we need to do the small things right and if you have any chance to get the big things right, then code conventions is one of those things that is actually pretty small but the amount of people that shy away from figuring that out is really large. And they do that because it involves confrontation and they don’t know how to break ties. I always tell people, “Look, we all have opinions and none of this is about telling us that one person’s opinion is wrong and one person’s opinion is right. It’s really just about everybody agreeing to do the same thing.” So, if you get everybody in a row boat, you all got to be rowing at the same direction or you’re not going anywhere. CHUCK:  One other thing that I want to add to all of this is just in the maintainability of the project, if you’re looking at the git or SVN log or whatever, it really sucks to have these commits sort of huge and all it is, is you reinvented the file, a hundred or a thousand line file. MERRICK:  Yeah, it’s also prone to merge conflicts. CHUCK:  Yeah. And it’s a merge conflict over something that ultimately doesn’t make the code work any better. JOE:  I would also like to chime in that Thinking Fast and Slow is a truly awesome book. I totally enjoyed reading it. CHUCK:  Nice. That’s on my list too. JOE:  Yeah. MERRICK:  Aside from formatting, a lot of your work has been in the scheme of architecture. And I believe [inaudible] a lot of more recent work like the Aura, Backbone Aura from Addy Osmani. Maybe talk a little bit about your architecture work and if you think that that sort of architecture still is applicable with these newer frameworks like Angular and Ember. NICHOLAS:  Yup. So, this all began actually, I think it was like four years ago now, four or five years ago when at Yahoo, we had to come up with a JavaScript framework for the new Yahoo homepage. And one of the developers who had been working on it came to me one day and said, “You know, I really enjoy working with this. I would really love to understand the decisions behind how this thing was made. Could you just put together a talk on it?” And so, The Scalable JavaScript Application Architecture talk was a direct result of that request. It was to explain this internal architecture and framework that we had set up so that people could just understand at a high level how to build things. And at the time when I first gave it, it didn’t get very much attention which I wasn’t sure what to think of. Two years later, all of a sudden, it started popping up. And I think what happened was that people started getting more interested in JavaScript architecture with things like single page applications becoming very popular. MERRICK:  Yeah, I think you’re having your time, kind of an innovator’s dilemma. NICHOLAS:  Yeah. If you look back at the video of that talk, I am a little bit apologetic and I was telling people, “Look, I’m not saying this is actually going to work for you. I’m just saying this is a way of thinking about organizing things.” It does relate a lot to maintainability of the product because I believe that a good architecture and a good framework help you answer the question of what goes where. And that is you need to create something new or you need to change something and just know where to go to do that. By doing that, you create an entire code base that is much more predictable and reliable and people just feel more comfortable doing their work. MERRICK:  The other thing I really like about your architecture that seems neglected across most other architectures that I’ve seen is that you think a lot about featuring capsulation. So, keeping people kind of boxed. NICHOLAS:  Yeah, that’s one of the key things that I found in my career prior to that time at Yahoo was that global scope pollution was really the number one problem in creating maintainable code bases. Because even when you had objects that were separated out, they were so dependent on the global environment being set up in a specific way that every time you had to change something, you had to go and make sure you’re not breaking something else. And this was the first framework that I’ve worked with at Yahoo was set up like this. It had the beginnings of good stuff where you had these separate objects that had mostly single responsibilities, which is great, it’s a really great start. But the problem was that everything was a global object. And that meant when we wanted to remove or replace something which we did want to do, it was really painful because we have to go and find all of the references everywhere else or else we would break stuff. And so, the idea of keeping things really encapsulated and not creating global objects and basically only passing in pieces of information that it should use and letting those objects request additional things was something that made our lives a lot easier. And it also let our teams scale because one of things that happened was, what happens at a big company is you start out on a team and you say, “Okay, we have five people and we’re going to take a year to do this.” That’s great. How about if I have 20 people, now how long is it going to take? [Chuckles] NICHOLAS:  And so, we had to figure out a way that each of those 20 people, and these were just frontend people, were able to work on their pieces without negatively affecting what other people are doing. The only way you can logically do that is to make sure that everybody isn’t sharing dependencies explicitly across all of the work that they’re doing. MERRICK:  Yeah, scaling the team is probably my favorite part about the architecture you proposed. JOE:  I’ll look for the link. There’s a really great talk that was given, I think on InfoQ and it was about architecture. I think it was a woman who gave this talk. She talked about building the Empire State Building and how it was built in 11 months or something like that. And the only way to get that was to separate out the different pieces of the building so they could be building the pieces separately. So, they put up all the steel work and then the people would come back afterwards and do the next piece. But they never had to go back to a previous piece. They separated out how they interacted all the different pieces that are out there. And they had no onsite storage for any of the material that was being put up. And they still managed to build this amazing building in an amazingly small amount of time. This was back in the 20’s or something. NICHOLAS:  Yeah, I love that example. The one that I use in my talk about this is the International Space Station which is made up of a bunch of modules that were developed separately and then shot into space and then connected together in space. And by doing that, they’re actually able to let different countries build different modules. They wouldn’t know until they got into space how the stuff worked. So, defining the interface between those modules is really important to make sure that every country could get their work done and shoot it up into space and then just be able to combine stuff together to ultimately create the Space Station as a whole. JOE:  That’s awesome. JAMISON:  I have a question about a slightly different topic. I read your book ‘High Performance JavaScript’ and it was really well-written but much of the advice has been obsoleted just by new browsers. Lots of that book is about dealing with IE6 and thankfully that’s not a thing that I have to do very much anymore. So, I wanted to ask how you balance technical books between short-term framework technology or platform specific information and longer term general principles. NICHOLAS:  It’s a really hard problem. And it’s something that I’ve struggled with almost every time I’ve written a book. Even to the point where for one of the additions of Professional JavaScript, I had gotten pretty much to the end when Firebug 1.0 was released. It had been like point something at the time. And we were just about to say, “Okay, let’s ship this thing.” And Firebug 1.0 came out and I sent this frantic email, “Oh, my god! Stop the presses,” literally. [Chuckles] NICHOLAS:  “We cannot release a book that is talking about the old version of Firebug, We need to fix this.” And then, on another one and this was even more fun. We were in the same spot and Chrome was released. [Chuckles] NICHOLAS:  It’s not just a new tool. It’s an entirely new browser that I had to go back and look over all of the content in the book and now see what was different in Chrome. And that was absolutely maddening as well. And so, High Performance JavaScript was the last book that I worked on in what I consider my old mindset which was, let me just cover the current state of the art right now and get it out there and just accept that within two years, it’s probably not going to be as useful. There are parts of High Performance JavaScript that are still important to understand but there is a lot of focus on sort of like IE6 and really the JavaScript engines that do not do compilation and that are still doing interpretation. Because Chrome I think at that time was the only one that had a compiling JavaScript engine actually out in their product and the other one is kind of working on it. What I’ve come to do now instead is try to separate my content into timely content and timeless content. So, I actually look at writing a book similar to building software. And that I try to create small pieces that I can identify how frequently I think they’re going to change. So for example, when I did this most recent version of Professional JavaScript, I specifically separated out things that were ECMAScript that is the core of JavaScript that is not going to be changing all that much. And then, I had chapters on DOM Level 1. DOM Level 1 is done. We’re not doing anything additional on DOM Level 1 right now. And then, ones on DOM Level 2. DOM Level 2 is done. We’re not doing anything additional on that. And I could go through and basically say, “Okay, in two or three years, I have a reasonable degree of certainty that these chapters are still going to be important.” And then, anything that I think was new and upcoming, I separated out in two other chapters. Okay, I’m willing to say this now. But I know that if I go back and do another edition of this, I might just delete this chapter completely. Part of writing books, because it does take a while, is you have to anticipate the future a little bit. And so, I placed bets on what’s going to be important. Early on, I placed a bet that SVG was going to be super important. That was not an awesome bet. [Chuckles] NICHOLAS:  So, the next edition, I just removed that. It takes a lot of planning with technical writing just because things change so quickly. But I think now, I’m in a pretty good spot. And like Maintainable JavaScript, I made to be as much as possible, evergreen. I don’t think there’s anything in there like two years from now, people will go back and be like, “Wow! That was really bad advice.” I should definitely not be worrying about code conventions at all. I don’t anticipate that happening. The only thing is that in the last section, I used Ant as a build system and a couple of people go, “Well, that’s a little old.” It’s a little old but it was really well-documented. It will still work in a couple of years. So, I don’t feel like I’m leaving people completely off on their own in that regard. CHUCK:  I want to ask about Maintainable JavaScript just a little bit more. You talked about having conventions on your team to facilitate being able to make assumptions about the code and communicate well through the code. It kind of sounded like you’re alluding to style guides but there are other conventions you could be following as well. I’m kind of curious to know which conventions, besides formatting, you think are the most important ones to follow on a team to make your JavaScript maintainable. NICHOLAS:  I think that it can be very team-specific. There are some different types of conventions. One group is styles, obviously. The other group I think of as like mini-design patterns. It’s just ways that you’ve decided as a group that you’re going to address certain types of problems. I’m a very big believer that you should solve a problem once and then not try to solve it again unless some assumption changed. It’s actually not useful to have everybody on the team writing their own factorial function. We should do that once, and then we should never have to do it again. Those things tend to be very team-specific. Some of the things that we’ve come up with on my team have been like, when do we use options objects as arguments for function? When do we actually name out arguments and say, this is argument one, this argument two, this is argument three versus when you have an object that has keys on it and that has all of your arguments on it? This sort of crosses over from style because it’s not just about formatting, but it’s really about how you, as a team, want to think about writing functions. What we came up with was anything that is a required argument to that function should be its own named argument in the function definition. And then, anything that is optional can be thrown onto an optional last argument that is an object that has keys in it. Something like that seems trivial. When I used to go in and do consulting around this, I always take questions about like, “This is minutia. Why do we care about this?” Really the thing is that you’re laying down a foundation of a bunch of small pieces and that freeze you up later on from needing to stop and refigure out this problem again and have everybody on the team figure out this problem again. MERRICK:  Yeah, really makes sense. What do you think about external frameworks that are prescriptive in their nature that try and solve these problems for you? NICHOLAS:  I think if that’s what your team wants to do, you should do it. I don’t like getting too much into like, there’s a right way and a wrong way of doing stuff. My main goal is that there should be one way. It should be unambiguous and everybody should just know it so that they can get to work on the stuff that they are actually providing value to on. For spending a lot of time worrying about how I should format this or the specific way I should be doing this, then you’re not actually getting to the point of the work that you’re doing. JOE:  Yeah. That’s really quite interesting because a lot of people spent a lot of time worrying about what’s the right way right now versus coming up — you’re saying your focus is make sure that there’s one way and that’s more, if I interpret what you’re saying correctly, you’re saying that’s more important to maintainability than whether or not you actually picked the most optimal way to do it. At least pick one way and do it. NICHOLAS:  Exactly. JOE:  Yeah, I think that’s really interesting because there’s a lot of talk about what’s the right way and a lot less focus about ‘let’s just pick one way’ and the value of picking one way. NICHOLAS:  Yeah. For a lot of this stuff, it’s very hard to say that one thing is demonstrably worse than the other. And I always chuckle when — I’ve had indentation arguments my entire career. You sure do tabs, you sure do spaces. And if you do spaces, how many spaces? “Oh, that makes it so much harder to read.” A lot of the arguments that people give for stuff like that are really, you can’t prove it one way or another. Going back to Thinking Fast and Slow, whatever you are used to seeing will seem more readable to you. So, arguing readability is really not valid in any way because you can think that one thing is incredibly readable and I can look at it and I’ve never seen something laid out that way before and it is just horrible for my eyes, and vice versa as well. So, I usually try to get people away from readability when we’re debating these things. You just say, “Seriously, why do you think this is the right way to do it?” And the answer might be, “That’s just the way I’ve always done it.” And that’s completely fine. But you need to realize that that is not a good reason to say like, “We should keep doing it this way,” because a lot of us are self-taught, a lot of us have our own styles that we’ve been dealing with since we started hacking on weekend projects as a teenager. And that may not be the best way for the team to work. And I’d also like to use the example of like an orchestra, is that everybody in the orchestra has a specific role that they’re filling in order to create beautiful music. But if you decide that you’re going to do things differently because you don’t agree with the rest of the orchestra, you change your tempo, you change your key, anything like that, the entire piece is ruined. So, just getting everybody with the same rhythm and the same key at the same time really goes a long way. And also just telling people, “Look, we are not saying you are wrong if we don’t pick your way, what we’re saying is we have to come up with one way of doing it.” I think it was Crockford actually that said this during a talk is that driving on the left side of the road or on the right side of the road, neither one is right or wrong, but it’s really important that everybody agrees to do it the same way. [Chuckles] JOE:  Yeah. I love [inaudible]. CHUCK:  Do you have some tools or techniques that you use to document these decisions? NICHOLAS:  I don’t have any good tools. I wish that we could just do this in an automated way. But what I tend to do is keep a living style guide. And I’ve set this up at other companies. I’ve set this up at Box. And the idea is when you get together regularly and talk about code which you should, you will probably come up with something that looks a little strange. You just want to say, “Oh, I’ve seen a couple different ways of doing this. How can we decide just to do it one way?” And basically build up that style guide slowly through conversations with people. The intent of the style guide is not to be like first day sit down, you must read the style guide to figure out everything because I’m a big believer that styles can get transmitted through osmosis. If you just follow the style of the file that you’re in, it can actually spread around pretty quickly. And then if there’s a question, the style guide is there more as a record of decisions that were made than a tutorial. And so, I have, as an appendix in Maintainable JavaScript, a style guide that I wrote. I’m not saying that it’s the only way to write style guides but it is at least a template that you can start to follow. And again, not to use that as the primary means of communicating what the team should be doing. The primary means should be talking with each other and working with the code that you have. I’m looking now more into things like linters as I started this ESLint project with the goal of being able to have completely pluggable rules not just for styles but for anything. I’ve also been looking more into automatic code formatters because I have this dream that as a pre-commit hook, you could have a code formatter that’s set up with the way your team says code should be formatted and it just does it automatically and there’s never an issue about it. Not quite there yet. CHUCK:  [Chuckles] MERRICK:  Do you suppose that people should break the continuous integration build if they are meeting the formatting goals or do you think that’s too rigid? NICHOLAS:  I think that depending on your system, it could be too rigid. To me, formatting is something that we should be able to do automatically in some way. And that if we don’t do it automatically, then how do you want to enforce that? Stopping the line for formatting issue, I feel that goes too far. I feel like if you can give people the automated ways of checking their own work, then you should be able to trust them to do the right things. So, if we say before you check in, this linter has to be run and there has to be zero errors. I want to be able to trust the people on my team who actually do that and abide by that and block a check in because some weird formatting thing got in there. MERRICK:  Yeah, okay. Does that scale as well when you have the number of developers, like for example, that you have at Yahoo? NICHOLAS:  The interesting thing about when I was at Yahoo, and I kind of laugh looking back now, is that we had very little automation on the frontend. Literally, you could be hacking on stuff and you could just check it directly in and there is no automated testing that will be run. There is no automated linting that will be run. It would just go. And yet somehow, everything worked okay. Later on, we made a gmake rule, I think it was called gmake commit or something like that, that we just asked everybody to run before they checked in and that would do basic linting, that would do basic testing. And the implication was if you checked in and you broke the build, then we knew that you did not run gmake commit. And then, you would get a monkey hat that you had to wear to meetings to let people know that you broke the build. [Laughter] JAMISON:  Shame-driven development. NICHOLAS:  Yeah. And then at the end of the month, everybody who broke the build had to sing a song in our stand-up. JOE:  That’s awesome. NICHOLAS:  And everybody did. I broke the build once, I wore the monkey hat and I sang a song with the other people at the end of the month. Yeah, shame-driven development is sometimes effective in lieu of automation. JOE:  [Laughs] NICHOLAS:  [Inaudible] to it sometimes, I don’t know. CHUCK:  I’m kind of curious. You’re talking about some of these coding conventions that people follow. How was that different from linting? NICHOLAS:  Linting really was designed to find problems with your code rather than give you opinions about things. JSLint started out as ‘here are some really bad things that you need to be aware that you’re doing’ because it could really cause you a problem. Not just that it didn’t look pretty but at runtime, this could cause you a problem. And that was really what linters are designed to do. It’s kind of come into the realm of style now once Crockford decided what his style was. He started adding all that stuff into JSLint. And I think really, these are slightly different things that tend to get jammed together because the process is the same. You look at the code and you see a pattern and you decide that it’s bad for some reason. And whether it’s bad because it could possibly result in a runtime error or it’s bad because it’s not the style that your team has decided to do. I understand why they end up getting munched together. But I think that there are two different classes of problems that linters are picking up now. JAMISON:  I want to ask a different question. How do you develop your skills at architecting things that seems like there’s not a lot of formal guidance on how to get better at it? There are just tips on specific things like avoid globals and link your code module and stuff. How do you develop those instincts to what is good? Is it just exposure to a lot of information about it over time or what? NICHOLAS:  I think that it’s mostly through experience and doing things the wrong way a lot of times. I was talking with some of the younger engineers at Box. And I was explaining to them that when we bring in somebody that’s experienced, it doesn’t mean that they’re super-super smart, that there’s something magical about them. What it means is that they’ve been working long enough that they’ve made enough mistakes that they know how to avoid major pitfalls. Because when you say that somebody has experience, what you mean is they have messed up a lot in their career and they have come out better for it. CHUCK:  [Laughs] I like that. NICHOLAS:  All that experienced it. JOE:  What about the people who mess up a lot and don’t come off better for it? NICHOLAS:  Those people we try to read out. But it’s part of doing things the wrong way and feeling the pain of those mistakes that makes you start to seek out better ways of doing things. I think a lot of that comes down to personal trait of curiosity for people like, “Man, I wonder why that was so painful? I wonder if there’s a better way of doing it.” And then going and trying to explore. I do fundamentally believe, though, that there are two types of software engineers. There are component-based software engineers that like to focus on one thing and focus very deeply. And there are systems-based software engineers who become architects because they like looking at the system as a whole and how the pieces interact with one another. And to this point, I am reasonably convinced that this is something that you’re born with this mentality. It doesn’t necessarily grow or develop. People can feel free to argue with me about this but I’ve just seen in my career is that if you are fundamentally wired as a component builder, it is very hard to transition and start thinking about systems because it’s much broader than you like to go. And for people who are more system-driven, what tends to happen is you see them creating components, but then they want to go and build the next component that fills out that system. They’re not satisfied with building just the tab widget, they also want to build the menu widget and there needs to be some way for those things to interact with another. That’s when you start to see the beginnings of systems thinking. I’m not saying, by the way, that one of these is more useful than the other. I think that just like, again going back to the orchestra example, you need people with different types of skills and different types of mindsets to create a really cohesive team. But the first step is really to think about this thing that I’m building and how does it interact with other things that are in that same system. If I make a change here, how does that change flow through the system afterwards and just continuing to go and read. I’m a very big believer that laziness has been one of things that has helped me in my career. And that I see something getting really big and I start to think, “Wow! It’s going to be really hard to maintain that one big thing.” It would be much easier and take me much less time if I had just a bunch of small things to worry about because when those things break, they break in a very self-contained way and then I can figure that out a lot better and a lot faster. I don’t have to spend all day stepping through a file with 10,000 lines. JAMISON:  It’s like the [inaudible]. NICHOLAS:  Yeah. I’m mentoring a bunch of the engineers at Box and I tell them all the time the goal should never be to build the biggest thing possible. The goal is always to build the smallest thing possible. But you can build a bunch of those small things and get them to work together. And that’s really, if you look at architecture in anything in any part of software engineering, that’s really what it’s all about. You make small things with the single responsibility and then you get them interacting with each other in some sort of rational way. JAMISON:  That sounds too sensical to possibly work. [Laughter] CHUCK:  So, how closely do you find that architecture is related to maintainability? I mean, you’ve kind of alluded a lot to that with what you’re saying. NICHOLAS:  I think that it’s really important. And it’s basically the architecture is the foundation of the thing that you are building. And if that foundation is weak, you’re going to have other problems down the line that will affect maintainability. One of the things that I encountered at Box when I got there –it’s not unique to Box, I’ve seen this in a lot of places — is that when you don’t have a good framework, things start to fall apart. And usually the way that they start to fall apart is that you’re writing things in a way that you’re not sure how to test. So therefore, you don’t have a lot of tests, you don’t have a lot of code coverage. So when things break, you’re not really aware and you’re constantly chasing down this long tail of, “This breaks when I do this and this breaks when I do this,” and, “How could I have tested for it?” “I’m not really sure.” “Well, then I guess I’m not going to add tests even after I found the bug,” which means that you don’t know if you’ve really fixed it and you don’t know if it comes back. That’s all based on having a faulty architecture. The architecture should encourage you to do things the right way. And I say a lot when I talk to people about architecture is that a good framework and a good architecture make it hard to do the wrong thing. Your path of least resistance is actually the correct thing to do. A lot of people will always go for the easiest way to get something done. And so, as an architect, as a systems designer, your job is to make sure that the easiest thing to do is actually the right thing. And once you get that, the whole system becomes more maintainable. There are prescribed ways to write tests for things. There are ways that you can figure out if you have enough test coverage. Other people looking at your code understand where it fits into the system and therefore, how it should be tested and how it should be interacting with other things. And all of that just leads to an overall more maintainable code base. CHUCK:  I find it interesting that you went to tests as well as part of that explanation. JOE:  Yeah, I like that statement. NICHOLAS:  Yeah. I think that’s an often overlooked part of good architectures is that part of the job is to make your code testable. I don’t blame individual engineers if they’re not able to write testable code. I blame the framework and the architecture that they’re using. JOE:  That’s an awesome statement. I like that. CHUCK:  You said that you blame — let me see if I can restate what you said. You basically said you blame the architecture and the framework that people are using. So, do you find that certain frameworks lead people down the wrong path? NICHOLAS:  Oh, absolutely. And I think not always intentionally either. I think sometimes, people don’t know the capabilities and limitations of the frameworks that they’re using. As a classic example — I’m going to start out with a disclaimer of saying I like jQuery, I think it’s a great library. But I think people misunderstand how to use it and don’t understand its role in your overall architecture because jQuery is actually a very low level utility. Its primary goal is to abstract away browser differences and that’s really important. But jQuery is not an application framework. It is not an application architecture. That was something that I think people are coming around to understanding. I would go into a lot places and ask, “What does your JavaScript architecture look like?” “Well, we use jQuery.” Okay, that told me two things. One was that they didn’t really understand the question that I was asking and two, the code was probably written in a way that was really hard to maintain because jQuery is really great for tying together some DOM manipulation in Ajax. And when you try to do things that are larger than that, you start to end up with a lot of spaghetti code and things that are very hard to maintain. Fortunately, we’ve had in the past couple of years, more interest in architecture and I kind of credit Backbone for that. I think Backbone did for JavaScript architecture what jQuery did for JavaScript as a whole which is it made it more accessible and consumable to people. That being said, Backbone is also not a complete architecture. It has significant holes in it. And you end up using a bunch of other things to make up for that. And I’ve seen people go in a horrifically bad direction with Backbone which is unfortunate because I think that like jQuery, Backbone is actually a really awesome utility but it’s part of a complete solution and not the complete solution. And until people start to realize that, they will misuse that as well and still end up in these sort of unmaintainable and untestable messes. JAMISON:  I have a question related to Backbone. [Inaudible] in using Backbone in a medium-sized project is that we thought we were creating lots of conventions and kind of reinventing the wheel. We thought like everyone else would have had to encounter the same problems but might have totally different solutions to the same problems. I mean, there are common things like avoiding [inaudible] and dealing with collections and binding that to data and stuff like that. So, how do you use less opinionated framework in a way where you can still create common conventions that will apply across projects? Or do you prefer something more opinionated? NICHOLAS:  I like frameworks that are opinionated about what they are good at and not opinionated about what they are not. The point of my Scalable JavaScript Architecture was specifically to say, “Here is how you start building an architecture that is opinionated about the groundwork but nothing else.” It has this idea of separating things into modules. It has this idea of not creating a bunch of global objects. It has this idea of creating an easy way to have extensions into the core of what the architecture does. But short of that, the rest is wide open. And so, you can actually take that as use it with something like Backbone which is what Aura does. And say, “You know what, I want to use that fundamental architecture but I want this concept of models and views and to provide that, I’m going to use Backbone.” And I think that’s the sort of trouble that you’ve run into is a trouble that I’ve seen people run into is that they bring in Backbone and they think that it’s solving everything. And I don’t think that Backbone was meant to be actually a complete framework in and of itself because it is very small, it is very particular about what it does and the relationships between the different pieces. It’s also kind of why I think it’s brilliant. However, when people go in and expect that it’s solving all of these problems for them, that’s usually where they end up falling a little bit flat. And so, I always tell people, “Look, you need to decide how much work you want to do and how opinionated you yourself are about how things should be written when you’re choosing a JavaScript architecture.” Because if you want a lot more control and you want to be able to sort of fill in your own blanks, then starting with like a jQuery base and having Backbone on top of that is a fine way to start as long as you accept that you’re going to have these holes that you have to fill in. If you’re not willing to accept that, then going more of a route of like an Ember.js or Angular might actually be the way that you want to do it because you don’t want to solve those problems. You want to solve your application problems yourself. I do like to have one framework that everybody who would be working with each other would use. I wouldn’t do Angular on one and Ember on the next because then that creates a lot of knowledge fragmentation within a team and within a company. But trying to find something that can suit everybody’s needs within the team or the company is hard but ultimately, I think a worthwhile endeavor so that you don’t end up with pockets of people who have idea how to interact with each other’s code. CHUCK:  I hate to cut you off, but I know that several people on this particular call tooting me to hop off pretty soon. So, I’m going to go into the picks. But I just want to know, will you come back on the show? Because I feel like there’s more to say about this and much more discussion to be had. NICHOLAS:  Yeah, absolutely. I’d love to. CHUCK:  Alright. Let’s go ahead and do the picks now. Joe, why don’t you start us off? JOE:  Alright, cool. I have three picks today. The first one is I’m going to pick my current employer Domo which I’ve picked in the past because they’re an awesome place. And I think when you come to Utah and look at employers, there are very few employers that really do as well to treat their employees and take care of them as Domo does. But I’m picking them because I am going to be leaving Domo and going off on my own to author full time for Pluralsight. So, I’m really sad about that, really sad to be leaving Domo and a lot of the smart people that are here that I’ve worked with over [inaudible] my time here. But I’m also, at the same time, going to pick Pluralsight because I feel it’s an awesome company. I’m training developers on how to develop is a really great thing and something that I enjoy. So, I’m excited I had the opportunity to go and spend my time, full time, authoring video training for Pluralsight. So, that’s my first pick. My second pick is going to be the game Game Dev Tycoon. It just barely came out on Steam [inaudible] for a little while. It’s a really fun game, it’s quite simple. It’s a strategic simulation game that you’re running on a game development shop. It’s really quite fun. But the cool thing about it was back a few months ago before they released their game, they created a modified version of their game and rampantly released it on all of the bit torrent sites. In that version of the game, after you played for a while, the piracy would go rampant and you won’t be able to make any money on your games. It would just basically destroy the game that you’re playing because of all the piracy. And they did that release to about all these piracy sites so that the people that are using the pirated copy of their game were like, “I played this game for a while, it was really fun. And then now it sucks because of all these piracy.” CHUCK:  [Chuckles] JOE:  And they were like, “Is there a way to research DRM or something?” It was really fun and clever. Just one of the most clever things I’ve ever heard of a game. MERRICK:  Yeah, that’s awesome. CHUCK:  They want to troll the internet. JOE:  Yeah, they totally trolled the internet. And then my last pick is going to be a new comic that just came out from Dark Horse Comics. I’m not a comic guy, but I am a Star Wars guy. And so, Dark Horse Comics has just released the first of an 8-episode comic book called ‘The Star Wars’ which is based on George Lucas’ original rough draft screenplay for Star Wars and not the actual screenplay that got made into a film. And so, in this one, so many things are different. Darth Vader doesn’t wear a helmet and Han Solo was green and Anakin is not Darth Vader. And the Stormtroopers have lightsabers. It’s really crazy, very different but very interesting. So, I’m super excited. I just bought it last night and I just barely started reading it. So, I’m super excited for that. AJ:  I’m going to drop this because you have to leave the room and you can’t debate it, [whispering] Star Wars isn’t very good. [Laughter] JOE:  You and I are going to have to have words [inaudible]. [Laughter] CHUCK:  Is that force grip? AJ:  Yeah. If you hear, “Jamison, stop breathing”, that was me. [Laughter] CHUCK:  Alright. Merrick, what are your picks? MERRICK:  I have three picks today. The first one is a book that I’ve had for many years actually. But it’s one of those books that was written for Flash. It’s called Actionscript 3.0 Animation. It’s written by Keith Peters of bit-101. But if you’re wanting to explore the use of geometry and trigonometry to do interesting animation, the book is relatively portable to JavaScript with Canvas. So, that’s one of my all-time favorite technical books. Two is an Angular conference that Joe and I and a couple of other guys are organizing. It’s ng-conf.org and we’re getting close to releasing the full website with all the details. JOE:  Ticket sales. MERRICK:  Yeah, and ticket sales. JOE:  Tickets are going to go on sale on the 16th of September. So, get ready. MERRICK:  And then, last but not least is one of favorite bands Sigur Ros has their latest album. Honestly, I don’t know how to pronounce it because it’s a [inaudible]. But the music is just wonderful. So, those are my picks. JAMISON:  [Inaudible]. MERRICK:  Let me tell you, it’s so good. CHUCK:  Alright. AJ, what are your picks? AJ:  I’m going to pick MakeMeASandwich. Somebody wrote in an NPM module that uses PhantomJS which for those who don’t know what that is, it’s basically headless Chrome where you can inject script into a page and then do whatever you want. So, they’re written in an NPM module, that you can NPM install, and makemeasandwich or npm install-g makemeasandwich. And then, you can run the command makemeasandwich and it will do all of the necessary steps to order your sandwich on the Jimmy John’s website. And that made me so happy inside. Sleep, I want to pick sleep because it’s so good when you get it. [Chuckles] CHUCK:  Very nice. Jamison, what are your picks? JAMISON:  I have three picks. The first pick is JekyllThemes.org. I just had to throw together a blog recently. I have no design sense, but people that do have design sense made themes. So, they put them on JekyllThemes.org. So, it’s sweet. There’s 10 or 15, there’s not a huge number but they all look really good. They’re just for styling Jekyll-based sites. My next pick is something that I bought two years ago but I have never gotten around to reading it until now. It’s a book called ‘Growing Object-Oriented Software, Guided by Tests’. And it’s these two developers that go through step-by-step how they write a Java app [inaudible] on options. But the main value is just in seeing their workflow just over and over again, how they test this app from end to end and unit test and everything. JOE:  Oh my, gosh! That’s a good book. JAMISON:  Yeah, I’m loving it. It’s really good. CHUCK:  I know that those guys do podcast appearances. JAMISON:  Yeah, they’re on Ruby Rogues I think. CHUCK:  Yes, they were. That’s how I know. JAMISON:  Yeah, I’ve heard of it. It’s super good. My last pick is also a book that I started reading again. It’s A Canticle for Leibowitz, it’s one of my favorite science fiction books ever. It’s written in the 60’s about the world hundreds of years after the nuclear war. And there are these religious orders that have sprung up around these random engineers’ notes that they found and had turned them into a saint and copied down all those blueprints and made them illuminated manuscripts and stuff. It’s really good. It’s a great read. So, those are my picks. CHUCK:  Awesome. I’ve got a couple of picks. I’m really excited because I’ve been working really hard on getting DevChat.TV actually up and running. And I’m probably going to be, over the next month, moving all of my shows over to it, all four of them. And so, I’m just super excited. So, I’m going to pick that. This show comes out in a week and I’m hoping to have at least one show moved over by then and have all the kinks worked out. So, I’m excited, excited. You know, I think I’m just going to leave it at that. [Chuckles] Nicholas, what are your picks? NICHOLAS:  My unintentional pick is Thinking Fast and Slow since I mentioned it, really a fantastic book. I think that the more that you understand how you think about things and how other people think about things, the better you can make decisions to optimize for that. It’s one of the most insightful and interesting books that I’ve read in a really long time. Next, I’m a very big fan of things on the internet that just make me smile. And one that came up recently was on the Colbert Report where he danced to Daft Punk. I don’t know if you guys have seen this but it’s quite possibly the most awesomest 8 minutes of television I have ever seen in my life. And during the week that it came out, you could have found me dancing around the Box office just because I couldn’t get it out of my head at all. Really, really awesome piece of video, and now internet lure. There’s actually another one that I found this morning that also made me smile because I love acapella music. There’s this group, Pentatonix that was actually on this TV show called The Sing Off which I think they’re not making any more of which is unfortunate. They did a YouTube video of the Evolution of Music kind of following up on the Evolution of Dance Craze from a few years back. And they just went through starting with monk’s chanting all the way up until modern day with little pieces of a bunch of songs. I thought that was just really awesome. That is my last pick. CHUCK:  Alright. JAMISON:  Sounds really cool. CHUCK:  Yeah, Pentatonix was fun to watch on The Sing Off. My wife and I watched that show together. Well, let’s go ahead and wrap the show up. Thanks for coming, Nicholas. It was terrific to talk and I’m really excited to do it again. NICHOLAS:  Thanks for having me. JOE:  Yeah, thanks very much.

x