JavaScript Jabber

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

Subscribe

Get episodes automatically

028

028 JSJ Greenfield vs Brownfield Projects


Panel

Discussion

Picks

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

JOE: Listen baby, it won’t get weird. JAMISON: [Chuckles] AJ: That sounds… weird. JAMISON: [Chuckles] Too Late. [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net.] [This episode is sponsored by Harvest. I use Harvest to track time, track subcontractor’s time and invoice clients. Their time tracking is really simple and easy to use. Invoicing includes a ‘pay now’ function by credit card and PayPal. And you can sign up at getharvest.com. Use the code RF to get 50% off your first month.] CHUCK: Hey everybody and welcome to episode 28 of the JavaScript Jabber show. This week on our panel, we have AJ O’Neil. AJ: Yo, yo, yo comin’ at you live from the second story of an office base in Orem, Utah. CHUCK:  We also have Jamison Dance. JAMISON: Hi, I’m Jamison Dance and I am super excited, because today iTV just announced that we are doing the Nintendo TV thing; and I haven’t been able to talk about it for, like, six months, so it’s a good day. CHUCK: Cool. We also have Joe Eames. JOE: Comin at you semi live from American Fork, Utah. CHUCK: And I am Charles Max Wood from devchat.tv. Tim is not with us this week because he is in China. I thought I’d point that out, because I think it’s cool. Anyway, this week we are going to be talking about Greenfield versus Brownfield projects. It was kind of funny when we were getting ready to do this, some of the panels were like, Green/Brown? JAMISON: Yeah, I have to pull Josh Susser and ask for a definition. CHUCK: So, as far as I understand it, there are some new — to this, depending to who you talk to, but mostly, Greenfield is a brand new project with few or no decisions made and no code written for it yet. And Brownfield projects are effectively older applications usually associated with legacy code. You know, so it’s an application that already has code written toward it. Typically, it is out there in the world doing whatever it is supposed to do. JAMISON: Now, I want to put this question delicately. Are there any fecal connotations to the color ‘brown’ in Brownfield? CHUCK: Only if it’s PHP. JOE: [Chuckles]. Then it’s Poopfield Development? CHUCK: [Chuckles]. Okay, we are not gonna go down that tangent. [Laughter] AJ: Because, I mean honestly, when Mormons make jokes about crap, it never sounds good anyway. CHUCK: Yeah. So anyway, how many of you guys have actually worked on a real Greenfield project? Like been there from day one, that you have it just built yourself. JAMISON: I guess it depends on your definition. Maybe. So we have lots of services at ITV, so I’ve been part of spinning up completely new services that didn’t exist. We had other sort of similar things already, so some of the decisions were already made for, so we kind of had a style established. But it was still like a separate project. AJ: Do you forget us so soon, Jamison? JAMISON: [Chuckles]. AJ: You don’t remember ever working here or getting started… JAMISON: I do. I don’t remember Greenfield stuff; I remember new features, I mean, we were building off existing code or do I misremember? AJ: Well, what about the map? Tell me? JAMISON: Yeah, that was a feature on top of an existing code base. It wasn’t like a whole new project, it was just a whole new feature. CHUCK: If you can’t tell folks, that was a bad break up. [Chuckles] AJ: No, it was a good break up. JAMISON: No. We still hug, every time we see each other. AJ: Yeah we do. I love Jamison. CHUCK: So Joe, I am a little curious if you would count a new web service inside of an existing eco-system a Greenfield project? JOE: Well, I think that really raises one of the more interesting questions about Greenfield versus Brownfield development which is, you know, your description, things where there’s been no decision and is green, and things where the code base is older is brown. I think that leaves out that big huge chunk, which is probably what most people work on; which is projects that are being built, but decisions have been made and, now you are in the middle of that and dealing with ramifications of the decisions that were made, and all the code that’s been written and then still trying to build upon it. So, services inside of a bigger project, like what Jamison was talking about, we’re you’ve actually already made some decisions, I think falls in that category, so is that green or is that brown? CHUCK: That’s a good question. For me… I don’t know. It’s hard, because you come into a Greenfield project, but you come in at a later stage. Is it still Greenfield? I don’t know. JAMISON: So, if you mix green and brown, you get like… CHUCK: Camouflage. JAMISON: Camouflage. Okay. [Chuckles] JOE: We are pointing at camouflage field development. JAMISON: Yeah. CHUCK: Camoufield. [Chuckles] JAMISON: You have a problem where no one can see your projects. JOE: So you know, some decisions have been made and some haven’t, right? That’s an interesting place to be, where you can make decisions still, but you are not just refactoring or bug fixing, track legacy code, but you are building. And that’s a really interesting place. And I think that’s where most people live the majority of their coding lives is in that realm. CHUCK: Right, that makes sense. Yeah, I think some of it just depends on the developer as well. I mean, if you are the person kind of making the decisions as you go along, then it may feel more like a greenfield project, where if you are being exposed to code that somebody else is writing, and making the decisions on, then it’s probably more of a brownfield project for you. JAMISON: That’s actually a really good point. To some people, every project they work on is a Greenfield project, because every decision that’s been made can be thrown out and made their way. CHUCK: Yes and no. I think that to a certain degree you are probably right, but I think to another degree I have to say that, it seems to me that at a certain point, you are dealing with the older app, the ecosystem that you’ve built. And so even when you are adding new features and making new decisions, you are still dealing with the legacy code that is already there. JOE: Yeah. AJ: So here, I was the third person to come up. So the only code that had been written, like application code, was written by electrical engineers, was not the best code — of course not to say that my code is the best code, but it was better. CHUCK: Having been an electrical engineering major. Ouch. [Chuckles] AJ: Well, anyway, so I had the luxury of kind of being able to take command, and everybody that came on, came after me. So the whole in the software team has kind of got a little bit of my footprint in it and it was fun to be able to throw away the crappy code and redo it. But it took a lot of time. CHUCK: Yeah. So how do you deal with the legacy code? How do you manage that stuff? What’s your approach, AJ? You come in, you find a code base that isn’t beautiful and you want to make it maintainable and solve some of the problems that are there, what do you do? AJ: I think there’s two kind of approaches; one is to get the existing code to be more like the API that you want it to be, externally, you know, whatever little pieces it’s going to have to interact with. And the other is the opposite way around; build some new code the way that you want it to be, but then put like a shim layer in there that interfaces in the backward way. CHUCK: Ok. AJ: Does that make sense? CHUCK: So basically you maintain the API and you basically add a translation layer to the more usable code. AJ: Yeah. You know, like, so as you refactor, just keep some stubs for the backward stuff in there until you are done with the refactor and then, you know when everything is working, you pull it out. CHUCK: Yeah. I think Joe and I will agree that there’s something else that you should do with your legacy code as you refactor it. AJ: Document it? CHUCK: It’s a type of documentation. JOE: Yeah. JAMISON: Oh, it’s  a guessing game! I know this one. Hungarian notation for your variables? [Laughter] JOE: Getting warmer. CHUCK: Yeah, you should put tests around it. At least characterization tests, so you know what it does. And then from there, you can modify it without worrying about whether or not you made critical changes to the API or critical changes to the results that you get out of it. JOE: So there is this excellent book written by Michael Feathers. It’s called ‘Working Effectively with Legacy Code’, where he talks through the process of adding… basically being able to change legacy code. I don’t know how many of you guys have had this experience (I am sure Chuck has) being on a project where you got this large portion of the code — if not, all the code – that you are just afraid to touch, because you have no idea what might break in the entire system if you touch one piece of code, because of how coupled the code might be. And so this book has techniques that work all the way from those really extreme circumstances all the way down, to just, you know, “Hey, we wrote this six months ago, but we want to make some changes and we just still haven’t refreshed our minds anymore.” And so it’s a process of adding tests around your code. And he has all kinds of methods of dealing with even the worst, least testable type of code and the least testable types of languages in that book. It is an excellent, excellent book if you are working with very brownfield type development of code that you are afraid to touch. CHUCK: I have to point out; you said that I probably had projects like that. I just want to correct you, I’ve built projects like that [chuckles] where you know, you have that section of code and every time you try and add something to it, something else breaks. And it’s just like, “Argh, how do I get out of this mess?” JAMISON: I’ve read part of that book, not the whole thing. I can only make it halfway through a book and then I have to start a new one. It’s a bad habit. But he has an interesting definition where he says that legacy code is just code that isn’t under test. JOE: I absolutely agree with that. JAMISON: That’s kind of an extreme position I think, but… JOE: We all know extreme is better… [Laughter] JAMISON: That’s true, yeah. Mountain Dew has taught me that extreme is better, so I really meant to say that that’s a better position. [Chuckles] CHUCK: But it’s funny that you say that it’s an extreme position, because it sounds like you are saying that it might be a little bit too far down the spectrum. JAMISON: I am a testing skeptic. I also have a lot of guilt about it because I don’t do it as much as I should, but so maybe I am skeptical about it to make myself not feel as guilty. CHUCK: Yes, because I tend to see it the other way and I am not sure it goes far enough, because I’ve seen code under test that I would call legacy code and it’s not just because the tests weren’t up to snuff. The code was just ugly; it was hard to work with. JOE: Right. So we had an interesting experience here at Domo. I brought like five of the front-end engineers with me off to the Utah Software Craftsmanship User Group. And for a lot of them, it was their first exposure to a group of people that were heavy believers in pair-programming and test-driven development, and you know, all the typical Agile practices and refactoring, to patterns and things like that and… AJ: Joe, I just want to let you know that you can come here when you have your time now, just sign up. CHUCK: [Chuckles] JOE: Thanks, thanks. So it was a very interesting experience because there’s these five guys that showed up and then their thoughts afterwards, about you know, test-driven development and code craftsmanship. And for people that ‘haven’t drunk the Kool-Aid’, you know, really done some good test-driven development for a long time, paired for a while, it’s funny because you just don’t see the benefits the first hour. It gives you benefits in scenarios that just can’t be covered by a tutorial that has code so simple, that people can understand it in a single article. But when you get into something big and heavy and all of a sudden your test is just saving your life and the other guy sitting next to you that is patching the code that you are writing, is keeping you from making mistake after mistake that pays off six months from now, eight months from now, not tomorrow, but pays off, you know, down the road. That’s when you know, you get those benefits and you get the people that really truly understand and believe how beneficial those things are. And that’s really one of the hard things to do is to teach somebody; if they don’t spent six months doing it, I don’t think they have an easy time seeing the benefits. You can talk about it all day long, but it’s hard to see. So I agree with Michael Feathers’ definition that legacy code is code without tests; code that is not under tests. JAMISON: So, I had a thought while you are talking and that’s how conservative… so if you are doing a Greenfield project where someone has an idea of what they want made, but it’s not really decided how it gets made, how conservative or crazy should you be with your technology choices? I mean, relative to your own experience. So should you start up a new project using, like, some framework you’ve never done before, because you heard it was cool. So, how do you decide how much new stuff to use or how to just use the same thing already that you’ve already used? CHUCK: So, that is a good question. And I think it’s going to vary for each of us. I am just going to start it off, because as a freelancer, obviously, I want to make the less risky choices. JAMISON: You don’t want to do “resume-driven development?” CHUCK: [Chuckles] JAMISON: Pick the coolest thing, so it looks really good on your resume. CHUCK: If I do, I am going to make few projects of my own at first, before I go and try and sell it to a client. And that’s exactly the point, right? They are paying me a premium to be an expert in whatever it is I am doing. And so I should be choosing technologies that will give them the most value. And so that’s kind of the way that I feel. If you are in a situation where somebody is dictating the technology to you in one way or another, either it has to be able to handle this kind of traffic or these kinds of requests or things like that, then sometimes you can get away with picking a technology that looks cool, that meets requirements. I mean, for the most part, that’s not the case. I think if you are in a corporation and things like that and they are satisfied with the risk, then you can take more risks. So, I don’t know if you guys have a different take on that; being employed at companies as opposed to being employed by clients. JOE: What do you think, AJ? AJ: So, I don’t know. I am kind of a bad person to ask, because I came in to a startup company as a 3rd person. I just pick stuff I liked and I said ‘let’s run with this’ and some of those choices turned out to be good and some of them, you know, had their drawbacks. And so I mean, like professionally, I am not quite as old as you guys. Well, I am not quite as old as you guys anyway. [Laughter] CHUCK: Thanks for that. JAMISON: Maturity. AJ: Exactly. So… JOE: Next time I see you, I am going to run you into my rascal. AJ: Run into your what? JOE: With my Rascal. AJ: What’s a Rascal? JOE: You know, little powered chairs that you see your grandparents in… AJ: Dude, I am not old. So anyway, in most of the jobs where I have been, I have been able to start new things, I mean that’s one of the things that’s very interesting to me; that’s what I look for. So my first job at BYU,I had to work a lot with legacy code. And one of the terrible things about working at a university — I would imagine at most universities — is that it’s people who don’t know what they are doing, picking up code that someone has worked on for the six months who didn’t know what they were doing, whose professor didn’t know what he was doing, because he’s never worked in the field but he’s got a PhD, you know? CHUCK: [Laughs] This sounds very familiar. AJ: But then in terms of real jobs, like I’ve always been in a position where I’ve had that opportunity. I would value your opinions. I mean, you guys have done a lot of freelancing and working around, so answer the same question. JOE: Go ahead, Chuck. JAMISON: Chuck already answered it. CHUCK: Yeah, I already answered it. What do you think, Jamison? JAMISON: I think you have to take risks somewhere, but it just depends on the downside. That’s a really vague answer. So if you are working on something that is, like, mission critical, makes your company tons of money, you probably want to be a little more conservative. If you are doing something that is helpful and useful and cool, I mean, hopefully you wouldn’t be doing it if it wasn’t helpful to your company. But I mean you kind of have to pick your projects that you are more able to experiment on, I guess. I do it sometimes, but on smaller projects. JOE: You know, I think that a lot of what is important when answering this question is gaining exposure to technologies so that you can make wise decisions. Like there are times that even when on a ‘mission critical’ piece, you can choose the wrong thing, because what you are comfortable with doesn’t cover the domain space well. And I will give you an example. A company I know of was doing a web chat client, and they wrote the server in C (C++), that’s because that was what the engineer knew, so he wrote an actual web server in C — from scratch. CHUCK: Oh, man. [Chuckles] AJ: That’s funny, actually. CHUCK: I mean, it would be an interesting project, don’t get me wrong. But there are things out there that already do the job — and do it better in what you can write in a few months. JOE: Right. So think of a maintenance cost with something that is a solved problem, so or so, you know and if you knew about Node…  most people consider Node to be very bleeding edge, most companies won’t allow any production code; like Domo here we are a fairly forward-thinking company and even now, we still don’t have any production code that runs in Node. But that’s just an obvious superior choice. So, even if you are a C programmer, if you don’t know a thing about Node I got to say that I think at that point it’s a mistake to say, “I am going to write this and see,” and not to just should pick up and learn Node. It’s not that hard. AJ: I totally agree with you there. I mean, not even Ruby is as simple for the networking and HTTP stuff as Node is. CHUCK: I think ultimately what we are talking here about is risk. And so, if there’s more risk in going and trying new technology, then you have to do at least some research in order to know that, then don’t do it. But if there is less risk, you know, you go out and you figure out ‘Okay, Node does these kinds of things really, really well’, then, you know there’s more risk in sticking with what you know, than there is with taking some time to learn Node. And I think the other piece is that usually, we are building software for stakeholders, other than ourselves. And if that’s the case then we need to be able to accurately represent to them “Hey, look. This is the direction we are gonna head in. This is why we are going to do it and this is the overhead that it’s going to generate.” And in that way, they understand the decision and they understand why the tradeoff is actually a favorable one. JOE: Yeah. And so kind of going back to that point about exposure; if you don’t understand the technologies that are out there and what they are good at, and what they are not good at, then you can’t make that decision. So exposure, I think, is an important part of being a professional developer. Even if you don’t work in Node and you don’t think that you will ever work in Node, at least spend enough time to understand why people are using it, so that when the perfect project for that comes along, you know why people are using it. MVC frameworks are another good example; there is 8 of them and they are practically clones of each other for many respects. So if you know one well, you’re probably not making a poor decision by using it instead of another one. CHUCK: You’re right. JOE: So, but you know one well, if you just have been doing JavaScript, if you never had been using an MVC framework and now you realize you are going to be building your first keys in JavaScript that’s bigger than 60 lines of code and you are worried about maintaining the code and organizing the code, you don’t know anything at all about MVC frameworks, then you are not fulfilling your responsibilities as a developer to your employer — in my opinion. CHUCK: I agree. At the same time, I think they should also be providing you with the opportunity to learn those things even if they aren’t directly applicable to the problem you are trying to solve. JOE: Yeah. So you got the companies that serve you as well as you serve your companies. So, if you are the type of guy that really wants to stay abreast, because that will serve your company, work for a company that supports you on that. JAMISON: So I have a theory about that. There are people who are really into learning new things and they are going to do it whether you let them or not. And if you don’t let them, and then they are going to do it on production stuff. So, there’s a lot of value in letting people… either giving them, like developer time or 20% of the time, stuff like Google does or training or whatever or being open to doing crazy stuff on production code. JOE: So, Bob Martin has a book called, “The Clean Coder,” where he talks a lot about professionalism. One of the things he states in his opinion is you give a good quality 40 hours to your company and then you spend another 20 hours afterwards sharpening your axe and honing your skills. So, he kind of takes the responsibility off the company to do that. Now, I think the company should support you with, you know, paying for education materials and conferences and things like that. I think that’s the mark of a good company. But I also agree with Bob Martin, that there’s just not enough time; 20% time would be really nice and most companies don’t provide that. But I think there’s just not enough time, you should be doing stuff on your own to stay abreast of what’s going on. CHUCK: I completely agree. It’s just that if the companies understand the value in that, then they should invest in it. Now, if they are not going to, then absolutely, you know, ultimately it’s you responsibility to train yourself up and you know, learn what it is that you need to learn in order to do your job. JOE: Yeah. Here in Utah, there is like, less than 1% unemployment in software developers. So every time I meet with a software developer that is stuck at his job, and can’t get a new job, I just shake my head because you almost have to work hard to make your skillset so obsolete that you can’t go and find another job in a week. CHUCK: That’s so true. AJ: Yeah, there is definitely a good market around here. It’s so hard to find people, because there’s so many companies vying from the same group. JOE: Yeah. And there are places in the world and another country where that’s not true, where you are in a smaller towns that only have so many places that pay for developers; so, it can be less true in other places, but I’d say that the majority of the country, being in a software development field is a good thing to be in, because it is not hard to find jobs if you keep your skillset up. And if you don’t, you are killing yourself; you are killing your future. You got to keep up. CHUCK: The other thing is that… I bet you guys can guess how many of my clients are actually local clients. None. None of them are local. And so even though the market is so good here for developers, you know, there’s a ton of remote work out there, you know, just gobs of it. In just about any technology you care to work in to. And so it’s not unheard of for people that find the work that they want and not even have to leave home to go do it.  But anyway, we are kind of getting off on a tangent here. So, what kind of decisions do you make when you are going after a Greenfield project? What decisions do you find yourself making, Joe? JOE: Well, obviously just the actual toolkit that we are going to use is a big one. And I think another nice thing about Greenfield development is that it’s tolerant to more risk. So that’s the time when you can look and say, I am here at this particular tool, this particular framework, this particular libraries are better than things that I’ve used in the past, so for this greenfield, we are gonna start here. CHUCK: Right, because you don’t have to refactor around existing code. JOE: Right. But I think another important decision to make when you are doing greenfield development is write from the start; put your engineering practices into place; put together your continuous deployment, put together your continuous integration, put together your automated unit tests, so that you don’t have to pay that pain some time later on. So that’s another decision that’s made right up in front is, what engineering practices are you going to embrace in your development. And then, on top of that, merging the two is… if you are going to choose jQuery or whatever, try abstracting your toolkit choices, your framework choices as much as possible, so that if it turns out you made a mistake, especially when you are trying something new and you are not 100% sure, as much as possible, try to abstract it inside and put another layer between your code and that code, so if you have to swap it up for something else then you can. — and jQuery I believe are really, really comparable feature set. And it’s not hard to write an abstraction layer around that, so that you can — jQuery up and put new tools in, if you still find that just jQuery isn’t working out for you. CHUCK: Yes, absolutely true. It reminds me a little bit of the ‘Growing Object Oriented Software Guided by Tests’. Have you read that? JOE: Yes, yes. CHUCK: And they talk about all that stuff where you set up your continuous integration, you set up your deployment and you actually test it and you make sure that it all works as part of getting started in your new project. And it just makes a lot of sense to me, because then you know exactly what your constraints are before you really start making the big decisions that are going to kill you later on. JOE: Right. CHUCK: So, with brownfield projects, let’s say that it is legacy code and then it is not tested. Do you pretty much follow the prescriptions that Michael Feathers lays out where you write a characterization test, then you refactor the code and then put more unit test in as you go? JOE: My experience has been that’s more up to the tolerance in the company that I work for. If they have a real [inaudible] to fix your technical issues, or if they don’t, it determines whether or not… if they do, then yeah. And actually we have an interesting situation going on here; Domo is very applicable to this. We have a large set of untested client side code written in Backbone – just kind of plain Backbone. And as we all know, Backbone is so unopinionated that what every developer’s version of Backbone is entirely different. So we have 30 versions of Backbone implementations written and all those code is definitely less maintainable. Not terrible, but it’s bad enough that it is causing issues. So we started an internal project just to migrate the client side code over to something cleaner. And so we were writing a new framework based on marionette to do that. And we are starting to have at least a primary engineer on that, who is not me. He is turning up some second thoughts about we’re kind of taking this Greenfield approach where we created a new framework and a new structure and then we have to migrate feature by feature from the old code and the old structure into the new structure. And he is worried that the company is just going to get a 3rd of the way into that and then be too driven on building a feature and going to leave it and that’s going to be worse because now, there is two ways of doing that. Even though the old way sucks, it’s going to suck even more, because there is still the old way and all its variations, plus now one more way; the new way. AJ: Yes, it’s super hard when you are trying to refactor and provide new features at the same time. JOE: Yeah. JAMISON: Wait, we did that. How did that happen, AJ? Didn’t we have this whole huge rewrite of lots of back end stuff while I was there, but we were also adding new features. JOE: Yes, so this is not a V2.0; this is a V1.1, right? Where you are just cleaning up technical data. What would you guys do at that situation? AJ: So, again, I mean keeping API compatibility or little shims in place is what’s been important for me and then continuing to add tests, definitely. CHUCK: Yes, I really want to drive that home, because the only way that you are going to know that you your shim API is compatible is through the test. So that is just something to be aware of. But yes, I really do like that approach where you can maintain the API and then maybe maintain a new API and the old API until you have the chance to phase out whatever system you are going to be implementing on the new application. AJ: And then obviously, you want to [inaudible] an abstraction layer in both pieces of code as quickly as possible with the areas that you have to add a new features, so that you can easily bring the new features over. So whatever it is that you have to have new features, that the place where you got to work first, because otherwise, when you go to merge in the new features, then there will be conflicts and crap. JOE: So, let me kick in what my input was as we were going through this process, our primary engineer worry about what’s going to happen. This is the actual conversation that I had with a local developer here who is a really strong software engineer. CHUCK: May I ask who that is? JOE: Yeah, David Adset. CHUCK: Ok. JOE: He is very active in a local software craftsmanship user group and a big blogger over at pluralsight. Anyway, the input that I am giving is that we still should go with the greenfield in this situation, because if we do brownfield, we have funny issues like we are using AMD but people are relying on global jQuery and global backbone instance, so they are not actually declaring it as dependency, because it has been potentially modified and had like… for jQuery had add-ons put in and now their code relies on it. So it’s funny things like that. So there’s these pieces of the code that in order to fix, we’d have to change something that would touch all the code across the entire board. And so if you change those things, now you have to do the full regression test on the entire site to know that change is right. And you would want to make those changes incrementally, you don’t want to just sit down and say; “We’re just gonna spend a month, clean up the old code and check it in or see if it works until the end of that month.” That’s a failed practice, so you have to do it incrementally. So if you do a Brownfield where you try to clean up just pieces at a time, you have to regression test the entire system. So instead, if you migrate feature at a time, then now you only have regress that feature. Even if you have your unit tests in place, you still have to manually walk through a feature to truly know that it’s correct. Unit tests are not an assurance of 100% correctness. So, after you migrate the feature over, you don’t have to regression test that feature and make sure that feature still works. The risk of breaking the rest of the code, because you’re moving code into something new, is very minimized and So that was my feedback is to go with the Greenfield anyway, because it lets you know that what you are doing is correct, whereas brownfield, it’s just a risky, in these two approaches. Calling them “green” or “brown”, they are not really that clear, but it’s just risky to try to touch something that might affect a large percentage of your application and might break it and have regression test over and over and over again. The cost of regression testing, because it has to be manual, is just too high. JAMISON: So, we’ve talked about API compatibility and regression testing and making incremental changes. I am working on a project right now that is a lot fuzzier than that. I mean there is an external server API that is really simple, but there is lot of changes to make in the client side code, because it is organized in basically just script tags that get put in the head and changing that into a model system isn’t something that you can do incrementally; you have to do it all at once or it will just break. So what about stuff like that where it’s something that will take some effort and you can’t do it incrementally. AJ: So I am a little curious about the implementation you got there, because I would argue that when you have the script tags, you can still put in a little bit of a shim, so that is incremental; like you can have your require function have access to the globals, and then start replacing the assumed global with requires one at a time and until they are all out there and something like that. So tell me a little bit more about that. JAMISON: It actually makes sense. I guess I just didn’t think it through very well. So you are saying that you could convert all the code to individual modules, but you wouldn’t use the RequireJS require function; you would make the require thing, just like look the variables. It’s kind of like what Tim talked about couple of weeks ago with your own require syntax is that, or with your own define function module thing. Is that what you are talking about? AJ: Yes, exactly.  So you could still use your RequireJS or Browserify or pack manager or whatever, right? But then, you just put in a script that right after that overrides the require function, give it like some composition, so that if it doesn’t work the way you want it to already, then it will search in the global. And when it does the define or the provide, then it also exports whatever you need out to a global as well and then you can have your code both ways. JAMISON: Sure, that makes sense. AJ: And then, you know, so you just hunt down the places in the code where you’ve got the global, little by little (one script at a time) until all of the globals have been replaced with requires and then you take out the shim and then test to see if it works. And then you do the build process and test to see if it works. CHUCK: Right, so I am going to change the subject here, unless there is something else we wanna riff on with what we are talking about. AJ: That was a pretty awkward silence. JOE: [Chuckles] I want to stick in a little comment on that and that is, lots of times, you can do incremental approaches if you start really thinking a little bit outside of the box. And I’m kind of like defeating my own argument here when I said, “Do the greenfield because the brownfield has these higher risks in our situation.” And we’ve thought about certainly some out of the box situations to try to make some incremental changes — incremental and safe. So there certainly is times when you think that things are hard, but if you think a little outside of the box, you can actually find ways to make them incremental. But I think that comes down to horizontal changes that affect a large percentage of your code base. If you cannot make those and instead make vertical changes where you fix a feature at a time, you know one piece at a time… and basically what it comes down to is making changes to your codes that are likely to only affect a small portion of the code, rather than something of a very cross cutting concern. If you can do that, then that’s better — much, much better. JAMISON: It sounds like what you and AJ are both saying is that if you are sneaky enough and clever enough, you can find some way to do changes incrementally — even it doesn’t seem like you can at first. JOE: Well, it’s nice to say that, but there’s definitely situations where that is just not true. You know? CHUCK: Yes. JOE: You have to try as hard as you can, but you are going to find some situations where you cannot make your own rule. I mean this isn’t like, “Hey, every recursive algorithm can be built in a non-cursive way,” this isn’t like that rule. You can say most of the time, probably more times than people realize that’s true, but certainly not every time. There are times when you have something foundational. It’s just so hard. But it’s like switching from Backbone to one of the other MVC frameworks you’d think, “Oh, I got to tear it out, it’s got to be this big, huge thing. It touches every piece of the code once.” It doesn’t have to be. There are ways out there to play on the same page with Backbone and other MVC frameworks — and they can play together at the same time — even with a single application for Backbone or something else, and vice versa. CHUCK: Yeah, absolutely. So one other topic that I want to cover is that sometimes you get into brownfield projects and you look at it and so, the joke is always about the big rewrite, right? But, you know, when is the big rewrite the correct answer? When do you decide, “Okay, this would be much easier as a whole if we went ahead and turn it into a Greenfield project?” JOE: I think the easiest answer to that is when you can convince the business that it is the right answer  — and it’s not always just a technical question. AJ: When it hasn’t been written 3 times. CHUCK: [Chuckles]. JOE: I mean, there are certain times, like when we are dealing with an SP application, you know, an old legacy technology, something that’s been around for 10 years and you just want to replace the technology, that is certainly a big candidate for a big rewrite. CHUCK: Yes, but if you are replacing the core technology, you are probably going to have to anyway. JOE: Right. But although, again, there are ways to do that with ASP and ASP.NET. There’s ways to make them play inside the same website and it is hard. There are ways to do that and that incremental approach is safer. Uncle Bob is on record as saying, “I’ll never make the big rewrite. Never make Version 2.0. Always incrementally fix it.”  And he is talking about situations where they have taken 20 year old systems, that were embedded systems running on crazy machine and rewritten them in current Python type stuff and they still do it in an incremental manner. JAMISON: I was going to bring up Joe Spolsky article, I have no idea how is his name. Lots of S-es and P-s. That guy, anyways, his article about the Netscape rewrite and how that killed them, because it allowed Microsoft time to create Internet Explorer and eat their lunch. And then so he is also on the record about never, ever completely rewrite your code. And there any counter examples of people who have done complete rewrites from scratch and had wild success? CHUCK: I can’t think of any. I mean, even like Digg did a big rewrite and switched over to Cassandra and a bunch of stuff and…. JAMISON: Yeah, but Digg was dead before they did that rewrite. CHUCK: They were close, but that just finished them off because then they were focused on the rewrite and not on actually making awesome software. JOE: I can’t think of any examples. CHUCK: I can’t either, honestly. JOE: That right there is pretty telling — very telling. CHUCK: So, are we saying that it’s never (I hate using absolutes), almost never appropriate to do a complete rewrite? JOE: Probably less often than most people think. I would say. If you think you need a rewrite, that’s like code smell. That’s a smell and you should really, really look closer at that if you think you need a rewrite. JAMISON: So I think, that, to be fair, you can say that when you are done the code will end up looking nothing like how it started, but you are not doing that by throwing it away; you are recreating the system from scratch. It’s like, you could replace every single line in your application, so that there is none of the old code, but doing it incrementally is safer than throwing it all away and rebuilding the app from scratch. AJ: I would argue that sometimes it’s better just to scratch it and to start it over. JOE: Certainly the size of the application makes a big difference too. Talking a one man month versus you know… then, one man month is a lot safer than just throwing everything away.  But, so size makes a big difference too. But who wants to put on their resume that they were the lead architect on a project that canceled six months in? It failed because as developers, we’ve got to consider what the business is likely to do, you know? If you tell the business, “We are going to rewrite this in six months,” and you know, you are lying to yourself as well as them that it’s an 18-month rewrite. Then you are killing your business, you are killing yourself. You don’t want that on your resume. CHUCK: Agreed. AJ: So, that’s why you don’t put that part on your resume. [Laughter] JAMISON: You put like, “Lead comprehensive rewrite of the project,” — without the cancel part. CHUCK: Yes. There you go. We went through some of that and honestly, I wish that one of the… one of the companies I worked for anyway, and I wish now that we had actually done something like that, where we had just sat down and say, “Okay, we are going to move this piece off and decouple it from everything else and just make you happy.” Because I think we would have gotten way further ahead by doing that. JOE: Well and it also teaches you a lot of skills about keeping your code decoupled, that you just not have… you know, no code stays greenfield for very long — it gets brownfield really quick. And if you don’t know how to change brownfield code and incrementally change it through techniques, like some of the things we talked about before, you are doing yourself… if everything is, “I can only code if I can start from scratch,” make every decision fresh and not have to deal with any previous decisions and previous code, then you are going to have a hard time finding jobs if you do that all the time. CHUCK: Yes, absolutely. Are there any aspects of this that we need to talk about before we wrap this up? Because we’re about to where we need to do picks. We’ll have AJ start us off with picks. AJ: All right, I actually had some picked up beforehand today. First off, I have been reading this book, called Joseph Smith: Rough Stone Rolling. And it is about the profit of the church of Jesus Christ Latter Day Saints in the 1830s, Joseph Smith. And it’s very interesting book, because I’ve got a lot of material that you come across about Mormonism and the true Jesus Christ Latter Saints is based on proving that it’s true or proving that it isn’t true. And this book is really nice, because it doesn’t really consider whether or not it’s true; it just says, “These are the facts.” Like, this is what Joseph Smith did; this is what the other members of their early church did. These are the things that happened and it doesn’t have that, “Oh, we need to prove that it’s true,” or “We need to prove that it isn’t,” it’s just historical. I really like that.  It’s been very interesting to get… a lot of times, when you get that kind of fairytale perspective, of oh, he was a perfect person who set up the church was just great and everything. And the other side of that was that he was a terrible person who stole young women to marry them. And this was just very… I don’t know… simple and seems accurate and complete — and I like it. Anyway, another thing, Roll up Crepes at State street in Orem; cool place to hang out, especially in Tuesday night, they have an open mic night. Went there for the first time kind of by accident and it was just a chill place. And I just found about this website Calepin.co and it is a Dropbox markdown blog. So you take mark down files, you put them in a Dropbox folder, and then you go back to that site and you click publish on it and then it turns into a box where you can do the C name host thing so you can have your own domain and have it like its being hosted on your domain, if not hosted there. But I like the simplicity of it. You just throw marked down files in a folder. I really don’t like Word Press and some of these other ones, because you have to put it to their system and it’s locked in their system and it’s an ugly HTML that is difficult to edit afterwards. CHUCK: Awesome. All right, Jamison, what are your picks? JAMISON: So, couple of weeks ago I watched a movie called Bernie. It’s with Jack Black and Matthew McConaughey. So it got some famous people in it but it was still one of those film convention movies that didn’t get widely released in theaters. It’s on the ITunes I think for a couple of bucks to rent, but it’s my favorite Jack Black movie ever, for sure. So it’s a funny movie, but he’s not like being wacky and crazy comedy and stuff but it’s based on a true story of a small town mortician that was apparently the nicest man in the world that ended up murdering some little lady. And it’s really funny. It’s a great movie, pretty awesome. So, that’s one of my picks, my other pick is, I do like a video game pick every week. I’ll do another video game pick. DOTA 2. It’s a free to play game on Steam. It’s a PC game. You control this hero and play with teammates to defeat this other team. Its super fun and they just had this giant tournament a couple of weeks ago, with a million dollars in prize money. The winning team got $750, 000 dollars. So, there are like lots of people playing, lots of people watching. And it was kind of scary to play at first, because lots of people are really good at it, but they were very friendly, very welcoming community. Those are my picks. CHUCK: Cool. Joe, what are your picks? JOE: Okay. So, I don’t know if I’ve picked this already, but I’ve read a little series, it’s trilogy that is actually just a single novel broken up three times at Amazon.com. Derrick Storm novels, written by the fictitious author Richard Castle, which is the fictitious author created in the show Castle. So the TV show Castle; it’s about an author played by Matt Fillion and then this fictitious author has published, like, six or seven books and they are all really cool. So, anyway, those Derrick Storm books are kind of a little bit like Bourne, but very awesome books. Then the X-Wing Miniatures game is coming out this week. So I am going to pick that as well. And then I am also going to pick PEX for Fun, that’s pexforfun.com. It’s a sweet site. I just discovered it this week. It’s a Microsoft project, so don’t hold that against them. It’s coding in C#, so another thing not to hold against them. But it’s this website that pulls up and it shows you one algorithm and  it just gives you an empty function with inputs and you don’t really input, the inputs are return type. For most ones, you can refresh the page and get different puzzles. For each one, most of the time you don’t know what the algorithm is trying to do and so you just run it and it will tell you like, “Given these inputs, this is what the output should have been. Whether or not your solutions solved the problem correctly or not.” And so you have to just kind of just figure out what the heck algorithm they are trying to get you to write. So one of them was like an anagram; so put in a word and then a return a Boolean that tells whether or not the word is an anagram or not. And so closing in on that solution is just really fun. It’s just some cool puzzles and really makes you think. CHUCK: So do they just give you an input and output and you are supposed to figure out what the… JOE: They give you a skeleton function. It’s got the inputs declared and the return type declared and you are supposed to fill it in the middle as to how, based on the inputs that’s correct output. And underneath it, it’s just all on the webpage, right? Underneath, they show you, every time you ask it to run, it will take different inputs and show you right for this input, this is what the output should have been and that the solution you have in your window is correct. It’s totally awesome. CHUCK: Right. JOE: It’s awesome. Totally awesome. CHUCK: Sounds cool. JOE: Yeah. It’s  quite cool. They definitely need more implementations in other languages. So, I got one more pick – that is the MLG championship and Raleigh, North Carolina. It happened a couple of weeks ago for the, I believe it’s the group C championship. There was this epic battle between Stefano and I can’t remember the other guy. Do you remember the other guy’s name, Jamison? JAMISON: No, I didn’t watch that one. JOE: Ah, you didn’t watch that one; you are a loser. JAMISON: I am a loser. I am not up to date in my Star Craft 2. JOE: It was this amazing 3-game series between these two players in Star Craft 2. Stefano and this other guy and there was a 6 pool followed by another 8 pool game and it just fantastic. One of the best series I’ve seen in a StarCraft 2 series. CHUCK: MLG is Major League Gaming? JOE: Yes, Major League Gaming. JAMISON: I think I was never a huge sports fan, and I actually like sports more after I started watching ESports, like I understand why people like sports more. CHUCK: Yeah, competitive; lots of fun. Cool. Any other picks? JOE: Nope, that’s it. CHUCK: All right, so I guess it’s my turn. I started working for this company last week. They are a client, not fulltime. Actually, it is fulltime and they are client. Anyway, they are using Tmux and Emacs on these machines up in Amazon and if you’ve used Tmux, you’ll realize that when you connect to a Tmux session, whoever has the smallest window size, that’s what Tmux resizes to. So I had these dinky little monitors on here and so every time I go on it would resize to teeny-tiny. Windows made it kind of hard to do some of the work. And one of the monitors was decent, so I could kind of blow it up a little bit. Anyway, I ordered some new monitors and anyway the deal with the monitors is that they have visa 100mm in the back, and I have these desk mount arms and one of them is I think the LX desk mount, I’ll put a link to the show notes. The other one is a little bit cheaper one that I got off of Amazon. I’ll put a link to that in the show notes as well, because I honestly love having the stands or the arms for it. Anyway, you can get a converter for the visa 75 mm to the visa 100 mm. And it’s just this plate with 8 holes in it. The 75 mm holes are threaded, so that you can basically use the screws that you would use to mount your monitor on there to mount the plate on there and then you just screw your monitor into the mount. So that’s pretty cool. One other thing that I also bought and I am totally loving is this Go Group Blue Sync, Bluetooth Wireless speaker. It has a USB plug in. And it’s really nice. The reason that I have been getting this stuff is because I have an old iPod second generation and it turns out that after you’ve had it for 3 or 4 years and you’ve used it as  much as I have, the headphone jack tends to wear out. So I thought of cracking it open and seeing if I could just solder it back together or find a loose connection in there somewhere, but I don’t really wanna open it up, so I just got this Bluetooth deal. So I got this Bluetooth headphone, then I got this Bluetooth speaker that just sits on my desk. So I can listen to podcasts while I am working. So, I’ll put links to all of that in the show notes, and those are my picks. All right.  We’ll just wrap the show up. Thanks to you guys for coming and thanks everyone for listening. We’ll be back next week.

x