Podcast: | (Duration: 46:01 — 42.1MB)
Panel
- Eric Davis ( )
- Evan Light ( )
- Jim Gay ( )
- Charles Max Wood ( )
Discussion
01:58 – Projects
- Contrast to
06:50 – Labeling and defining a Brownfield Project
- Age
- Decrepitude
08:37 – How to handle Brownfield Projects
-
Upgrading
-
Modernizing
15:48 – Rescue Project versus Brownfield Project
-
State of the Client versus State of the Project
-
Urgent Need
20:02 – Technical Problems Business Leadership Problems
26:56 – Refactoring and Testing
- Show, Don’t Tell (Leading by example)
31:46 – Educating team members
- Correcting mistakes
- Learn how others work
- Lead by example
36:57 – Pushback
- Trying new angles
- Leave the project
- Lower standards
Picks
- (Eric)
- (Eric)
- (Evan)
- (Jim)
- (Chuck)
- (Chuck)
- (Chuck)
Transcript
JIM: Brownfield’s project, I’m just thinking, reminds me of this joke I heard where there’s like a cabin boy on a pirate ship and the captain is always telling, when they are going in to battle, captain turns and say, “Arrr! Get me my red shirt!” And so, you know, they’d go to a battle and every time they go, “Arrr! Get me my red shirt!”
And so, finally, the cabin boy goes to the captain and captain says, “Sir, why are you always telling to ‘get me a red shirt’?” “Well, I don’t want the men to see me bleed if I get stabbed.”
And so, the next time they were travelling through the entire like Spanish Armada comes out and just completely surrounds them. And the captain turns to the cabin boy and says, “Arrr! Get me my brown pants!”
[laughter]
[Are you a busy Ruby developer who wants to take their freelance business to the next level? Interested in working smarter not harder? Then check out the upcoming book “Next Level Freelancing: Developer Edition Practical Steps to Work Less, Travel and Make More Money”. It includes interviews and case studies with successful freelancers, who have made it by expanding their consultancy, develop passive income through informational products, build successful SaaS products, and become rockstar consultants making a minimum of $200/hour. There are all kinds of practical steps on getting started and if you sign up now, you’ll get 50% off when it’s released. You can find it at nextlevelfreelancing.com]
[Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net]
CHUCK: Hey everybody and welcome to episode 34 of the Ruby Freelancers Show. This week on our panel, we have Eric Davis.
ERIC: Hello.
CHUCK: We have Evan light.
EVAN: Today, I have whiskey.
CHUCK: And we also have Jim Gay.
JIM: I am ready to go.
CHUCK: I’m Charles Max Wood from devchat.tv and this week, we are going to be talking about Brownfield Projects. And who says it’s such–
EVAN: It doesn’t sound very pleasant, right?
CHUCK: [laughs] Yeah. There was some discussion before the show about that.
JIM: That term is terrible. I mean–
EVAN: It’s poopy.
CHUCK: Oh geez. [laughs] Somebody has to say it, right?
JIM: Actually before we start talking, I started searching like is there a Wikipedia entry for brownfield? Like, who came up with the term “brownfield”?
EVAN: Well, we can get it in the Urban Dictionary pretty fast.
[laughs]
CHUCK: Oh geez. [laughs] I usually hear it as a contrast to “greenfield” is what I hear.
JIM: Yeah, I’d certainly understand that. I always like I mentioned before, I’d always hear legacy and when I heard brownfield, it makes sense but it just sounds so unappealing.
EVAN: Well, yeah actually the Wikipedia article seems more appropriate, but I don’t think of what they talk about in the Wikipedia article when I hear brownfield.
ERIC: Do you wanna actually talk about what it is? Because it took me a while to even know what greenfield was and all that too.
EVAN: You wanna talk about BMs?
[laughter]
JIM: I don’t think so.
EVAN: Oh, OK.
CHUCK: You guys keep putting up links to greenfield land and brownfield land and so, when you said “BM”, for some reason might brain translated it to “BLM”, which is the Bureau of Land Management.
[laughter]
EVAN: It’s your innocent Mormon mind at work, Chuck. [laughs]
CHUCK: No, I just think it colors my opinion of that particular branch of the hypocrisy in the federal government.
EVAN: [laughs] OK, fair enough.
JIM: So, back to our topic, “greenfield” is when it’s a brand new project and there is no code had been written it, right? So, maybe a “start-up”; that would be greenfield.
EVAN: Oh, that’s right. We are trying to inform an audience, aren’t we? We are not here just to laugh a lot. I forgot. I’m sorry.
CHUCK: [laughs]
ERIC: Yeah, so that’s right. I typically think of greenfield as “new app” or if there is a bit of code is the people who are working on it are already on the project. Like, if you started it, you can consider it a greenfield if it’s like a few months old and you have some code or whatever.
EVAN: I was going to say, I don’t consider every production app to be a brownfield app necessarily though. Because brownfield to me, I don’t think— again, I don’t think of the Wikipedia entry. Although, I think that’s maybe what the original term was supposed to refer to, but, I think of a project that’s desperately of a rescue.
JIM: That’s kind of what I think too. I mean, you know, what is it Working Effectively with Legacy Code defines “legacy code” as code without tests, right?
EVAN: I thought it’s a little more sophisticated than that, but that was a very much part of it.
JIM: Yeah or I mean we could read through the book now.
CHUCK: See, when I think of—
ERIC: Right now on the call? Like, live?
JIM: Right now.
EVAN: I think we may run into IP issues with reading Michael Feather’s book, you know, for the podcast.
JIM: Maybe if we did a dramatic reading.
CHUCK: Here we go.
EVAN: Now, that sounds like fun.
CHUCK: so, in my mind, brownfield doesn’t necessarily have to be code without tests. We can call it legacy or whatever, but I’ve been on projects that I would consider brownfield projects that were fairly well organized and easy to follow. But maybe, there was so much there that I couldn’t just look at it in few minutes and know what more or less everything was about.
ERIC: Yeah, I think of it– I don’t think of it as a straight label like “yes” or “no”. I think of it like, more of a scale of like, this is greenfield and this is brownfield. And then, there is a third one that’s kind of a joke where its scorched earth. But you know, it’s kind of anywhere on that line. And I think it’s actually personal like, though it might be brownfield you know, whatever to you like level 7 to you, might be a brownfield level 7 to me. So, that’s how I look at it and this is kind of a rough label for the quality.
JIM: I think so too. I mean, the other way of looking at is like a greenfield project, all the mistake is going to be your own; whereas in the brownfield project, there are probably mistakes in there already that could be yours or it could be someone else’s.
CHUCK: Right. Unless you inherit one of Evan’s projects; because he doesn’t make mistakes.
EVAN: I was just waiting for you to say “right”, Chuck. Right.
CHUCK: [laughs] So anyway, [laughs]
ERIC: I think everyone in the call is tired right now.
EVAN: Just a little bit.
JIM: We’ve been talking about like, now that we have the transcripts, we look back after recording a podcast and see like how many times do we begin a sentence with “so” or say “like” or [laughs] how many times in particular Chuck say “right”.
EVAN: Yes. Chuck loves the word “right”.
CHUCK: Wrong!
JIM: [laughs]
EVAN: Oh!
CHUCK: Anyhow.
EVAN: [laughs] We are a little unruly today.
CHUCK: Yeah, no kidding. So, when you make it you label a brownfield project then I mean you got you know, that it doesn’t have tests or maybe not enough tests that it’s more complicated than a small and simple project. Are there any other things that we can think of that we might want to use to sort of define what a brownfield project is?
ERIC: Age is a good one. Like, even if you have a really kind of well laid out project that I’ve test, if it’s you know, came from before Rails 1.0 or whatever and it’s still using kind of the patterns and ideas from that time, and it’s like “modern” or modern-ish, that can be kind of labelled as a brownfield. Because it’s you have to kind of think back of like, “Oh, there is not RESTful controllers here. What is that about?” So, like I said, like it’s kind of the complexity of the project and kind of how much you have to work through to get to your goal.
EVAN: Well, I think he hit something there but decrepitude in the project counts for something too, it’s age. Age tends to increase complexity because, at least for those of us who are trying to stay relatively on the leading edge in terms of skills, we are going to lose the older skills. So, working with Rails 1.2 can be pretty painful.
CHUCK: Well, for me, I mean, I’ve been picking up some RedMine work and even that I mean, Rails 2.3.5 some of that mind-set I’ve lost. And so I go back and look at it and I’m like, “I don’t remember exactly how this works.” And so, I have to look at it again and go, “Oh, yes! That’s how we did things back in the day.”
EVAN: I have the same experience working on a Rails 2.3 project also sometime this year I don’t remember when.
CHUCK: I actually recommended to some of my clients, because I have picked up one or two other Rails 2.3 projects, I recommended to them that if I spend a day or two upgrading, that in the long term, it will actually save them a bunch of my time.
EVAN: Yup.
ERIC: You know, it’s like even in RedMine because I think they are up to Rails 3, you know, whatever the latest is. But, I can probably pull up the code and point to controllers or models that were script generate back in Rails 1.0 days, that are still kind of sitting around there and with the test in that style. So it’s, you know, it’s about upgrading and actually getting stuff kind of I guess “modernized”. But, you know, it’s just kind of watching for rot and how much rot that’s in the project.
CHUCK: Right. So now we are kind of talking about how to handle it; and so, in that case, is it worth upgrading?
ERIC: It depends on the business and like what the app is for really. Like you said Chuck, like is the pain of working around these issues is greater than or less than the pain of fixing them and then using modern stuff. And that’s kind of a long term maintenance discussion.
EVAN: Sure. I mean, what’s the prognosis for the application? How long is it going to live? Not just how healthy is it, but in terms of it’s business needs, how much more longevity does it have?
CHUCK: And how likely am I to have to go back and do something with that same bit of code later.
EVAN: Or anyone else for that matter, not just you.
CHUCK: Right.
JIM: Well, I always when I’m taking a look at anybody’s application, I always start by looking at the routes file or sometimes the Gemfile. But, the routes file can kind of give you a quick overview of what the heck is going on in this thing. And if it looks really complicated, and there’s duplication or seemingly duplication of effort inside the routes file, then you know you are in for a big mess. That to me is like the canary of the application; if people handle the routes and stayed on top of them then, you know, or I should say if they didn’t, then you are in for trouble. But if they did, then you might find trouble elsewhere.
CHUCK: Well, that’s generally true of any application; if you look at the entry points and you see duplication.
EVAN: I developed from I guess from the talking to David Bach, he is one of the guys from the Ruby5 Podcast that he mention once upon a time very much the same thing that, looking at the routes file will tell you a lot about the state of the application. Not just how well organized, I guess not just how well organized it is, but how much care went to it’s construction period.
ERIC: Yeah, it’s a good indicator.
CHUCK: Another canary that I have seen is, if you run the specs– because RSpec will bring out the like the whole tree of the test.
JIM: I know where you are going with it, keep going. [laughs]
CHUCK: And so, once again, I mean, you can see how well its organized and sort of how they thought it out just by having it output that tree of tests.
EVAN: Oh, I was going to go a step further and say one of the ways no things are probably not good is if you see a bunch of warnings when you run the specs or tests or see a bunch of pending specs when you run the specs.
CHUCK: All those things go warm and fuzzy, doesn’t it?
JIM: I just grep through the test directory for assert true and if you find any of those, that’s [laughs]
EVAN: [laughs] Same difference, right it’s the placeholders “I was created by a generator and no one touched me” specs.
CHUCK: Right.
EVAN: Whenever you see those lying around in an app, that is usually a hint that things weren’t done very well.
ERIC: One thing like I’ve been on project where you can’t even send the boot and so–
CHUCK: [laughs]
JIM: And so I have actually gone as far as like using Unix tools. So, there’s a Unix tool called “Tree”, which will turn out like a directory tree and ask in your terminal. I’ll do Tree spec or test whatever and I’ll also do that on the app and just see what’s there and how much is there. And between that and then a couple of other commands that will show you like just the raw file size. Like, there is 2,000 lines in this model. To me, that gives me a really good idea to like, “OK, this is where there’s going to be problems.” and I mean, that would tell you, are there 500 classes and they are all under hundred lines or is there three classes and pushing 10,000 lines each.
CHUCK: It’s also a common thing to do things like a word count on a file or a word count on a directory or things like that where, it gives you sort of the depth or a line count even so that you can look at the class or series of classes and say, “OK it looks like these 3 or 4 classes handled this section of functionality” and then when you do a wc, you just kept the files and pipe them to which, it will tell you about how much code you are looking at. And you can get an idea, “OK, this is spread across two files and it’s 10 thousand lines of codes. It’s probably not well organized.”
EVAN: So, should we talk about what the difference between what brownfield and greenfield and what the hallmark of a brownfield is. Or do we actually wanna talk about maybe some of how we approach these coming projects and try to make it better.
JIM: I was just about to ask this; I think there’s a couple of a different things to think about here and I’m curious about how handles them. If you are helping a team, if there is a team that built this application and there’s problems with it, what’s your first step? When you find the problems, how do you try to gear the team in the right direction? Especially if you are new and you are the hired gun and how do you assert our authority or assert the problems with the team or how do you get the client to realize that it’s going to take a lot more effort than they thought it would or if it’s just–
EVAN: I’ve got a lot of experience on this one. The short answer is the “Socratic Method”. I ask lots of questions and I ask slightly leading questions because I want to know if they even perceive the problems to be problems.
JIM: And what did you think was going to happen? [laughs]
EVAN: [laughs] Right.
CHUCK: That’s not a load of question.
EVAN: Are you insane?
EVAN: Yeah, that’s not the kind of question I typically ask, although I’ve seen some code that’s brought me fairly close to that. But, no it really is a matter of–
CHUCK: [laughs]
Evan: [laughs] its true I have seen some code that really is that bad. But, it’s really try to figure out– when you are dealing with a team, it’s not just do they realize what’s wrong; it’s do they even if they realize what’s wrong, do they care enough to learn how to do it better? Because now, I feel like we are pretty much talking about rescue projects and in that case, to me, it turns very much to a political issue not a technical issue. That it becomes determining whether the people who I actually need to work with are interested in fixing things as the people who hired me. They often have different motivation to different desires.
ERIC: What do you consider the difference between a rescue project and a brownfield project?
EVAN: Hmmm.
ERIC: I think that they almost are the same, I mean–
EVAN: I don’t use the term brownfield, so I do tend to see them as the same. I guess the term brownfield feels more passive to me. Rescue sounds like there is more dire need. And so, I think I tend to see projects in need of rescues as project that are not only follow. Because brownfield to me, for some reason, implies follow and it’s essentially being left alone. And rescues to me are projects often that are in state of data currently actively being destroyed by some poor developer whose not doing the right things.
JIM: I think that’s probably on point. I kind of see rescue project as like, you know, the application was outsourced and it went horribly wrong and so they need you to come in and correct it; whereas brownfield might be, “This app has been around for a while and we need to renew our efforts or we need more developers” or something like that. So I can kind of see brownfield as not necessarily terrible code, but just as been around for a while.
EVAN: Right. Rescue is a hot mess. Whether it’s currently being worked on hot mess or a hot mess someone left behind.
CHUCK: For me, the other aspect of rescue, because something that isn’t necessarily like a huge mess it needs to be saved, but where it may have been neglected for a while and may need to– there is some urgency behind getting it back into working order and making it move ahead, can also be a rescue project. I think the mind-set has more to do with it than the actual state of code.
ERIC: OK. I mean the way that I can think of about is like brownfield is kind of the state of the project whereas rescue is more the state of the client where they recognize like, “Oh, we have a problem here.” and when they actually say, “We need to fix it.”, that’s when it’s kind of like this is now a rescue because someone is rescuing it versus it’s just sitting there.
CHUCK: Right. But for me, like the rescue project could be, “We urgently need to add a CMS to this.” and so because they have an urgent need, “We need this within the next week.” and it’s going to be a lot of work and there’s stress and you know they are gnashing their teeth every day and every dollar that it counts to get it to where they need it could be a rescue project even if the code isn’t in awful shape.
JIM: So, you could have a brownfield project that’s not a rescue project? [laughs] Can you have a greenfield project that is a rescue project?
CHUCK: Some people don’t need that long to make a mess.
[laughter]
EVAN: Chuck for the win.
ERIC: I mean, Jim, I don’t know. Like, maybe if there is like non-technical customers who are “designing” what their product should look like, and so there is maybe no code written but maybe there is wireframes and stuff. But that will really hard to have no code, fresh project but it be on trouble, you know like it’s almost like a business problem at that point.
EVAN: Yeah. I’ve worked on a few project kind of like that. Most problems that I’ve seen on projects are not just software problems because software problems are usually a symptom of a business problem.
CHUCK: Right. And if you have a large team that is generating a lot of code that are reflects the dysfunction of the organization–
EVAN: Yeah.
CHUCK: It can go south pretty fast.
EVAN: This is what I’m saying.
CHUCK: And it might be—it might still kind of feel like a greenfield project or it could be classified as a greenfield project, but you still have a deep hole that you’ve built in a month.
ERIC: So, it’s like continuum where it was a greenfield but it was going quickly to the brownfield side.
EVAN: Well, you know, every project starts with no errors, right? Because there is no code.
CHUCK: Right the errors are in the assumptions.
JIM: Yeah, exactly.
EVAN: The error start before you have the code, but they don’t manifest really. They are not concrete until you have code but yes.
CHUCK: Absolutely.
JIM: I was going to say, this — assertion that every time we are hired, it’s because there is a problem and the problem is always a people problem. The people problem is not necessarily, I found often not a technical problem, the problem is usually one of business leadership. And like the technical problems that I’m brought in to solve are a symptom of the business leadership problem that maybe they hired the wrong people, maybe they just haven’t managed the people well, maybe they haven’t lead their people well. But it’s usually at some point, it’s the business.
CHUCK: Isn’t that related to Conway’s law where the structure of the application mirrors the communication in the organization?
JIM: Definitely.
EVAN: Yes.
JIM: But what about, you know, tackling technical problems like, what’s the code coverage for it or what do the different aspects of Metric Fu tell you about the code base?
CHUCK: Can I generalize that just a little bit Jim?
JIM: Sure.
CHUCK: So let’s assume that there are no political constraints.
JIM: Right.
CHUCK: You have a brownfield project that’s got whatever problems it has and you are being paid essentially bring it to the state of the art best practices, make it better so that they can start making money or more money with it. What’s your approach? What do you tend to look for to do first?
EVAN: I hate to start with “it depends” but, it depends on the what the business’ priorities are in terms of deriving value from the application. Usually, most people want certain features either added or working better or working correctly before other ones. So then, to me, that is a matter of establishing priorities. Once the priorities are established, so that communicating with the customer and then figuring out what priorities this is going to be done in and then establishing what the technical risk is and then prioritize it to some degree around that as well. And then usually, most brownfield apps or I would say most legacy apps don’t really have much in a way of tests. So, then for me, that is writing what I call “life support” test; that’s find the portion I need, find the portion of the code I need to work on in order to add this business value. And then just test basically everything. When I say that I mean pretty much every path can reason if not, literally every path in order to map out the dependencies and then start trying to clean things up once I have passed the test. And that’s almost out of Michael Feather’s book.
CHUCK: Makes sense to me.
ERIC: Yeah and that’s kind of what I do too. You know, basically try to find little spots like I’m going to work here and I tend to go up a level. So if you’re working say controller I might go up to the view and I go down a level to the model and kind of make sure like, “OK, I can test out this. I can test the assumptions.” and basically like, “Okay, this bug requires me to work here. That part is fixed.” and so you kind of have this brownfield, but you have this bright green patches here and there. And eventually, you will convert it over.
EVAN: You can’t fix the whole project all at once. You have to tackle it a little bit at a time.
JIM: Yeah and you know, in my experience, a little bit of frontend clean-up can go really long way. Sometimes the business owners and project managers and whomever feels a certain way about the application because of how it looks. And if you do just a tiny bit of HTML, CSS clean up and styling, all of a sudden, they believe that things are different. It feels different to them and so sort of takes a load off. You still might have functional problems that you have to address, but if you take a little time to just kind of make it look better, if it has visual problems to work through, that can really relieve pressure.
EVAN: Maybe it’s me, but I tend to tell the client how I see it. When I see problems, I let them know that they are problems. if putting a shiny front end on it would make them feel a little bit better, then I would do it because they would feel a little bit better. But I tell them while that’s there, there are still problem and this hasn’t alleviated any of them. So, again this goes very much back priorities. It might be function over form first for me. It depends.
JIM: I’m not arguing the opposite, but you know, I’ve seen things lately reacts to things in a different way. And even the way they– for example, sometimes I’ve had clients who claim that some particular piece of functionality is critical, like absolutely highly critical. When it’s really difficult–
EVAN: I thought every feature is critical?
JIM: [laughs] exactly.
[laughter]
EVAN: In every clients, every feature is critical. I have to have them all and they all have to come at the same time. [laughs]
JIM: Yeah and its sometimes to get them to realize that it’s not the case, but you can make them react to their own application differently just because it looks different or they feel differently, because some minor aspect of the UI was cleaned up a bit.
EVAN: Agree.
CHUCK: I like that just because sometimes, the changes are going to be on the backend and so they don’t really see the change in functionality, other than maybe it works where I didn’t before or something and so, if there is some visual queue of change, then its something that they can see and deal with.
EVAN: One of my clients, I just built an API for; not frontend at all. So, it’s hard for me– I’m declaring there’s no progress but ideally don’t have anything I can show them easily. So, on the flip side as the consultant, I’m self-conscious of the it’s really hard to show him progress other than, “Hey, go look at all these code we have” [laughs]
ERIC: Yeah and I mean I kind of agree with Jim. You know, if there is political stuff at play, which other than our assumption, there always is, I mean, showing a bit of progress, especially if you can tell the client like, “Look, we are in a bit of a progress in the UI side. There is still these underlying architectural problems.” the client will appreciate that because they can actually visually compare, “Hey look, it’s different.” but they might also have stake holders that they go to them and say, “Look, this new consultant is producing new results. This is what they did in one week. We are going to keep them on”. And so, that’s if when there is political pressure like that, having visible results is probably a good idea.
EVAN: Can’t argue with that. I’ve actually used the same approach with one of my clients.
CHUCK: [laughs]
EVAN: Oh, I heard that! That’s the first time Chuck laughed at a — because I’m — for Chuck.
CHUCK: [laughs]
EVAN: I’ve been typing them in to the Skype chat except for that one there.
CHUCK: Yeah, Evan is being evil.
EVAN: [laughs] “Evan is being evil.” Well, the first two letters are the same.
CHUCK: [laughs] I’m not sure exactly where to go with that.
EVAN: I’m not either, but it works.
ERIC: Let it die. Let it die.
CHUCK: So, you get some characterization test around things, you start cleaning it up, I like the idea of putting up some kind of visual queue that things were going on; How far do you go with that refactoring or testing? Do you just test the things that are related to what you are changing?
EVAN: Yes. The Boy Scout rule is basically where I go by that, I have to work on—I wanna focus on parts of the project that will directly add value to the client, but my rule is, when I touch it, I’m going to make it better. And I usually, depending on the decrepitude, I’ve worked on a lot of decrepit projects, I find myself working to make it quite a bit better because I need it to be maintainable, usually it barely was when I got there. So, based on what need to get done at the time.
ERIC: That’s what I wanna say, like how you can go maybe a layer above and below. Because you have that one session working on that better and then that betterness leaks out a bit and then overtime, the leaks will kind of cover each and overall quality goes up. That’s kind of how I approach it, I mean, there’s also the business side of if the project is going to be shelled in 6 months, or it’s going to be taken out production and all that, going to affect your judgement to how much better you wanna make things. But yeah I mean, it’s all Boy Scout rules the thing I think about while I’m doing these kind of stuff.
EVAN: So, I’ve got another metaphor, I’ve got the number one metaphor to go with the number 2 metaphor we were using at the beginning. You guys ready for this one? So, I was talking to a client about how we were trying to make this leads off in a developer project that I’m working with and how we are trying to make the app better because the app has problem all over the place in terms of the code quality. And so the problem that we are facing is that it’s like pissing a pond. That you can turn the you can turn the pond—you assume the goal is to turn the pond yellow, you can do that, it’s just going to take a while.
CHUCK: [laughs]
EVAN: Yeah.
ERIC: I think you have to have like you know, the rest of the team kind of on board of you. Because if you are cleaning up messes all at the same time there are 6 other people making more messes, then you are going to have a mess worse than when you started. And that is something to watch out for and I know there’s– you can kind of mentor the team or what I do is I try to like this “show, don’t tell”. I’ll show you how you do good stuff and I’ll be kind of vocal about, “Hey look at good stuff.” and hope they will get it. But sometimes, you got to be more forceful and I mean, I’ve heard people even going above the teams head all the way up to like CTO, CEO level and say, “Look, your team is not doing their stuff. You need to get on them.”
EVAN: Yeah but that’s sort of—that point we are talking hard ball politics.
ERIC: Yeah.
EVAN: And you have to be very careful and you also have to have basically used almost every other option at that point because doing it and run around, the whole staff or developer team that hypothetically you are trying to work with, is a great way to lose credibility with almost all of those people.
ERIC: But at the same time, it’s depending on your circumstance.
EVAN: Sure.
ERIC: if the project is going under and it’s like management thinking, “This is going to get killed. It’s a waste of time.” That might be an option to save it, but–
EVAN: That’s what need — I agree.
ERIC: Yeah, I mean you have to have a lot of political trust built up with whoever you are going to go to. You have to prove that you are right because they can always say, “Look, you are the consultant. You don’t know our organization. You are wrong, you are fired.”
EVAN: Legitimate option too. [laughs]
JIM: There’s an approach that I have never used in its entirety, but truly it came up with one projects when I started doing around few others is, I don’t know this Agile approach called Forge. And what it is that you give different members of the team tasks that take different amounts of time. So, if you have a sprint that is two weeks long or something, you have one developer whose job it is to just turn on the small bits and sort of do clean-up work. And then the other developers have you know, longer tasks and as they come off of like a short task, they’ll go and help another developer on a bigger one. And I’ve seen that be a very successful approach where you can have– put somebody for this sprint, you are going to go around and you are going to do clean-up work and make sure everything is getting—you know, any tiny little things falling through the cracks that aren’t big enough for us to add story points to or whatever it is for our playing session then, you just take care of it.
ERIC: So you basically have one person or whatever doing all the clean-up work and then some people who are working on new features. As they finish, they come and do more clean-up work or help other people? I’m looking at the graphic of it.
JIM: Yeah, exactly.
CHUCK: One thing that I am wondering and this is kind of related to both of what you guys have said, how do you go in and fix something and educate the person who make the mistake without it feeling like you are picking on them in some way? Some guys will just be like, “Oh, thanks for pointing it out. I feel good about it. I won’t make the same mistake again.” And some folks are like,” Why are you on my case?”
EVAN: Almost everyone has an ego. It’s a matter of how personally they identify or how much they identify themselves with their work.
JIM: Not me. I’m the most humble person you will ever meet.
CHUCK: [laughs] I bet you are proud of that.
EVAN: I know a few bridges in Manhattan I could sell you.
CHUCK: [laughs]
EVAN: But, to me that seems to be the case; there are people who are completely detached. And I guess I’m not sure how many clients I’ve worked with like degrees of detached no one is really completely. And so it’s a matter a little emotional intelligence realizing how attached they are. And that’s the kind of thing that can be trickier to do when you are freelance, when you are remote and not on site, because it’s very new ones. Unless you have a lot of communication with the person, a little bit of in person time makes it a lot clearer. Just body language, facial expression all the little things you don’t get.
JIM: If you are brought in on a project specifically to make changes and you know, turn the team around or something.
EVAN: I think that still defacto versus dejure, Latin legal terms and you are brought in de jure, to fix things but the truth of it is this is one thing I said earlier, you might be hired for one reason, but the people you are working with really might want you there for another one.
JIM: Well, yeah what I was going t say was that, even if you are hired to do that, it would be wise to not do that from the start.
EVAN: Yes.
JIM: you know, if you made to change culture you have to do it in very small steps. And like at first just learn how everybody works and just don’t do a thing that is different from what they’re doing.
EVAN: Absofreakinlutely.
ERIC: Yeah, you got to slowly introduce ideas. That’s kind of what I’m saying earlier about I try to like lead by example. So, it’s like, say for instance they are not writing test or the test are bad, I’ll try to write good tests and I’ll try to point out like in a common like, add in a bunch of tests for this and kind of show like this is how development should be. And not really getting on their case or saying that, “You guys are doing it wrong” but saying like, “This is how it could be.” And you know, if there are some smart people that really care about the project, they might pick up on that and start trying to adapt. And that is kind of what Evan was saying that having the emotional intelligence that can notice if they are kind of borrowing from you and fully improving it in their own right now.
JIM: You know, that reminds me just quick anecdote, when I was in college I did a summer of painting was painting some home and I remember being my first day and painting outside of some customer’s house. And there was this expert painter next to me, he was doing the window because he was good at it and he looked at me and he saw that I was not—you know, it was just this painting job, some slap some painting on it. And he looked and said, “You know, no matter what you do, if you make it a craft you can really enjoy it.” So even if you are working with a terrible code, if you really turn it into a craft, you can walk away with enjoyment.
EVAN: This is why I said to people I actually kind of enjoy being the code *** cleaning up bad project is kind of a craft for me. But, what I was going to say though, in terms of the political aspect, in terms of determining how to teach people to improve or to work with the existing team, working on brownfield to improve, this is where I actually like to go out to a customer site as early as I can in the project. I like to go out for maybe a week on site whenever possible with these clients with the very beginning and try to get a sense of the people and try to get a sense of the culture. Because that is usually the environment I find myself having difficulty navigating. The code, messier not solutions present themselves but the people, it’s easier to collect more information on the ground and then figure out how best to help them. Doesn’t necessarily mean interfere, [laughs]
JIM: I agree I mean, I’ll try to do that too. Even If either I want to or I’m only brought on to do some part time work or something ,where it’s not full weeks’ worth of 40 hour billable time or whatever it may be, I always say at the beginning, I like to have enough time where I have a full schedule but then, back off. Because if you are just kind of coming and going at the beginning of the project, you can’t really get a feel for the developers or the code or how things are running.
EVAN: Right.
JIM: So what else haven’t we talked about? I mean what experiences do you have in when maybe things have gone right or things have gone wrong, where you attempt to make a change and it’s either not accepted by the client or not accepted by the development team? What do you do when you get up against push back?
EVAN: Try another angle or retire. I guess not immediately but usually, it’s try a bunch of angles and then I think I might have mentioned, talked about this to some degree in other podcast, but every individual has a limit to how much they can learn, how much they can change within a finite period of time. I found that some of my clients in working on improving them to fully change the team where, we just wanted to get stuff done and the heck with making improvements, let’s just go. And when they get to that point, I will frankly get impatient and that is usually when I say well, “I’m going to part ways with you now.” and the explanation, (I forgot which book provided this good guideline suggestion) is then if you find itself working with a team whose at least technical, if not business practices, don’t live up to your standard, then your options are either to leave or to lower your standards. And if u find yourself working at lower standards for longer periods of time, it actually becomes a habit. You have now lost something valuable to yourself. So, in that case, I find that its dangerous for me to stay on projects like that because I get dumber.
CHUCK: Yeah, I can see that.
EVAN: Are you saying I’m dumb?
CHUCK: [laughs] No. No.
JIM: I don’t know. [laughs]
EVAN: [laughs]
CHUCK: I didn’t wanna say anything but.
EVAN: [laughs]
CHUCK: Anyhow, I really liked that explanation to be honest. Because when you start doing things in way contrary to what you know is best, then yeah, you are forming habits.
ERIC: if you are brought in as a consultant to give advice of how to improve, if they are not going to take your advice, I mean it’s almost like “why you are there?” type thing. And yeah you can do the day to day grind, but like you said Evan, that grinds — too. And that’s not fair to your other clients or your whatever career future or whatever you wanna call that.
EVAN: Yeah as I said, it hurts me. It’s just that it’s not fun, it’s just that, I’m going to lower the quality of my own work, which is going to impact my future as a business. Not only that, but it also my enjoyment long term too because I couldn’t follow all the practices that I do make my job easier and making my job easier tends to make it more fun. If it was too easy then this job would be pointless. Right? Right? Right?
CHUCK: [laughs]
EVAN: [laughs]
CHUCK: My new goal is to make it so that when you try and make that joke, it won’t apply anymore. [laughs]
EVAN: Right. [laughs]
CHUCK: So anyway, it’s time to get into the picks. Unless there’s another aspect to this we wanna tackle real fast.
EVAN: Nope.
CHUCK: Alright lets go ahead and do the picks then. Eric what are your picks?
ERIC: I got two picks today. First one is actually a Rails Commit I saw come through. I’ll post in here because I’m not going to tell you about the Commit hashes because that’s just boring.
EVAN: [laughs]
ERIC: But I think it’s going on Rails 4. But they basically changed the test locations. So instead of being like test units, test functional, test—well yeah, I guess they kept test integration. But you know, test unit, test functional its now going to be like test models, test helpers, test controllers, test mailers. And it’s really nice because like, that’s the only thing I like about RSpec is that, RSpec kind of says all of these stuff is unit test but it’s unit test for different parts of your application; whereas Rails for the longest time when it’s using test unit, it kind of blurs the lines on things. So that Commit came in and I think I’m going to go on Rails 4, but I really like it’s going to be a good improvement.
My second pick is by TekPub. It’s a screencast called “Practical KnockoutJS”. It’s a paid screencast but it’s basically about 90 minutes of getting in to Knockout. And I like it because I’m doing a project I use a lot of Knockout and I have a little bit of experience with it, but going through this I got to see a bunch of stuff that I haven’t played with in the project doesn’t use either. Pretty nice, it goes through basically adding Knockout, adding the whole improvement to the UI for something that you can do like MonoRails app for — stuff. So, it’s pretty neat and I think the best part about it was the last two parts of the series they kind of get into a refactoring. And its actually not very Knockout specific, but it’s actually JavaScript and how to refactor jQuery type stuff. So, it’s a pretty good thing. It’s good to watch and like I said, its paid screencastl about 88 minutes long.
CHUCK: Cool. Evan what are your picks?
EVAN: I have one pick because it’s been a pretty crazy week. I’ll leave it at that. In this pick is a new podcast that I just started over the weekend it’s called the “Delighted Developer” and it is about, in a nutshell, we as developers engage with the emotional, I guess I can say emotional. The human condition of being software developers. So, not necessarily so much a technical focus, but more of a personal focus. And I maybe interviewing folks, maybe doing a panel every now and maybe monologuing a little bit. Because you know, I don’t like to talk or anything. I’ll have a link to that in the show notes. Right.
CHUCK: Sounds great. Looking forward to it.
EVAN: You can start listening.
CHUCK: All right. Jim, what are your picks?
JIM: I only have one pick and it’s an application that’s called “Dead Man’s Snitch”.
EVAN: Oh yeah, by —.
JIM: Yeah. A friend of ours who I met at Ruby DCamp was building this monitoring application that makes sure that you are notified when any of your periodic tasks don’t happen. So for example, paying them can make sure that your site is up and running but I don’t think it has any way to let you know if your hourly or daily mail processing queue wasn’t flushed or whatever it is. So, take a look at that. That’s my pick.
CHUCK: Alright well, then I’ll jump in with my picks. My first pick came out today in the Mac App Store is called Tweetbot for Twitter. It’s basically Tweetbot, except it runs on your Mac instead of your iPhone.
EVAN: Wait, it’s out?
CHUCK: it’s out.
EVAN: YES!
CHUCK: It costs $20 .
EVAN: Oh my god.
CHUCK: I think that’s to kind of only get the hard-core folks that really want it, because they are limited on the user tokens for Tweetbot.
JIM: Why “oh, my god.” When you hear twenty bucks though?
EVAN: Well, the iOS version, which (I’m using the alpha, I’ve been using the alpha for Tweetbot for ages) the iOS version both iPad and iPhone are significantly cheaper. So, that’s my shock.
ERIC: And how much did your net cost again?
EVAN: [laughs] I don’t understand what the cost of the hardware has to do with the software which are very similar request platforms.
CHUCK: Yeah, I’d literally think it’s a attrition play because they only have so many user tokens that they can acquire from Twitter without jumping through more hoops.
EVAN: Yeah, I remember reading something about that.
CHUCK: Because Twitter changed the rules on how they allocate those. Anyway, that’s just the thing I really don’t know why it costs so much, but I like their interface enough to where I just bought it.
EVAN: I love it. Yeah.
CHUCK: My other pick is talk on Confreaks. We were talking about writing tests, refactoring code and making it better. And there’s a terrific talk by Katrina Owen at Cascadia Ruby conference. She also spoke in Scotland on Rails or Scotland Ruby or whatever they call that one in Scotland. The same talk, and so you can go watch the video there as well. It’s called “Therapeutic Refactoring” and it is awesome. So, definitely go check it out. I think it’s also on YouTube but, you kind of get the idea. It’s just an awesome talk. You just need to go see it. And we actually had her on Ruby Rogues and talked a little bit more about it. So if you want extended conversation on that, you can go over there and find the episode that she was on. In fact, we’ll put link to that in the show notes as well.
And outside of that, do we have any announcements that we wanna go over or anything else?
EVAN: Right.
[laughter]
CHUCK: All right. Well, then we will call it an episode. We’ll catch you all next week.
EVAN: Right.
JIM: See ya.
ERIC: See ya.
CHUCK: Right.
EVAN: See ya. [laughs]
