Brian Shea, who joins to talk about consulting on an existing org, is 8x Certified, Salesforce Architect at Shea Consulting LLC.
Sponsor
Proton Text is a complete SMS texting solution built for the Lightning Platform, and by one of our previous guests Pat McClellan.
Main Points
- Working in a brand new v.s. Old Salesforce environment
- Brian’s definition of legacy code
- Risk of working in an old environment
- Regression test
- Project scope
- Get familiar with the legacy code
- Communication on the existing issues
- House cleaning job – consultant or internal staff?
Links
Video Teaser
Contact Me
If you enjoy this podcast, please reach me out to let me know your thoughts or simply say Hello. My (Xi’s) contact info:
Take care, until next time :)!
Transcript
AI-generated, unedited.
[00:00] Our sponsor today is Proton Text, a complete SMS texting solution built for the Lightning platform by one of our previous guests, Pat McLehame. Here's reason number two that admins and users love this app: easy automation. Pluton Text uses platform events and invocable Apex actions, so admins can create automated texting that is customized for the needs of their work and users. Starting with the app's open-source automation library, admins can set up text notifications, appointment reminders, text lead, and text case audience polling, customer surveys, and all of it built with processes and flows. It's not magic, just good design. Check out the ProtonText open-source automation library at protontext.com.
[00:57] Hello,
[01:06] everybody. This is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today, I'm sitting with a new guest. His name is Brian Shea. Hello, Brian. Hey, Xi. Great to meet you. Great to chat with you today. Yeah, definitely. It's a great Saturday, sunny day here in Finland. Yes, yes. Saturday. I'm in Boston, so it's Saturday morning here in Boston. So Brian, would you like to introduce yourself? Sure. Yeah. So I have a consulting company, small consulting company called Shea Consulting. We've been around since 2012. We do Salesforce, Salesforce architecture. For the most part, for higher ed clients and for financial services clients. All right. So working in the consulting firm, I would assume that you get a lot of chance to working with different customers. Am I right? Yeah. Hopefully, yeah. No, that's that's the that's the fun of it. Being able to work with different different customers. You know, we learn on every project. We learn something. You know. About Salesforce, about technology, about business from every customer or every client because everybody's got their unique situation. So that's why I like I like doing it. Yeah, so
[02:37] I would assume also a lot of customers they already have their org existing for quite a long time. Yes, they have their metadata already in the environment. They have custom code. Yeah, so. It's kind of different situation comparing to a greenfield project. Am I right? Totally, one hundred percent. Yeah, if you if you're walking into an org that's existed for a while, that's been customized. And generally speaking, if it's if it has been if it has existed for a while, it has been customized. It's a there's a number of kind of risks and constraints that we're really need to be aware of. And I'll say also a lot of times it's not just Salesforce. You know, sometimes we're coming in and Salesforce is integrated with something else, whether it be you know. ERP system or another you know business intelligence reporting system. So there's a lot of stuff there. And as consultants, we're coming in and not as knowledgeable about what's going on you know on the ground because we're coming in. So there's a lot of a lot of things we want to make sure we don't break. Hmm. I would assume there's like a checklist for us, right? If you're experienced enough, you have your own checklist each time we get a customer, because customers usually they don't. Tell you okay, how
[04:07] much code do we have? Have how complex the environment is? They just say we have this requirement. How much money you want get? Right, right, right. Yeah, and a lot of times, a lot of times the fact that they're hiring a consultant, depending on the type of engagement, is a lot of times if they're hiring consultants because they, you know, they need help, right? So, you know, when you come in, they're not saying like, okay, here's you know, here's the issue with this you know block of code, and here's the issue with this class, and we know we have this problem over here. It's usually something like, you know, oh, we've got all this legacy code. It does some stuff. We don't know what it does, but we need this. We need this, you know, new feature built, or we need this thing worked out. So you sort of have a sense of what's going on, maybe, but it's it's really up to us in a lot of cases to figure it out, or work with the client and help them help us figure it out. You just mentioned the legacy code. Do you have a definition about the legacy code? My definition is there's there's probably two parts, and it's it's probably not a perfect definition. But my first piece of definition on legacy code is when we walk into a customer, into a client, any code that already exists, any Apex code that already exists. By our definition, that's legacy code because it was already there. It's already in production, so that's one piece. The other piece, sort of more informally, is. You know, it might not be
[05:37] a a code that is necessarily written as per best practices. So we're sort of getting getting what whatever is there. You know, and we may look at that code and say, or the client may say, we wish we hadn't written it this way, or we wish hadn't structured it this way, or we should have done it differently. Even if hasn't been architected in a way that the client doesn't love, a lot of times they're like, okay, it's working. Let's let's not disrupt that piece. How about the declarative automations like Process Builders, Flows? Is that also part of the legacy code? Do you say? Yeah, I think I I think when we were chatting before this, like our definition of legacy code is, is not just code. Usually, you know, in Salesforce, yeah, it's it's it's good that we set the theme. We we make sure everybody understands the same way, right? Yeah. So. And actually, I I do agree that we should take care of the process builder and flow and and you know workflows because they are really part of the the environment. They're as powerful as the code. Yeah, validation rules. A validation rule can, you know, it's it's basically anything. I'd say any piece of automation that can have unintended consequences that needs to be tested is something that you you really need to take into account in terms of your assessment of of the situation. So, what kind of risks are you usually encountering when you go to a new customer? Sure,
[07:07] yeah. T here is when we think about risk in terms of legacy code. T here is really two two buckets of risk that we take, and it's really like two sides really two sides of a coin. One piece of risk, one side of the risk is. We build something, you know. We test it as part of our project, and then we put it in into production. And something that had worked previously. An unrelated feature doesn't work anymore because of how the new thing we built interacts with existing things that have been built. So, in in that example, like the the sort of the answer to that, or one of the things you can do with that is is regression testing, right? Like testing testing existing features that are somewhat unrelated to your new features to make sure you haven't disrupted anything. So that's one side of the house in terms of risk. The other side of the house, and like I said, it's kind of the other side of the coin, is like project timeline risk or project budget risk. And that means like, hey, we said this project was going to take three months and cost X, and you get to the end of the project if you haven't sort of assessed your you know legacy code. Effectively, you get to the end of the project. You have your testing. You do your testing, and you realize, like, oh man, we we've broken this stuff because of you know the legacy code and whatever. And now all of a sudden, we got
[08:37] to extend the timeline or delay it or something. So that's the other side of the risk. It's really born from the same thing. Unintended consequences, but it sort of manifests itself in in different ways. depend Depending on whether you catch it before you go live or after you go live,
[08:55] either you found it by yourself or the user found it. Right, right. So if you find it by yourself, it extends the timeline. If somebody finds it after production, it's the unintended consequences in production. Yeah. It's it's also a universal challenge in software projects, am I right? So yeah, just how it is. It's virtual. They are interconnected, one with another. It's really hard to say. I just built this new feature, and nothing existing will be touched. You have to touch the existing features. You have to build on top of them. Right, that makes a risk that introduces a risk that you might break the existing features. Yeah, and I mean there are some. You know, as as folks know, there are some orgs that have been really, really well designed. Right? It's real, you know, object oriented architecture or service oriented design or whatever you want to, whatever term you want to use, where it makes it much easier as the developer, as the consultant, to come in and build something that can interact with the existing things in a very, you know, rational way.
[10:00] So there's still risk there, but it's it's much less. But a lot of times you go in, and you know, particularly with, I think particularly with Salesforce, although it's not unique to Salesforce, one of the benefits of the platform is that it's it's made the ability to build automation. It's made it much more widely available to people. You don't need to be like a Ten-year veteran of writing object-oriented code to build automation in Salesforce, so that's great, right? There's more people who sort of stumbled upon it and built stuff over time, which is great. On the flip side, a lot of time it becomes a lot easier for sort of bad habits and things to get. Built in a Salesforce org. If you've got different people who are building things that might not have, you know, a lot of times we run into. You know, we talk with folks, and they'll say, "Oh, we, you know, I built this automation four years ago. It was the first piece of automation I ever built. I wouldn't do it this that way again." You know, because now I know better. But that's sort of the blessing—the blessing and the curse of a cloud architecture, right? There's lower barrier to entry, which is great, but also, you know, you can get some some tough architectures sometimes. Yeah, totally. And if we step back a little bit, talking about the existing legacy
[11:30] codes, you mentioned a regression test. So that's one efficient way, I would assume, to make sure when you introduce new things, existing things are not broken. So could you open it up? What is regression test and How do you do that? Sure. So, just in terms of kind of the definition of what it is, of what it is, it's testing features that should
[11:57] not have been changed as part of your project. So it's it's testing. Unrelated changes. So if we think about, let's let's throw out an example. Let's say you are building. You've got a simple, relatively simple org that uses you know account, contact, and opportunity, and you've got some automation existing in the org. And you do a project where you're adding, I don't know, you're adding some features related to. Opportunity contact roles. Let's say, right. So it's so you're on the opportunity. You're on the opportunity contact record. A regression testing would look at what are the existing features overall related to not just opportunity but account and contact. They shouldn't have been impacted by what we're doing on opportunity contact role, but let's do testing to to confirm that. Do you usually do it in the manual way or in the automated way? So what what I'm talking about here is manual sort of business scenarios. We'll work with the client to sort of determine how things work currently and kind of document those test cases. Usually in like a You know, sometimes there's tools you can use, but it can be as simple as like a spreadsheet of identifying the scenario, what what should happen. You know, what's the pass criteria, and it's you know can be done manually. And you know,
[13:27] from a business user perspective, business users should be able to go through and and and do those things. Yes, because I know some of customers they are technical heavy and they have their internal teams who really manage this automated testing, which only covers the most essential business cases. So if you have a customers like that, then definitely you can use those existing automated testing to make sure the regression test is is always there. It's always green lighted. So it would be like an org would have basically a set of automated tests they could run, yeah, on demand. Indeed, it's like a browser. Open a browser. You log in. You click this button. You click that button to make sure you know. See the database has the the data. Got it. The data existing in the page or something like that. Yeah. Got it. So it's very like essential, sort of low level test cases.
[14:30] Comparing to the Apex unit tests, that's still a bit higher level and is more fragile. And for a developer, usually we create the unit test to test the the minimum, smallest functions in our Apex code, which runs fast. And it's easy to create, but those kind of automated UI testing it runs slower, and it's fragile, easy broken when something changes. Got it. Got it. Got it. Got it. Different level. Yeah. Yeah. Like I said, the regression testing I'm referring to is like higher level than both of those, and it's really like end user business business testing. Yeah, it's another tick box in our checklist. You have to make sure there is a certain level of regression testing there. It doesn't matter, is the manual or automated? Yeah, depends on the project. Yeah. Yeah, but that's that's you know I know when we do regression testing, you know, we'll definitely have regression tests that are you know from a business user perspective. We'll also, as we do our project, you know, just in working with the org, we'll identify sort of high risk scenarios. That will add in there as well. That we can tell from like working with the code or working with declarative element that, like, oh, this is something you know that could break. That might not be obvious to folks. Like, let's
[16:00] document those and make sure those are heavily tested. Yeah, it's all about possibilities, the odds, right? And how about the project scope? When you start the project, you definitely want to define the scope, right? Especially for project manager. Yeah, yeah. Especially as a consultant, we have to define the scope, and this is this is one of the hard things about consulting, right? Because particularly, you know, for a new client, you're walking in and you don't really have a sense of. What's going on in that org? I mean, from initial conversations and stuff, we'll we'll get a sense. But a lot of times for us, this is more of a consulting tip than anything. for For new clients, our first engagement a lot of times will be a discovery session. Or discovery engagement, and that's where we come in. We're you know we're meeting with the client. We're looking at their org, and we do that independently of any you know implementation or any changes. Because the challenge is, you come in and you look at. You know, sort of how something is structured, and as you know, can vastly change what options are available or how long something happens. So, that's that's really the first. Step with a new client. Once we've once we've worked with somebody for a while and we have a better sense of like how their org is structured and you know where the risks are, we can do projects without that without
[17:30] that standalone discovery. But for new ones, that's that's kind of how we that's how we start because it's just walking into something new. It's very very difficult. You can give a range of estimates to somebody, but at some point the range is so big, it's like it's not useful. You know? Yeah. Do you usually do on the business requirement levels to scope it, or do you also go into some technical detail levels? Yeah, so we definitely do the business requirement side of it, obviously, and if possible, we really do like to, if we can, identify scope at like let's say an Apex class level. Okay. So we would say, you know, we would identify the business requirements, but in like the scope document, we would say, you know, our changes will be limited to, you know, this Apex class or something, and that sort of gives us. Some constraints and allows us to to narrow the scope. How do you study the code base in that sense? Do you get some support from like the existing developers or architects, or do you do by yourself? Yeah, if um, if at all possible, we want to get as much support as we can from either the folks who wrote it or you know a lot of times the folks who are maintaining it. Um, and they might not, you know, again, a lot of times they don't. They might not know exactly
[19:00] what the code does or how it works, right? Because a lot of times, if if they did know exactly how it works, they wouldn't be hiring us. Um, but you can get, you know, it's a process, right? And getting their input into, um. Challenges that they've run into, or scenarios where, oh, we we have this issue. You know when.
[19:23] I don't know. We're creating opportunity products, or we're creating opportunity contact roles, and it always seems to happen when we're doing it for the you know the West Coast team, but not anybody else. You know, it's like that's a clue, and we can use that to for our analysis into the code. And it's it's really a process. It's a process of like figuring it out, figuring out together, and like learning together as a consultant and as the client. You know, with with our projects. One of the things that I enjoy the most about our project is not just what we, the features that we build, but when we leave or when we finish the project, that everybody, the consultant and the client, has a better sense of how everything works. You know, so there's like this. There's this like learning going on with all of us. I'm also consulting developer role in the consulting firm, so I have worked with customers that they have internal experience architect who really know every single piece of the moving parts. Yeah, they can really give you good comments what how you should work. Then that facilitates a lot. Yeah. Sometimes the customer don't have that. They're really like a business focus, right? Yeah. Maybe they have a lot of money. Okay, you just hire you in. This is your job. Yeah. Get it done. Yep. Yeah. Yeah. So then you have to swim through a lot of things, right? You know, and it's funny too. Like you know, somewhat
[20:54] of a like a subtle distinction. Um. At least for me, like starting out when I started out consulting, you know, you focus on the client and their client, and they've got a project and. Okay, fine. But that distinction of like, hey, they've got somebody on staff that knows the org really well and can architect the whole thing. That's a huge change to the project, right? If you if you're coming in and there's somebody who does understand the org and can architect, it it totally changes sort of what you're doing as a consultant, right? In that case. You're probably coming in to execute on, you know, you may build the design, but at the end of the day, that architect is going to know and have a lot of feedback on your design. So what you're really coming in to do is to build something, right? That's one type of engagement. The second kind of engagement where somebody might not have that. You know, technical architect, or it's you know mostly business folks. You've got to build it, but you also you're you're going to be the one who needs to manage the risk and architect it and work with the client. And those are you know non obvious, subtle things as a consultant that you kind of need to identify and be aware of. Like what your job is. You know what what am I getting What am I getting paid to do here? Is it just to build, or is it to like Tell them like what the architecture should be and what the risks are. You know, or even tell the customers that you are missing such an architectural role in the company. Maybe right
[22:24] hire people to do that. Right. Yeah. Exactly. So when you are doing all this figuring out the stuff for the customers, you will definitely find out a lot of maybe issues as well, like you mentioned the lack of code, some of the code are rotten or maybe are outdated. Yeah. So, do you do communication back to them to tell that okay, we have all these red flags, so let's let's talk it through. Yeah, definitely. So, and you use the term communication. That's exactly. It, you know, if we get in there and we're looking at something, and they've wanted, you know, a particular feature, right? And we get in there and we say, you know, t here is t here is a lot of issues with the org right now. What we usually do is come back to them and say, okay, you wanted this feature, and give them some options, right? Like we could say, you know, your existing code base is. You know, there's some risk here. There's a lot of stuff going on. We can build you this narrow feature, but understand that you're still going to have. A lot of risks in your code base, so give them that option as one option. The other option could be we're going to do this feature, but while we do it, we're going to rearchitect some things. And what we try to do is quantify that to them and give them, you know, why that matters, right? Because for a company that doesn't have that architect, if you say, hey, we're going to reengineer your code base a little bit, they're like, why do
[23:54] Why do I need that, right? So you kind of in try in business terms to quantify why that's valuable for them, and then obviously quantify it on the cost side to say, like, okay, we can do this, but it'll take an extra. Six weeks or something, and give them the choice to identify what they want to do. And I'd say a lot of times, you know, if you come in and they, you know, have a particular timeline in mind, and they really want to get their feature done, a lot of times what they'll say is, "Hey, we want option one. Like, let's get this." Like let's just get our feature, and we're not going to do any big reengineering. We're just going to work within the existing structure. Get this feature, but a lot of times they'll say, "Okay, now we know there's this other challenges that we've had, and they can put it on their roadmap, or they can they can decide maybe to do it in the future." So the communication is huge because. Again, it's like a learning process for all of us, right? When we're working on a project for for the consultant for the client, and we want to help them not just get their feature, but know know their org better, so they can so they can be successful in the future. So in this podcast, in the past, we had episodes talking about soft skills and how to do communications, and it's it's non trivial to do the communications. So as a new consultant walking to a new client.
[25:25] They don't trust you at the early phase. So if you tell them your code sucks, maybe right be thrown out of the way. Right, right, right, right, right. Well, yeah, I I think that yeah. I say as a new consultant or as an old consultant, if you walk in and say your code sucks, you're probably gonna have. Problems, I think. You know, I think we were talking about the the fact that when we're consultants, a lot of times, you know, our clients are not necessarily like. Salesforce experts or technology experts, and really for them, if you are coming from the business side, you know, or even a CIO or somebody, for them, it's about the business impact, and a really good way. To to talk about the business impact is to try to quantify things, right? So, again, like if you are talking about legacy code, you know, what does it matter to the companies? You know the company overall, right? If you've got a bunch of legacy code, is it going to hinder you from earning money in the future as a company? You know, maybe, maybe not. Is it going to introduce risk to the company? Yeah, maybe, right? Like if you're if you're Salesforce. Data your Salesforce or is client facing, right? It may impact you know clients, their customers may be getting errors or may be getting bad data. That's a big
[26:55] risk. You know that's something that you can put into your analysis and try to quantify that. Maybe it's okay. You've got all this legacy code, and in the future, if you want to do some new strategy, go to market with some new strategy. It's going to take you six months to do that because your Salesforce is all you know. The data quality's bad. The code's jacked up. So these are the kind of things. Like if you can put it as a consultant, put it into those terms, it makes it easy. It makes it easier for your client to make a decision. And even if your client, and the good thing is, even if your client is technical and they understand, like you talk about legacy code, and they understand. Oh, this is bad. If you can put, like, make a business case for them, they can take that business case and they can bring it to their boss, or they can communicate it around the organization. It helps them to do that. So, I'd say that's a huge thing. Like as a consultant, if you can do that. That's that's really interesting. As a developer, a lot of people like me, we know what we're doing, hands on code. Yeah. But it's difficult for us to visualize it and put it into the business case and tell how important to the big bosses, which yeah they look into things in different aspect. And yeah, one of the things I remember, one of the thought leaders in the programming industry is Michael Feathers. He mentioned one thing: is like a clean code always looks like it was written by somebody who cares.
[28:26] So definitely, that's the feeling. You know, when I open somebody else's code in the work, I can definitely see if it's well taken care of all the time, or is it you know let it. Opened it for a long time. Yeah, yeah, that's a really good quote, and it's you know it's as a consultant too. Like even when we go in and we're working with an org that has you know. Legacy code and legacy code in terms of maybe it wasn't architected that well or built that well. You know, we can still go in and even for the piece that we're doing, build it as well, architect architect that piece as well as we can. Right, and build it in a way that's you know commented clearly to at least keep our little corner of the org as well organized as possible, even if the whole other thing isn't you know. Yeah, I've seen that as well. Can I say one thing in terms of the? You were saying as a developer, you really know hands on what's going on. You know, I'd say I've worked with you know a number of developers throughout my career, and and I've heard heard folks say like, oh, you know. I'm a I'm a developer, so I don't necessarily know like the end business impact of what I'm of of some of the stuff that we're building. And I'd say, generally speaking, like for a lot of those folks, like they have a really good sense of the business impact. They have a really
[29:56] good sense of the risks of having code that isn't well structured or or isn't clean. And I think in a lot of those cases, I'm thinking of a couple of colleagues in particular. It was a matter of them kind of finding their voice in terms of how to communicate the things that they already knew about working with an org. So maybe they worked on like, okay, how do I communicate this in a way that resonates with a business audience? But Their their issue wasn't the fact that they didn't know the the the business impact of it or the um or the the risks. It was just that they hadn't had like the practice of like communicating out in a meeting or communicating it out in an email or something. Um, so I'd say like for developers out there, you probably you you have like a front row seat to a lot of the things, and you know like trust yourself that like you've got a lot of um a lot of things that you can communicate to the business audience that nobody else knows. Indeed. I also heard another guy, Robert C. Martin. Okay, it's called Bob. He also mentioned as a developer, it's your professional responsibility to tell the business because you get paid to do all this stuff. You're professional, so you should be responsible to give the feedbacks to the business, which makes sense to me. Yeah, absolutely. Yeah, again, it's like the developers have a view to things that nobody else has,
[31:26] and it's definitely the responsibility because they have you know unique insights to share. Yeah. All right. Um. So we talked about how to take care of the work, this and that. But that's like a long-term process. It's not just usually not for like one comes out and walk in and fix all the issues and walk away. It's a house cleaning job. It's every day, every month. You need to do that. Do you think usually you should hire consultant to do it, or or like an in house developer? What's the? I think yeah. That's a that's a really good question. I think ideally, if you have a in house developer. You know that's a the in house developer or you know they're the the owner of the org. You know from a technical perspective. So I think there's a lot of benefits to having that person own it, and you know having.
[32:27] As Salesforce professionals, we always have to be adding business value, right? So even if there's you know a bunch of legacy code that we want to reengineer, you know we can't just pause for three or four months and just. Clean everything up. So it's great to be able to say, like, okay, how can we, as we do projects, how can we slowly reengineer the org and make it better? So as you look at your roadmap. That can be a great way to sort of couple features with opportunities to reengineer the code, right? Like if we're opening up, you know, some legacy class to add a new feature, how can we? Factor in some time into the budget to reengineer things. So, I mean, it's it's it's definitely possible. You know, consultants can do it, but I think it requires having a real long term relationship with the org in order to clean it up. So, some some consulting relationships are like that, where somebody's been working for a really long time with somebody. But I think it's to your point. It's ideal to have somebody really own it internally. Excellent. All right, so that's all. I don't know, Brian. Do you have something else you want to share before we close the session? Think I think that's it. The only other thing I want to share is just thanks for having me on. This has been a lot of fun. Yeah, definitely. You know, getting you onto the show and to talk about this topic, share our ideas mutually.
[33:57] That's that's really excellent, and we get the people to listen to us. That's Right, right. Well, thanks, she. Yeah, no worries. Okay.
[34:08] Hi, I'm constantly looking for good guests. If you have any guest recommendation, please reach me out. I'll make sure they are joining to the show to share their knowledge. Otherwise, thanks for listening to the show. I'll see you next Thursday.
