Logo

Software Developers Journey Podcast

#204 Scott Ford is a software mender

Resources

Highlights

Introduction and Early Interest in Computers (00:00 - 05:33)

The podcast kicks off with Scott Ford introducing himself as a passionate software developer who enjoys the art of rejuvenating existing, older code. His early exposure to computers fostered an interest in technology, and he spent a considerable amount of time experimenting with code in his youth. He encourages aspiring developers to adopt a self-driven approach to learning and to remain open to constant learning in the ever-evolving tech landscape.

College Years and Developing Problem-Solving Skills (05:34 - 09:45)

During his college years, Scott pursued a degree in Computer Science and a minor in Mathematics. He asserts that the structured academic environment, coupled with the problem-solving nature of mathematics, enhanced his programming skills. His college years taught him to think abstractly and logically, which has been instrumental in his career. He recommends a similar approach to junior developers, encouraging them to leverage any opportunity that broadens their thinking horizons.

Stepping into the Professional World (09:46 - 15:02)

Scott speaks about his transition from college to the professional world, which introduced him to the challenges of real-world programming. His initial job required him to modernize an older system, sparking his interest in legacy code. He reminds new developers that the tech industry is not just about writing new code but also understanding and improving what already exists. Flexibility and adaptability are essential traits in this dynamic field.

The Entrepreneurial Journey and Importance of Business Fundamentals (15:03 - 24:50)

Scott shares his entrepreneurial journey co-founding Corgibytes, a company that focuses on modernizing and maintaining legacy systems. He discusses the struggles of handling business tasks and stresses the importance of understanding business fundamentals. His experience underscores the importance of business acumen, even for technically focused roles.

The Art of Mending and the Appeal of Legacy Code (24:51 - 32:15)

Scott delves deeper into his fascination with legacy code and compares it to the art of mending. He takes pleasure in fixing and improving existing systems, rather than starting from scratch. He suggests that developers, especially those starting their careers, should not dismiss the idea of working on legacy systems. It presents an opportunity to learn from past decisions and strategies while improving their problem-solving skills.

The Mentorship Approach and the Power of Narration (32:16 - 38:25)

Scott explains his mentorship approach, which involves explaining code in a narrative form. He believes that narrating code helps in understanding its function and enhancing its readability. He advocates for the power of good communication in coding and encourages developers to incorporate it into their practice.

Legacy Code, Rewrites and Sustainable Solutions (38:26 - 49:17)

The discussion then focuses on the common urge to rewrite legacy code. Scott encourages developers to question this impulse and explore more sustainable solutions. He suggests gradually transforming and modernizing an application, which can prove more beneficial than a full-scale rewrite. This approach underscores the importance of patience and a step-by-step methodology in programming.

Concluding Remarks and Final Tips (49:18 - 50:47)

As the conversation winds down, Scott shares resources where aspiring developers can learn more about legacy code and engage with like-minded individuals. He concludes by reinforcing the importance of curiosity, continuous learning, adaptability, and effective communication in a developer's journey. His story inspires developers to embrace both the challenges and rewards that come with managing and transforming legacy systems.

Enjoyed the Podcast?

If you did, make sure to subscribe and share it with your friends!

Post a review and share it! If you enjoyed tuning in, leave us a review. You can also share this podcast with your friends and family and share lessons on software development.

Become a supporter of the show. Head over to Patreon or on Buzzsprout.

Got any questions? You can connect with me, Timothée (Tim) Bourguignon, on LinkedIn, per email, or via my homepage.

Thank you for tuning in!

Transcript

⚠ The following transcript was automatically generated.
❤ Help us out, Submit a pull-request to correct potential mistakes

Scott Ford 0:00
A big one, I think comes from. It's an old blog post by Joel Spolsky. He talks about how every line of code in your program defends against a bug. So it exists to prevent a bug. Whether you know it or not, that line of code is there to prevent a bug. So how confident are you that when you build the replacement, you're gonna prevent all the same bugs.

Tim Bourguignon 0:26
Hello, and welcome to developer's journey to podcast, bringing you the making of stories of successful software developers. To help you on your upcoming journey. I'm your host, Tim bourguignon. On this episode 204, I receive Scott Ford. Scott is a co founder and CTO of Corey bytes, where he has quietly led a software maintenance revolution for the past decade, where most people find nothing but frustration Shamen bugs in legacy code, Scott has centered his work around his genuine love of software modernization, and helping others use joy, empathy and technical excellence, to make their systems more stable, scalable, and secure. Scott has authored three courses on LinkedIn learning, and he's a fellow podcaster. He's the host of the podcast, legacy code rocks, Scott, a warm welcome to the afternoon.

Scott Ford 1:24
Thanks him. I'm gonna be here.

Tim Bourguignon 1:27
But before we come to your story, I want to thank the terrific listeners who support the show every month, you are keeping the dev journey lights up. If you would like to join this fine crew and help me spend more time on finding phenomenal guests then editing audio tracks, please go to our website, Dev journey dot info and click on the Support me on Patreon button. Even the smallest contributions are giant steps toward a sustainable dev journey. journey. Thank you. And now back to today's guest, Scott, the show is is to help listeners understand what your story look like and imagine how to shape their own future. So as usual on the show, let's go back to your beginnings. Where would you place the start of your journey?

Scott Ford 2:19
Yeah, so I think like it's easily High School back in 9697. And I took a computer programming class, it was basic. And I somehow already had a lot of that information in my head. And then after reflecting back realized that I had been like checking out books in the library on like, how to program and things like that for years. And like writing down like little programs in notebooks and stuff. So the teacher grew frustrated with me and threw me in another student can often the corner and gave us challenging hard things. So we would stop disturbing the class by asking questions, but I think that release kind of set me off on learning independently, and kind of learning at my own pace. And that has really kind of stuck with me throughout my career. The roles that I've enjoyed the most are the ones that really let me learn at my own pace really let me kind of de vet that can't even dive in and kind of follow my curiosities wherever they happen to take me that teacher I remember one day came in and he handed me and my friend this like small little white book and it was titled a book on C and he said we don't have a C computer programming competition team. So you too are at no pressure because the like this I think it was like C or C plus was being offered by the by the group that that they normally entered Pascal competitions into and so he was like we have nothing to lose. So the two of you will be the two of you will be the C team. And like that was the first time I'd ever even seen the language was learning that I was going through the competition team and it was also my first time learning about competition computer programming. So

Tim Bourguignon 4:05
why don't you think about data and going from basic to C Yeah basic

Scott Ford 4:08
straight from basic to C and then really enjoyed it and like diving into in differences between C and skills c plus at the time and then getting curious about Pascal because Pascal was the AP Language until my senior in high school my senior year in high school the Advanced Placement language in the US was a c plus prior to that it had been Pascal so all that studying I did on CNC paths and then switching to Pascal because I was trying to get ahead for the advanced placement course that was going to that I was going to take as a senior to change the language the Advanced

Tim Bourguignon 4:39
Placement is basically the the a level or the baccalaureate, which which you do too.

Scott Ford 4:43
Yeah. It's it's similar to like baccalaureate or it's like college. It's a test that you can take to get kind of like college placement credit. If you do well enough. It's a pseudo college level course. Thanks Yeah, yeah, thanks for Ask And I forgot that there's not a nuts not at all US audience. So my apologies for being so naive and but really dug in and just got curious about like the similarities and differences between basic and Pascal and c plus and then the the teacher had had grown frustrated with pretty much everything that he had tossed at us, and eventually said that our that we had to write a text editor, but we couldn't use a GUI toolkit and the computers in the computer lab that we had access to were pretty old. So they ran DOS, DOS five, and we were working with Borland turbo C++, oh three Oh, and Borland Turbo Pascal seven. And he was like, read it read write a graphical editor, similar to the ones that we were using when we were using Turbo Pascal, where you could move the mouse around in this giant block giant and textual block, like floats around the string, screen use, like, figure out how to do that, but figure out how to do it yourself. You're not allowed to use any libraries. And that shut us up, because that gave us plenty to chew on. But that was really diving in deep to Pascal diving in deeper to the operating system to try to figure out like, how do we move? How do we get? How do we get this block of this block? That is the mouse to move when we moved the device and things like that. And when we get to draw a pulldown menu, how do we put the text back that used to be no matter what it was, and so ended up figuring out how to ask the operating system for the contents of the video memory. So we could render it back and doing all this in high school, and just having fun. And then going off to university and my parents didn't have a lot of money. So I ended up working while I was in school. So I got like a work study job my freshman year was helping maintain a website on campus. I went to Virginia Tech in Virginia. And but there was a job fair that came up. And there was a company that was advertising, internships. So I applied and I said that I was not only interested in in internship, but I'd love to work part time during the school year, if they would let me. And this library automation company that was just off campus, they took me up on that. So I got to be I got to work here as an intern for the summer and then part time to the school year. And the my first day that summer, I got to meet my the person who's going to be my mentor, still a friend of mine, somebody I'm still in touch with. And he said congratulations, we're so happy to have you here. I'm really looking forward to being your mentor. I turned in my notice today. So in two weeks, I'll be gone. And you get to inherit everything that I worked on.

Tim Bourguignon 7:34
Wow.

Scott Ford 7:37
So So we've got two weeks to get you ready. So and the this company was using Delphi for for Windows applications. And so all that experience I had working with object oriented Pascal, when I was back in high school was really handy. And that that seemed to cinch the job interview when they were like they're like, Yeah, we're around here. We use Delphi. It's similar Object Pascal. Like I know Object Pascal. They're like what you can do Object Pascal, nobody knows Object Pascal. So yeah, so I dove in. And like, here I am my second year at university. And I'm owning these applications that are in production. I mean, they were tiny, they were kind of tiny. And they were off to the side, like one of them was for helping translate the user interface into all the localized languages that it was rendered in. Another one was the version of the the UI component library that they used to handle multiple languages at the same time. So at the time, Windows didn't have very good support for multiple character sets. So when you would, you could install windows in your local language, localized language. And that was pretty much it. So you could install like the Arabic version of Windows or the English, US English version of Windows or the French version of Windows. And when it installed the character sets for that version. And so but UTF eight, Unicode were out and had been out for quite a while, but that option wasn't all that great. So they had taken the they taken this UI component library and they had made it so that the all of the strings that it passed around in memory were UTF eight, and that it rendered it by converting from UTF eight to the local code page of whatever operating system was running on. So my desk became the test bench for all of those all of those odd combinations. They also modified that UI library to work in right to left mode. So if it was like Hebrew windows or Arabic windows or the start button was on the opposite side of the screen from what you're used to if you're reading right to left language or left to right language rather, so I had like Hebrew localized Windows installed on a computer on my desktop it was like dual booted so I get to like pick like four different versions of Windows and just like counting down bugs and like this textbox on this screen when you on the Hebrew version Windows when you type in English character, it shows up in the wrong spot. Right? And like a bug like that you're like, like first, like, make it happen, right? Like, and sometimes that would be, you know, like, okay, install the OS like running, try to replicate the problem like, Okay, now it's happening. But why? And this was like diving into documentation for for like the windows 32 controls and things like that. And then the source code for the UI library that we had to work with, and then trying to find the problem and trying to fix it. And hopefully it worked. But those tiny little like, those tiny little bugs like that, that were probably really annoying to a significant audience. They weren't super critical, right? It's not like there weren't hundreds of 1000s of customers who were clamoring to get those things fixed. So it was a great thing to throw at the intern. Right? So and yeah, I just I loved tackling those problems. And having fun with that. I stayed in touch with my mentor, that person who kind of said, Nice to meet you Peace out, he went to work at a place right across the street. And I would eat lunch with him. And one day, he said, Would you like a job. And so it had been about a year, but I applied to work at the place that he was at. And he was working on some cool stuff. His company was working on the X 31 experimental jet, which is currently in I know from you and I chatted before the show that you're in Germany and the x 31 is in a museum in Munich. So if you're ever done that way, you can go take a peek at it, be there in two weeks. There you go. You go check out the Aviation Museum, and go see the plane that I worked on. And yeah, so what he and his colleagues did on that on the extra one is they took the there was this like, giant flowchart that was written by engineers, people with PhDs in terms of like, how airplanes are supposed to work and aerodynamics, and they knew tons of stuff, right. So they had like, defined like all of these, they called them control laws. So all these control laws for how the airplane was supposed to operate and how the flight control system was supposed to work. And it was my friend and his team's job to take that, and then translate it into the programming language that ran on the airplane, and then was jovial. I never heard of that language before. I don't think I've heard of anybody using it since. And I was like, Oh, cool. That's exciting. And I'll get to learn jovial but no, that's not what I worked on, what I got to work on, was there was a program that was used to take the compile jovial, essentially install it on the flight control computers that ran on the aircraft, there were four flight control computers, and each one had the same copy of software running at the exact same time. And so this application would, was responsible for loading that software on the aircraft. And then it was also like a debugger. So you could like you could run it, you could basically like watch a variable that's in memory on the flight control computer. And you could see how that value is changing over time, and you could manipulate it, you could change the value in memory, on the flight control computer, and then make sure that things happen correctly. And there was a scripting language for it. And that scripting language is what they used for all their automated testing. So it was it was a load tool. It was a debug tool. And it was a testing tool. And at the time, it would only run on 286 Mega 286 era in Intel computers. And at that time, you could walk into a computer store and walk out with like early Pentium 200 megahertz. And there's like this 100 megahertz tuner megahertz, 400 megahertz, like those were things you could buy. But then there was a 4.66 megahertz computer that was kept alive back in the lab. And keeping it alive was really challenging. And it wouldn't, the software wouldn't run on anything more capable, because of the way it had been built. If it had more processing power, or more math, more more RAM, then calculations would go wrong, the tests would fail all these like giant test scripts that were written because the aircraft had like two lives it was it was built in the late 80s and flew for some experiments, and then it kind of went away for a while. And they brought it back out to do more experiments. And this was a joint project between United States and Germany was and so we had some folks from Germany in the lab for the aircraft. And yeah, it was really neat. So what I was tasked to well, my team, me and my mentors working on this like only like 10 hours a week, if that was tasked with reverse engineer the software that runs on the 26th and build a version that will run on an off the shelf computer that we could just go buy it on the street. And it wasn't expected to be successful. So we didn't get a lot of prioritization time. So like our access to hardware was really limited, but I think we had a flight control computer at our office in Blacksburg, Virginia, for a little bit. But then anytime we wanted to work with an actual flight control computer, we had to travel to the Naval airbase, which was just several hours away. And when we got there, because our project was such low priority, and it wasn't expected to work, we got lab time when no one else needed it, which was usually at night. So we would start our lab shift at like 8pm. And we would work until 8am, or 6am, when people came in, and we would try to queue up like all of these experiments and things we wanted to try, and then we would try them. And then we would work all night and get some sleep. And we come in the next day, because we're usually in town for like a week. And it was around my school schedule, I was still at university during this time period, working on my school schedule. And but yeah, we were ultimately six on were able to run all of the existing test scripts with the very minimal modifications, we didn't have to change much at all. And we significantly increased the throughput of the test scripts, were able to decrease the amount of time it took for the automated test to run by several orders of magnitude, if I remember correctly, like I remember it taking like on the order of like a week to do the the automated testing, and we got it down to just a couple of days. So it was like, it was huge. And just learned a ton, learned an absolute ton and then graduated and went on to work on other stuff. And you know, I did, I did some more library work after that, again, working with more hardware, but then like, I wound on my way into working on web projects. And I was noticing that on the web projects. There. The the level of discipline that I had been exposed to for like testing for like, like testing was really valued when I was working on the aircraft, it suddenly wasn't really valued much when I was working on these web projects. But the challenges and problems that I was seeing people run into were the same. I mean, the level of criticality and the level of severity of being wrong was very different, right, like crashing an aircraft is very different than getting payroll wrong. Right? It's just it's different levels of

Scott Ford 16:56
consequences, right? The consequences are very different. So the how critical you are, when it comes to safety is different as well. But there were like things that definitely could have been could have benefited from. And so I would propose like, hey, let's do TDD on this project. Or this method. We keep having to fix bugs and and over again, can I spend some time and refactor it to try to make it so that we don't have to fix bugs in it as often or when we do? It'll be easier. Like it'll be easy to read, easy to work with. And I kept getting told by managers that like, like, No, you shouldn't work on that. Like, this is like after I graduated and like off working on on different stuff. Like no, you shouldn't work on that. Like that's a waste of time, go stop fixing bugs, and go work on features,

Tim Bourguignon 17:39
and not pay to write test. You're not

Scott Ford 17:43
exactly. We heard that when you people who tests like, we don't need you to we don't need you to be reading tests we so yeah, I got really frustrated with that. And I dropped a lot. I dropped a lot. So by the time I was 25, I had worked for four different companies

Tim Bourguignon 18:03
wise,

Scott Ford 18:05
I would leave, I would leave to get more money and get bored and then come back for more money.

Scott Ford 18:20
And yeah, it was really strange. And often I would be working on something completely different. When it came back. It wasn't always the same stuff. But I think like my average tenure at any one company was like eight months, that was like kind of the average. So I would hit this eight month point and then just like, start getting itchy. I need to go find a new job.

Tim Bourguignon 18:38
Before you will further Yeah, you often hear this advice, stay at a company for longer otherwise, you're gonna hear well, you're doing job hopping, you're not reliable, etc. Did you have a problem with that?

Scott Ford 18:48
I didn't until I did. Okay. Yeah. So I hit this point where everywhere that was willing to hire me twice, or, I don't think anywhere was willing to hire me more than twice I had already worked at in the area that I lived in. And so I might hopped too much. It was I was living in a rather rural area where there weren't a lot of tech jobs and everyone that was hiring I had already worked at and they didn't want me back left for a third time anyway.

Tim Bourguignon 19:25
You could try now and see if it works again. Or not. But yeah,

Scott Ford 19:30
and then it was like quite a quite a while later, when kind of in the back of my head through throughout a lot of that was this idea that I wanted to start my own company one day, I didn't really know what or why or how. But I wanted more control over my own destiny. And so that's where kind of where you actually came from was this desire to kind of own my own destiny. And when I created it, I thought I was going to do like a casual Will games for the Mac? This is before we could write programs for the iPhone? And yeah, so I thought that's where I was gonna end up. I had done a few experiments, tried to sell them online, but I think I had a very much how to if you build it, they will come idea of marketing, which doesn't work. By the way, if you're listening to this, and you have that idea, like try to find somebody who knows what they're who can help you with marketing. And that's what I did, I realized I had a marketing problem. And so got in touch with a friend of mine from high school, who had started her own marketing business, and met up at her 10 Year 10 year high school reunion and was like, Hey, I've got a marketing problem. Can you help me with this? And so we met the next day. And she just picked apart everything, all the ideas I had. And I was like, oh, man, where do I go from here? And then she goes, Oh, it's so simple. Here's all you have to do. Just start your own consulting company. And then through consulting, you'll start to notice patterns. And from those patterns you'll identify needs in the marketplace. And then you can build products to solve those needs. It's just go do it.

Tim Bourguignon 21:02
There's some air quotes somewhere here.

Scott Ford 21:06
So it's like, wow, like, it's great that it's easy to you. I'd love for more help. And but I can't afford more help. Because this business, isn't it on the back of a napkin at this point. Like it existed as a legal entity, but it had no money, right? Like it was just me. So I was like, how about you have 51%? In we run with this and then see where it goes. And so, so she did and then we ended up getting married later. That's where the 1% comes from. 51%? Well, no, it was partly like, like, it took just as recognition like you're in charge, right like, and kind of the idea of like, I would have rather had 40 49% of something than 100% or nothing. At that time, I had 100% Nothing like and I didn't think I was going to be to make it go anywhere on my own. And I had been looking for someone to be like a co founder with me, someone who I could like turn, like become a co founder, because I'd seen in Y Combinator, they had a they had like a how to like get funded by back at the time, this would have been like 2006 2005 2006. And one of the rules they had was that they didn't invest in single person companies. And their justification was that if you can't convince at least one other person to take that crazy journey with you, then how are you going to sell customers?

Tim Bourguignon 22:21
Like, interesting take?

Scott Ford 22:24
Yeah, so I was looking for that one other crazy person. And so a 51% stake is what it took to give it a go. And then let's give it a go. Because it wasn't working on my own. That's for sure.

Tim Bourguignon 22:34
So do you did you take her advice? And really start with consulting? Yes,

Scott Ford 22:38
yeah. Yeah, yeah, we started with because consulting, we're still doing consulting. And then we knew really jumped around a lot in terms of what our business model was. So at the time, what we started out with was building websites for people. So if you needed a website, under his background, at the time was in copywriting and marketing. So the idea is that she would write it, I would build it, and then we would partner with a designer to make it happen. And so we started networking with graphic designers. And we're kind of thinking that, like, if you were a freelance graphic designer that wanted to take on a bigger project, that we could help with that. And we had some traction, but you know, we were about seven or eight months into it, and I got that itch again.

Tim Bourguignon 23:22
How'd you leave your own company?

Scott Ford 24:14
We did so like we I was realizing that I wasn't really enjoying a lot of the projects we were taking on finances of starting your own business were really hard. So I went and got a, you know, a real job at another consulting company. And this time really tried to take notes of like, because I had like for money, my own I'd seen all sorts of stuff go wrong. And I was thinking like, well, let's pay attention to how they solve the problems. And Andrea went off and did the same. And again, about six or seven months I do it like I stopped liking it. And I was noticing that they're repeating all the same problems that we were having, and I don't feel like their answers are any better than ours or so. Andre, and I really like let's give it another go. But let's really think about like, what should we work on? Right? Let's be smart about it. So on Yuri sat me down. And we looked at like everything that I've ever enjoyed working on. Or like, Why did I keep job hopping? And especially why didn't I go back like, and realizing that there was this magical period, when I first got to new to new company, everything was new. And it was a completely new codebase to me. And I got to kind of do that independent learning that I mentioned from the beginning that I really enjoy. And it was like a puzzle. And often, when I joined a new team, they were like, go fix bugs in the system. And then I would graduate somehow, and be told to stop fixing bugs and go work on features. And like, well, that's you, I really only want to fix your bugs. And so like, this is a story I told Andrea several times before, and then we were watching the home improvement show this old house. And I was just watching the like, the way they were working on a house. And I was like, that's what I want to do. And Andrew turned to me and goes, Are you telling me you're gonna quit working on computers, and you're gonna go move to Boston and work on or Conal houses are gonna, what they're doing for houses I want to do for software. Like, that's what I like doing. Like I like I like cleaning up messes that have been left behind by other people, like, I genuinely enjoy it. Like I enjoy fixing bugs, I enjoy solving really hard, challenging problems, I get less excitement out of using something new just for the sake of using just for the sake of using somebody new, right? Like, there are some people who like really excited about like, let's start a brand new project, let's use all the new stuff. It's a completely blank slate we can we can avoid all the mistakes from last time and create entirely new ones on that device. Or like, oh, let's rewrite this right? I get so frustrated with, you know, consultants and dev teams who would come in and say, look, the problem with this system is it needs to be rewritten. Right? Like, and if we rewrite it, everything's simpler. Everything's easier we get to. And I was like no, like that. That can't be the long answer. There has to be a way to just start with what's there and make it better. And so that's what we made our business model when we kind of rebooted the company after we both left our real jobs on that's the business model we've had since and I haven't wanted to quit that. But it was like it took like, I mean, that was a good 1011 12 years to figure that out of like every six or seven months going like, nope.

Tim Bourguignon 27:32
When you're stubborn. I speak from experience. I did exactly the same thing on the people side. I took on software developer jobs and was happy coding. And then after a couple of weeks a month I landed in a PPL II place more taking care of people and say, Nope, I want to code. Yeah, yeah. Job quit project. Go back to coding. Malls online. Same thing. Yeah. It took me 12 years to realize it. So.

Scott Ford 28:05
Well, yeah. So I think like learning what you like, and learning how to say no to what you don't. That's probably the big lesson that I've taken away from my journey so far. And then really kind of leaning into the idea of, I really liked that independent learning and discovery. I like having to figure stuff out on my own. It's not that I have to work by myself. Like, I like working with other folks. But I really like at least like it when the team is like struggling. Right? It's the struggle that I really enjoy. That's the the hard problems that I enjoy. I don't the easy ones. don't excite me all that much. It's how are we going to do this? Is this possible? That's fun. Let's we know this is possible. Let's do it as fast as we can. That doesn't excite me. So I think that's why like you legacy code or like in that I don't mean like old ancient COBOL systems, it's something you wrote a week ago can feel like it's now a legacy that's holding you back, right? If it's a project that you've inherited from somebody else, and there are challenges with it could be that it's a system was written like 10 years ago, and it's been neglected all of those 10 years. But suddenly, the owners of the companies that depend on it, finally noticed that just how critical and important it is, and now they're ready to invest in it. Well, it's 10 years old, and they really want to invest in it. And it works. It works the way they want it to, but they want it to be more modern. So they hire people to work on it. They want to avoid security issues where they wanted to be more performant. And they do have other things that they would like it to do in addition to what it but they definitely don't want to break anything and it does already. That's a hard problem. Like I don't care what tech stack you start with, that's gonna be challenging. And that excites me. And that's what I get really giddy about. And then some of those patterns have started to show up over and over again. And we're now getting to the point within the company's journey where we're starting to, you know, experiment with building a solution. Most of those at least, if not products, at least a like a prescription of like, these are the steps you need to follow. Right? And perhaps those steps can be automated. Yeah, there because there are things that come up over and over again. And

Tim Bourguignon 30:18
there's no question there. How did you it's more than you and your wife now? Is it? Yeah, yeah. So

Scott Ford 30:25
we have worried about I think, 18 total, folks. Okay, so,

Tim Bourguignon 30:30
yeah. How do you find people who really find joy in in this kind of work? How do you screen for that? How do you find those people?

Scott Ford 30:40
Yeah. So that's another story entirely. So when when we first started experimenting with this kind of this work, we like, Can I curse? Oh, absolutely. Okay. So I had a mentor of mine, he used to sell me to other teams within the company that I worked at, because there was a larger consulting company that I worked at for a while, where I got to work on different projects within the company. So I was there for about two years. But I still work there twice, he would sell me to other teams by saying, just have Scott come in Hello, unfuck your project. And so we tried to run with that. So like we did on F store on f your project. And we got a few bytes that way. And then so I created a I created a talk that we started pitching the meetup groups in the local regional meetup groups near near where I live in Virginia. And a lot of them took us up on it. And so it was kind of like me going around talking about like, how I'm crazy. And I like working on this older stuff. And I would ask a question, to set the tone of the room. And one of the question I asked, and I still try to ask it when I give a talk is, who here likes working on a project who they inherited from somebody else. And 5%, maybe 5% of the room would raise their hand. But those people would be like, Oh, waving their hands in the air, that's me. And those people would come up afterwards and be like, as soon as you have an opening, call me. And so it was more noticing that there are people out there who do like working on it. But it's a small minority. And then. So that's when Andre and I came up with the term meander to describe people who like doing this kind of work. So as a contrast to a maker, right? A maker likes to create something that's new, a mender likes to take something that exists and make it better. And so we tried to we tried to build a team of mentors. Awesome. And yeah, there are people who are like, sign me up, I want to work on these problems all the time. And they're out there. And you might even have one at your company right now. One one of our clients. He we talked about, like kind of maker and meander as a continuum. And then also like you, hacker and crafter as another continuum, and you can make a box at any two lines, right? Like you can make four boxes at once. And so he what he started doing on his teams, was he was starting to notice like, what did the project need? Did it need a crafter hacker? I mean, did it? Did it need a craft or mentor? Or did it need a craft or maker? Right? Like he started assessing? Like, what does the project need? And then who's on it? And is there a match? Is there a match between what the project needs and who staffed on it. And he started moving people around as a result. And he unstuck several projects that is his organization just by trying to match people up with what they naturally enjoy doing,

Tim Bourguignon 33:43
which sounds abuse when you put it like this? Right? I Yeah.

Scott Ford 33:47
But I was like that's, it wasn't obvious to me. So he said he done it. Yeah.

Tim Bourguignon 33:52
So when you're facing the problem is probably way less obvious.

Scott Ford 33:55
Right? So yeah, so it's like you, there's probably one of those folks at your company now. And so instead of having to hire us, let them clean things up, right? And match the folks who enjoy doing the work with the work that they enjoy doing.

Tim Bourguignon 34:07
Very wise. Thank you. I know. Indeed. And I can totally relate to this. When I tried to describe for instance, to my to my mom, what programming is like nowadays, it's never the algorithmic it's more like, well, it's a puzzle, basically. Yeah, all the pieces and angles gonna work somehow. You just have to figure out how to put them together. Yeah, that's right. When I look at, well, I got this piece of code from somebody else. I have no idea what it was. I have no idea how it works. Can I do this? Well, that's where I have to say, I don't know. And one of the possible answers is yes. And one of the possible answers is no, but I don't know. And so this becomes a real puzzle. And while building something new, I know it's gonna work. Just I don't know how fast I'm gonna get there. And I hope performance is gonna be but I know I will get there at some point.

Scott Ford 34:57
Yeah, and I take the attitude of Oh, Like, it's always a yes eventually. Like, it's for me, it's not yet like, is it going to work? Not yet. Okay, it will.

Tim Bourguignon 35:11
For sources in time, yeah,

Scott Ford 35:12
yeah. And I think the challenge and frustration that can show up when you're working with a mentor, is they want to keep going. Right? They might not have noticed that it's time to stop, because you're not willing to throw any more money at the problem. Like, yeah, it's probably technically possible, and they're completely capable of figuring it out. But you're not willing to spend more money on it. And that can be tough.

Tim Bourguignon 35:37
So you raise money than the limiting factor? Or is there another metric that you can follow as a mentor to say, Okay, I don't think it's worth it.

Scott Ford 35:47
I think for the mentor, it's tough, I think, but for the person who's managing the mentor, I think it's money, I like to put somebody else in charge have enough, because there's always more that I can be doing to clean things up. There's no end to better that things can always be better. Like, I like making things better, show me something that needs to be cleaned up, and I will clean it up. And I will keep cleaning it up. And I will keep cleaning it up. And I will make it better, and I will make it better. But I need somebody else in charge of enough. Like that's enough where it's good enough, we can move on. Okay. Yeah. How

Tim Bourguignon 36:21
do you make sure with your clients that somebody is really going to do this job? And really interact with you? Yeah, exactly. And really understand what's happening, and really build a relationship with a vendor to really have a discussion and say, Okay, we think it's enough.

Scott Ford 36:38
Yeah, I think it comes down to like, what are you measuring? What is it that you're making better, and you almost always start to hit diminishing returns, like the amount of energy that's going into it relative to what you're getting out of, it starts to skew and kind of plateau. Like it starts out with like, actually, it's more complicated. Usually, with a mundane project. When you start out, you're putting in a lot of energy, and you're seeing nothing, like you put in a lot of it's almost like getting a Jeep unstuck from the mud. Like, I'll use that as a metaphor of like, there are a lot of people pushing and are pushing really hard, but just not going anywhere. But then you get it unstuck. And once you wait, if you stick with it for that long, then you really make a lot of progress. But eventually you run out of gas. And it's kind of noticing that you've run out of gas is the trick so or that you need to put more more gas as needed, or it's time to stop spending money on gas.

Tim Bourguignon 37:30
So you work more with with time boxes, because when you start looking at a project for first time, and somebody says, Well, how long is it going to take that? Well, you have to throw your hands in the air? You don't know exactly, it's a no clue time box. Let's look at that box. Let's see what we can find and then decide if we add another time box after that.

Scott Ford 37:48
Okay, yeah, because so the that first time box if you're if the Jeep still stuck in the mud, it could be time to buy new Jeep. Yeah, so like time boxes become critical. Yeah. And I think that's the challenge is, is knowing like, like, I when I'm doing the work, I'm a really poor judge of whether or not we should stop. And I knew that about myself.

Tim Bourguignon 38:11
Okay, that's already started. I have one eye on the clock. But there's one question that's burning. Yeah. How did you avoid? Or did you avoid getting cornered into one domain, one language one framework, become an expert. unstacking wonderful corner of the industry?

Scott Ford 38:34
Yeah, I had an I had a hypothesis that the challenges that come up are going to be generic enough that similar approaches would work regardless of the languages or frameworks that you're using. And I didn't want I didn't want to bet my career. I've never wanted to bet my career on just one language or one platform. Like I've always wanted to, like be really good, at least two, if not three, like I could always be at a point where I could be comfortable shipping production code in two to three stacks. And I wanted the company to have that same safety. So that if the software community just up and says Ruby sucks, don't use Ruby anymore. And we've built our entire business on Ruby, the word out like Well, great.

Tim Bourguignon 39:30
Okay, did your customer see this way? The experience I have had was for instance, having a problem with DB two database on the host. And so we asked around and we were given the name of one gentleman who was an expert in that and when somebody asked us well, we have problems with a dB to database on the host you know, somebody we just grabbed this guy and and so he became willingly or unwillingly journey wide expert in dB two on the host. Right so If you want to do that, fine, but if you want to avoid it, how do you avoid this, this word of mouth, from going in and taking you in this corner,

Scott Ford 40:08
we try to the to avoid kind of like getting stuck with like those referrals, making sure that we show up and other language communities making sure that we let our clients know that we're willing to tackle any problem. So like, we did have a client who their procurement process was pretty laborious. And so they already had us in the system, we were already on site. And they had some COBOL code that they wanted to, they wanted to rewrite into Java. But none of their Java folks had any interest in learning COBOL, even to read it at all. And so they were like, are y'all willing to learn how to read COBOL code? Like, yeah, why not? That sounds like fun. And they couldn't find anybody within their organization who's even willing to learn how to read COBOL code. And so that became our job on the project is like, and they knew that from the start, they knew that we had never worked with before, were really honest. But we learned and figured it out. And so we will always try to be open and honest about what we do know what we are experts in because we do have a few folks of the company who can claim a claim to be experts in different tech stacks. And we do get word around word of mouth recommendations because of that. But then we also try to show up and speak at speak at conferences where we get exposed to people from other language communities. And we're clear that the things that we're doing, you can do them in any language.

Tim Bourguignon 41:24
I see. I see. So sounds like a good place to be. Yeah. We have a piece of advice for people who are facing the consultants that yet you mentioned saying, Well, you have to write it. And then we say no, there's some cleaning that we can do. What what are the kinds of arguments that you can use in such a situation to build your case? And then maybe get a go at mending instead of recrafting?

Scott Ford 41:52
Yeah, so a big one, I think comes from it's an old blog post by Joel Spolsky. And he talks about how every line of code in your program defends against a bug. So it exists prevent a bug. Whether you know it or not, that line of code is there to prevent a bug. So how confident are you that when you build the replacement, you're going to prevent all the same bugs? Hmm.

Tim Bourguignon 42:24
That is very TDD. Yeah.

Scott Ford 42:27
Yeah. And so like, that's one another is really challenging. Cuz I think for a lot of teams, when they say like, Oh, it'll be easier. If we rewrite it. I would challenge them to say, I think you haven't thought about the problem long enough. Right, like, like the part that you're seeing the part of the percentage of the problem that you're noticing that percentage will be easier to rewrite it. It's the parts that you're not noticing would not be easier to rewrite it. And it's those parts that the system has been built up over the years to solve. Now, it certainly is possible sometimes that a system is just doing more than it needs to because either features were added and never shipped, like so you've got like partially implemented stuff lying about, or users just never adopted things. Like Like imagine, I can imagine in the word desktop application that there are some toolbar buttons that get clicked like, point oh, 1% of the time, right? And so might it make sense just to delete that toolbar button. But as software professionals, we very rarely delete features. Right? So like, if you have something that you think can be removed, right, if that's your justification for doing a rewrite, try just deleting it first. Right? Like, and so like really trying to tease out like, the why behind the motivation to rewrite is the motivation, resume Driven Development I've been, which I've been guilty of that, right. Like, I want to start working in TypeScript. So we're gonna build this in TypeScript. Right, like, so what if it doesn't make sense? Like, let's just go do it? Yeah, right. Is that a motivation? Well, is there and then is there a way to satisfy that desire on the existing codebase? Is there a way to start adding new functionality in TypeScript? Doesn't have to be a doesn't have to be binary? Do you have to start completely over in order to satisfy that desire? Or is there a way to fulfill that on the existing project? Like it doesn't need to be a single language system does it? Like if there's a place that makes sense to plug that language in and start doing it, right? Maybe anytime you have a deployment script or something like that, that you're writing, write it in TypeScript, like, fine, right? Start writing your tests, your automated UI tests, which everybody knows in TypeScript, you'll find a way to start using the technology that you want to use. Another motivation that I've heard for wanting to do a rewrite is that the tooling has gotten too old. So like, it's the All of the tooling is out of date the compilers at a date, the version of whatever that it's running on, whether it be Java or dotnet, or Ruby or Python or PHP or Perl, like whatever the version is, it's seriously a lot of credit. Like, take on the work to upgrade it like, you don't have to, you don't have to just accept that it's on that version forever. And I'll sometimes use like a home improvement analogy. So like, if you own if you own a home, or you live in a place that lets you like, make improvements to where you're living. You don't first ask when was it built, and then go to the store and say, Okay, I'm only allowed to use tools that came out the year this is built. So if I have a house, if I have a house that was built in the, you know, in the 1870s, then oh, no power drill didn't exist. So I gotta hand crank all my screws. No, like, don't do that, like, upgrade your tools. Don't Don't let yourself adopt that pain for for no reason. If it's the tooling, that's frustrating, then find a way to upgrade the tooling.

Tim Bourguignon 46:06
Unless you want to have that pain and you want it

Scott Ford 46:10
yeah, that's, that's fine. That's fine. Yeah,

Tim Bourguignon 46:13
I just have a picture of a Frenchman building a castle in South of France, since probably 20 years, just doing it with the old way. Just because it's fascinating, not for me,

Scott Ford 46:27
there's a poem that you need the you mentioned that I think it's called the builder by Rudyard Kipling, I think it's called the builder. I'll search for it. And we can put in your show notes a little bit. But the gist of the poem is, it's about this guy building a castle. And he comes across this great space to build a castle. And he sees all of these discarded stones.

Scott Ford 46:48
And on each and every stone is a warning that basically says it's impossible to build a castle here.

Scott Ford 46:56
And like, and I think it's much more poetic than that, because it's a poem. But something along the lines of like, after me will come a builder, tell him I to have known as paying, right. And so knowledge meant that whoever reads this message is not going to believe me. But they really should. And so this person is like, I can do better, I can build a castle here. So they get into it, and they get way into it, and then they realize it's not going to work. And so they tear it all down, and they write on all of the stones. That's a message that they found and they move on. And I think it's a neat story that sometimes the pain that was encountered before, like, if the system was that complicated for a reason, like and so I think that sometimes happens in the rewrite as well is, when you first get started, it's like, this is gonna work, this is gonna be so easy. It doesn't need to be nearly as complicated as it was last time. And then you're three years into what you thought would be a six month effort. And you're looking back and you're like, oh, my gosh, the system we built is just as complicated as the one we tried to replace,

Tim Bourguignon 48:02
or worse or worse. Because we started thinking we know what we're talking about. And we didn't. And so yeah,

Scott Ford 48:10
yeah, but like so just that that impulse to rewrite, I think, just get curious about it. Get curious about why it's there. And is there another way to satisfy that pain that you're experiencing, because you've got that impulse to rewrite, because you're frustrated with something, there's pain that you're looking to alleviate, and you think a rewrite is going to do it. But I encourage folks to just really take a second glance and get really curious about whether or not there's another way and might that one be cheaper to at least to rule out. Like at least rule it out, right? Like, you might still arrive at a rewrite, but at least rule out the other possibilities. And I think a rewrite can still be your destination. Right? But getting there gradually is another great strategy. Like let's very gradually rewrite this application and transform it so that every single line of code gets replaced. But let's do it a little bit as we go instead of trying to do it all at once, which is what so many teams end up trying to do.

Tim Bourguignon 49:10
Amen to all that in there. Don't do it again.

Scott Ford 49:15
But probably well.

Tim Bourguignon 49:17
Scott has been fantastic. Thank you very much. If there are some listeners are waving their hands and saying I'm a meander, I'm a meander. I want to narrate the code with zody Arsal. Like like this conference? Where should we send them? We're working to contact you. Yeah, so

Scott Ford 49:30
I would think legacy code rocks, Slack dot legacy hood rocks. And that's slack, the legacy code.in. Join that online community that we've built and follow along in the podcast. We have a we have a weekly virtual meetup, which was virtual before it was cool, because one thing about mentors is they're spread out because they're under there aren't enough mentors in my geographical area, to create a meet up for my geographical area. There just aren't enough of them. So it has to be virtual. So we've got a virtual meetup that meets Wednesday, meets Wednesdays at 1pm. Eastern, which doesn't work out for everybody, especially if you live in Europe. That's like dinnertime, right? So kind of dinnertime or put kids to bed time. So but but yeah, it's a great group. And then we've got a conference that we've done two years in a row now. And we're gearing up to do it for a third year meander con. So, again, virtual conference, because

Tim Bourguignon 50:21
this whole thing going around right now. Yeah, that.

Scott Ford 50:25
And that was one of the motivations for creating it was like, I'd wanted to do a conference forever. And then it wasn't what sitting around watching conferences get cancelled left, right. And so we're like, well, let's do it. Let's do a ritual.

Tim Bourguignon 50:38
Nice that you did. Yeah. Scott. Thank you very much. It's been a blast.

Scott Ford 50:42
Thanks, Tim. I really appreciated being here and being able to share my story.

Tim Bourguignon 50:47
Likewise. And this has been another episode of Deborah's journey. We'll see each other next week. Bye. Thanks a lot for tuning in. I hope you have enjoyed this week's episode. If you liked the show, please share rate and review. It helps more listeners discover those stories. You can find the links to all the platforms to show appears on on our website, Dev journey dot info, slash subscribe. Creating the show every week takes a lot of time, energy, and, of course money. Would you please help me continue bringing out those inspiring stories every week by pledging a small monthly donation, you'll find our patreon link at Dev journey dot info slash donate. And finally, don't hesitate to reach out and tell me how this week story is shaping your future. You can find me on Twitter at @timothep ti m o t h e p or per email info at Dev journey dot info. Talk to you soon.