Robert Sösemann from Up2go guests in the show to talk about Clean code and Code Agility. Every salesforce programmer needs to pick these up, it is simply THAT important!
Main Points
- What is Clean Code
- What is Code Agility
- Why should developers care about both
- Robert’s planned Dreamforce session about Code Agility
Links
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] You're tuning to Salesforce Way podcast, episode seven, the clean code.
[00:14] If we search by Google with the keyword "every programmers must read books," we get infinite results. But one bug persists in every single one of those results. It's the bug, clean code from Uncle Bob. In this episode, Robert Sösemann, product architect from Up To Go, joins me to talk about what is clean code and why other developers would sincerely appreciate you if you apply this concept into your own code. Robert and I don't have the chance to go into all details in this talk. Actually, we only touch the surface of this concept. So I'd urge you to get this book for yourself, or you love to follow developers and learn it along the time. Oh, by the way, the book link is already attached in our episode show notes. And if you enjoyed the talk, don't forget to thank Robert on Twitter and advocate his Dreamforce topic proposals. His Twitter handle is also linked in the show notes at our website SalesforceWay.com.
[01:27] Hey everybody! This is Xi Xiao. This is yet another episode of Salesforce Way podcast. Today we're going to talk about a very exciting topic. At least I'm personally very excited about. It's called clean code. So I always wanted to talk about this topic because I think it's very important for all technologists or developers to understand this concept. I have always seeking the person, the best guest, to join the session to talk with me about this topic. Until today, I really found one. So his name is Robert Sösemann. Hello, Robert. Hey Xi, thanks for inviting me, and I'm honored by your introduction. No problem. I really, I really enjoy. I did Bob Martin, author, code. Yeah, yeah, but um, I I will try to um not replace him, but to to be a good proxy. Yeah, sure. Let's carry on on that. So, would you please, Robert, first introduce yourself? Sure. Um, yeah, I'm Robert. From my last name, everybody realized I must be German or something, not American. Um, I'm. I call myself a product architect up to go. Up to Go is a for many years a partner,
[02:58] an ISV partner with Salesforce. We built multiple enterprise apps natively on the the platform. Our main focus customers are automotive suppliers, but our software is not only about gears and mufflers. It's about collaboration and. Micro social networks, so interesting stuff. Cars are also interesting, but this is even more interesting. And what what's my role? I'm not a PowerPoint architect. I really code ninety percent of my day. We are um. I would I would say still a small company um around 50 people um separated in in the US in France in Germany in Austria and I work for the Tubingen development office where we produce one of our applications called CPRM customer product relationship management and yeah. So I can say I have quite a lot of experience in in the Salesforce space and the development space, also in this special space of being a partner. Building something, selling it, licensing it, and yeah, and as I say on my Twitter page, um, there are like two concepts, um, in my career that really. Made it into my mind and never leave it. It's it's
[04:28] one agility. So the way how you organize the development of stuff and clean code. It's how you code. So I I I don't say anything else. It's not of interest to me, but. There's a lot of stuff that I do it. I say it's good. I can use it. This is a hype, but this is something I constantly iterate on in every job I had, and it's getting better. And the fact that that you connect me to clean code really makes me makes me proud. The message came through. Okay. Yeah, and Robert, I understand in up to go that's your official title, but in your spare time you also have a product. You authored a product called the PMDA Packs, right? Ah, yeah, no, no, I, I don't offer it. PMD is. More than 50 years old. It was it was. I was called Tom Copeland. I think a great guy said we need a we need a tool to to find nifty bugs in JavaScript or the the stuff that people hate to find in manual code reviews. Just imagine you you do a code review. You are an expert, and a junior developer comes to your place and. What you do is basically spend hours just to correct syntax and find
[05:59] stuff that that code could be. And and PMD is a it's called a static code analyzer. So it basically parses source code without understanding its runtime behavior and finding those. Those trivial problems. So in a real code review, you can spend your time on fighting about names and names and and whatever object orientation and how you encapsulate stuff. So the real important stuff and. So this is old, and and what I did is I just ported it to to the Salesforce world. Okay, so that it supports the Apex, right? And it's it's not a product; it's free. It's it's just like an open source contribution I did. Okay, and it was a really egoistic move because I needed it for myself. Okay, so we will go into details about the PMD Apex. If we jump back to the the main topic, so today we're going to talk about the the code agility, and there's also a concept called the clean code. Are they the same or are they different? No, I mean, clean code is really something everybody knows because there's a. It came comes from book from Bob Martin and it's. I I even said that during Dreamforce talk. So please don't say everybody knows it. I know it's famous,
[07:29] but I know there are people still don't know that. I will put the links to our show notes. Should know it. Yeah. Yeah. There are some some Bible developers should need to know, like pragmatic programmer and.
[07:44] Code complete and clean code is also such a book because it's not tied to a certain decade and some hip programming language. It's basically true since it was written, and I think it's more than. I know, twenty years old. I don't know. It you can read it. I can I can give it my kids and it will still apply in twenty years. And it's it's not about how to be efficient or stuff like that. It's just about. This this somewhat vague attribute of clean. What what does clean mean? We we all thought code just has to work and be efficient and run fast. No, it has to be clean because code is not written for the computer. It's for the programmer that has to maintain the software, to extend it, to improve it. And the whole book is about this: how you write code in a way that. The people that come after you will not hate you. How they can maintain your stuff, how they can fix bugs, and how they can improve it. So, because that's important. Software is around for years. You write and you think, I will always be there. And then you switch your job, and ten years later, somebody he could kill you if he know who you who who you are and where you live. Okay, you have your experience already. I think every developer, even if they don't know the the concepts or the the book, they they know how it feels if you. Even with
[09:14] your own code, I often I still often read my own code and think, Hey, what happened? What did you drink that day? And this book is just about those concepts, and I think it's crucial to know it because no manager will ever point you to that book. Because managers, they are only if they are really smart, interested in you writing clean code. Because writing clean code means thinking long term, thinking and and really taking your craft serious, and that often contradicts to what bad managers want: get stuff out fast. No matter how many quick hacks there are, and how about the code agility? Yeah, code agility is. I would say that this is I I just made this up. Um, I don't know where you have it from, but like the the draft of my Dreamforce abstracts that I I'm going to submit talks about code agility. I mean, the the word agility in the software world comes from Scrum and planning. It means how can you Yeah, agility means how can we? We all don't know how the the worlds and the requirements will change in the future, so we we not. We we try not to make things that we have that we build to to fix and to rigid. So we want to stay them changeable, and and this this needs certain processes while
[10:44] planning, but processes are not enough if you do perfect iterations and sprints and are very agile from a planning. You can still bake your software in a way that it basically. Explodes after a year if you just bake on feature, feature by feature, without thinking about architecture and without refactoring. This this doesn't work, and that's what all the the anti-agileists said for years. They said Scrum or agile in general doesn't work because there's not no big upfront planning. It's just thinking about story and another story. And really believe in this agility in this this way of planning. I don't believe in this big upfront architecture stuff. I never did, and I I saw it in my own career that it doesn't work. But if you do do Scrum perfect, you can still totally mess it up. So, and I switched from being a manager, a Scrum master, to a developer very late in my career. So I basically think I'm a very good person to talk about because I yeah I found it out on my own. So, code agility means what you have to do to your Salesforce code, to Java code, whatever, to to to to also be agile there, to be flexible, to to
[12:14] to change stuff later. Okay. Um, you talked about the code agility and also we touched the clean code. I still want to go back a little bit the clean code because it's such an important topic. And especially back in school, I was never told to write any clean code at all. So now, that's when we use the Git. We have the Git blame. When we see a really crappy code, we tend to really check who was the author of the code. So, and it was really important to to write the clean code, which is easy to understand, easy to interpret, easy to maintain. So that's all about how to write clean code. So I really recommend everybody who listen to this episode, if you haven't read the book from Uncle Bob, this Clean Code, you definitely should go it through and see if that fits you or not. It it it fits everyone, no matter which language. Yeah, I I loved it. It's it's it's really just valuing the fact that code is more read by humans than by computers. It's trivial. You can basically write assembler. The computer will understand it. Why did we make up such wonderful complicated languages like Java, and why don't we? Don't just write machine code. It's not only because the programmer is not able to do
[13:45] it; it's also because the the next programmer is not able to to read it and understand it. The machine doesn't care how you call a method, but you will care a year later or your fellow developers. Exactly, and most of the concepts in the book are easy to grab. But of course, really hard to master. If you already understand the concept, then in your next project, your next programming tasks, you tend to, you know, more be aware of something that you should improve in your coding skills. That's right. That's right. It it might. It's often very counterintuitive to junior people, and they they tend to think the opposite is right. Like they put ah those ugly Java um comments on top of any trivial method. Like a method that is just giving back a name, and it's called get name, and then they they put this Java doc on top where it said when they wrote it and what their name is, and that it turns there's no exception thrown and stuff like this, and then they read this book and it says don't comment because com comments are an excuse for badly written code if you're Method is clean and short and has good names and and has a has many test methods which basically prove that it works. You don't need to comment and you also need doesn't
[15:15] don't need to comment. Refactor this later. No, put put a refactor user story in your sprint and then just do it. I've seen so many bad code comments, but but junior developers they still think commenting is cool. Makes make it cryptic and then comment how it works. It's the other way around and. Instead of instead of having the other developer think hard about what you wrote there, think about how to write it in a way that you can just read it from reading reading it. Yeah. Right. I remember there is a really. Maybe a old saying. I don't know who said it originally, but I strongly related to it. the The saying goes like this: Everybody can write code, but there is a huge difference between writing code and writing good code. So if we want, yeah, I guess this this this saying works for basically everything. Everybody can cook water, but it's really hard to be professional, the top. Yeah, cook good. So if I give you a ton of great exotic ingredients, yeah, you can make up something that's really spicy and good, and people will say, "Wow." But if I just give you a little bit more time and just a boring programming language like Apex, which isn't. Super cool. It's just like a copy of JavaScript minus a lot of stuff. It
[16:45] really takes a while. Yeah. And and by the way, one of the reasons I like clean code is that it's not about scientific stuff. It's not about data structure, algorithms. It's about communicating to people, right? So everybody can learn that. It it it helps when you know when you know some patterns there are some I will I plan to talk on that in my my Dreamforce talk but when you know how to to build objects that that work together there's there's way to to basically write fluent. Method names, and if you know how to do that, you can write better, clean code. If then, if you don't know that, so I think it's not the book I would give like a very junior developer, because he also cannot feel how how important it is. But you're right, it's it's not about any scientific stuff.
[17:47] It's really on a on a on a language agnostic level. Okay, I guess we have said enough about the Clean Code book. We have done our advertisement, even though we don't get any paid on this, right? Yeah, because we really love that. How about the code agility you mentioned? It's it's like an extension from clean code, and also it's like the agile way to plan your software design, the architecture, right? So, and you also touched why is it important? But could you? Elaborate more about this topic, the code agility, especially like how we can really measure it, how we can say, okay, my code has a high agility now. Okay, I just want to restate that this is just a made up word. Yeah, yeah, it's it's good. You are the author, you know. Made it up, but but I would say when when I look at our product code, adopt to go, I would say it's agile when. I don't fear the customer change his mind about a feature. I when I was a young developer, I basically hated all those planning meetings where they said, ah, the customer changed his mind. He also wants to have it in German, or he he just wants to add multiple currencies, or. You know those moments when you say, "Oh, why didn't you tell me that a
[19:17] month before?" Right, and you. I would say you have code. Your code is agile when you don't fear a customer to change his mind. No. You you actually love it because every time when your when your product manager comes along and says, hey, your guys were right, we need it that way. You say, hey, no problem. When you you you have agile code when you don't bake in stuff. What do I mean? Maybe it's it's it's a bad translation from what I mean in German, but um. When you go, when you when you have to add a feature, and then you go into a really long spaghetti class, and then you think, okay, should should I add those ten lines between line two hundred eighty and two hundred ninety, or should it do it in line eight hundred ten? This is baking in stuff, basically make your code die fast. Okay. Without understanding the rest, you you bake it in, and this is not agility. This is basically, I don't know. It's like putting a putting. Putting a time bomb into code that is already rotten and agility means okay yeah then I just make a make a super class move all the code that is redundant into the super class and use some basic inheritance whatever. And then it works. And then you even while doing
[20:47] that, you think about okay, when I have to do something similar a third time, I will even do some improvements. And and and just imagine this this way of working. You you already. You already knew that this would happen, and you you thought about it. But this doesn't mean that in the first place you really spend a month just thinking about what could come. It's it's something that you just do. You don't build build quick hacks. So I would say when we do planning poker, when we do our sprint planning, and when we have some more junior developers, I would say. There, there are two types. the the The one says I need, like just a day, and the other one says I need twenty days, and I'm somewhere in the middle. I need more than the optimistic junior developer, and I always need less than the pessimistic junior developer because the optimistic he really thinks about how just just to hack the feature, and and making it in a way agile means thinking about what could come. That somewhat explains it. Yeah, and another thing. I often hear me saying is, for for writing agile code, you need to have some values that are not intuitive. A
[22:17] value is that you that any pro any line of code that you have not written is a very good line because it cannot have bugs. It must not be reviewed. You don't have to test coverage it. And this is what programmers they think. Hey, I I can do it. I love it. I get paid for it. I want to write nifty complex functions. And no, if if you can do it in Salesforce with clicks and not code, do it. This doesn't mean you should always use clicks, not code. I often have a discussion if we should do it in Flow and Process Builder, and I always say no because it's not efficient. It it it it doesn't work with governor limits. It doesn't work with our managed packages. But if we could do it, I would immediately switch. And when I look at the evolution of our product, in the beginning we wrote we basically reinvented everything in code. And we even introduce stuff from the Java world that were not required in in Salesforce, but and yeah, less code is better code, and then and that simple code is better than. Complex code, and we, our
[23:31] boss often uses this Steve Jobs metaphor. There can be you can, you can have like an an MP3 player, um, like there were back then, very complex with a thousand features. You can basically do everything, and then you have this iPod, which can just. Basically, play good music, and this is—it means a lot to to get a product and code. That that simple, and it's it's a high sophistication, but I like code and a product to be like an iPod and not like one of those. Those dinosaur MP3 players with thousand at one buttons. Okay, all right. Ah, so I just trying to recap your information here is that if our code, our solution has a good design, flexible, robust design, it should be simple. Like the metaphor you mentioned, the iPod, we can easily add features, we can easily remove features. So those things should be flexible in our code, right? That's important. That's important. Adding, especially removing, a good like an agile software makes it easy to remove stuff without breaking stuff. Everybody, everybody hates breaking existing stuff, and I often hear. People say that we shouldn't remove that. We don't know how it depends,
[25:01] especially in a platform like Salesforce. In the Java world, there there are tools that can basically tell you if there's a dependency, but in Salesforce world, it's often guesswork. And if you if you write your code with agility in mind. It's easy, when when somebody says we remove it, I say yeah, just let's do it. If if if anything is broke. Next night, we might get some test emails from our CI system, and then I see, oh yeah, I broke stuff. Yeah. Okay. So it's really not only even about coding; it's also about the process around. How do you plan, and how how secure is your safety net regarding tests and People who check the quality of the product and yeah okay, so most of our listeners, I assume they are the Salesforce technologists, either developer or like architect, like your role. How could we learn the code agility, the concept you mentioned? Do we have like design patterns or books or articles or something for us to follow? I I love this concept, but it's kind of like in the ideal world, everybody knows that's the best solution. But how to reach that in the practical world? And. Good question. I could say, yeah, come
[26:31] to my Dreamforce talk if I if I get accepted. But okay, but I didn't came up with this. It's I would say it's it's it's a mixture of a lot. It's But but I'm still having problems to really find like one one sentence how to do it. It's. I mean, you have to know all the basics. I think you cannot learn about code agility without having learned about all the other stuff. So curiosity about your craft of software development, without reading about what's out there, clean code patterns, test-driven development, about lean development, it doesn't work because you are basically missing all the values and principles behind it. But yeah, and sorry, I'm
[27:26] throwing you such a big topic, but people want to grab it. We we love this concept. Yeah, they want to grab it. Yeah, I'm I'm not really good at um um. I can describe it, and I think if I talk about it, um, I can. But um, there is, I mean, a book like Clean Code. Actually, they could call it, yeah, code agility, but but clean code is just a better name. So the values conveyed in clean code are, actually, it's enough. But um, what I plan to add when I talk about this is how we do it in Salesforce and what do we outside of the code. So I will talk about how important it to it is to. To leverage open source, so because leverage what other people did, because this makes you really agile. Maybe I can just iterate a little bit on that because I know you. We also want to talk about PMD. Exactly, because I have been in Salesforce only for a bit more than three months, but I have already noticed. There are difference between Apex and Java or C Sharp those paradigms, so so how especially for Salesforce developers how do we apply this code agility or clean code into our work? I think they're definitely something
[28:57] unique we need to grab right. So. So yeah, that's something we really wish you can push forward. If you get so you have already subscribed, should I call it subscribe or submitted? Yeah, and I'm going to submit it. I. I asked for review for few people and um, but I'm planning to do two sessions. The one is about, um, this code agility. So our story from an I C V perspective, how what we do. I want to show code. I want to show patterns. I want to. I want. I basically just want to tell people how we do it, and be great if people. I really. I show them our life system. I show them our, our defect tracker. I show code, whatever. Because I I really would like to talk to other people about this topic, and the other topic is about PMD, this open source project, which I talked first on Dreamforce two years ago. A lot of has happened in in those two years, but now I really want to get more people interested in the topic, even in in contributing to PMD because it's open source project, and I think such a talk could help to. To make it more proficient, is is there any chance listeners and I could influence the result of your your thing over there? I don't know. It's
[30:27] like it's like a voting. I don't know. I no. Yeah. You can tweet about it. Sure, you can. Okay, I I would definitely do that. I mean, I mean, we we want this. We want it. Yeah, sure. Okay, it's great if people. It's great if people come and I I think there's a good chance. At least the the PM, that it's it's. I will not talk about PMD. I will just talk about like automating the this boring part of code reviews. And and we'll show PMD as as one tool because there are many other cool tools out there um which which are sometimes which are not open source but but do some stuff more and I it it should be it should be helpful for a broad audience even if they want to buy a tool but PMD is is free and I like it and. Yeah. Okay. Cool. I got it. So, yeah. When when does the result come? Oh, I think the submission is until mid of July, and then I hear. If if I was accepted, I think at the beginning of August. Okay, okay. Accepting tweets from me with tears or with champagne, champagne emoticons. All right, I I really wish we will get that, and I will try to publish this out before.
[31:57] Your sub, the submission. So I think we can get more audience on this. Thanks a lot. Yeah, no problem.
[32:10] Hey, thanks for listening to the end of the show. I really appreciate you spent your time with me, and I'd love to connect to you, my listeners. If you have any advice, idea, opinions, or simply greetings to each other, my Twitter, LinkedIn, email information can be all found at the website SalesforceWay dot com. Oh, by the way, it occurs to me some of you are not yet subscribed. If you're one of those people who are not subscribed to the show, go SalesforceWay dot com, hit the RSS feed or the link to iTunes to subscribe. So you won't miss any of our shows in the future. Okay, so with all this out of the way, I'd say having a great day and see you the next
[33:01] time.
