Guy Reams (00:02.19)
Today is day 156, the life design flaw of overengineering. So I've been thinking a lot about software development cycles lately. And so naturally, I've been making parallels to my own personal life. And so one of the challenges in software development projects is this concept called overengineering.
So, and I think what I hit on today in my thinking was there's a very specific cause of over engineering that I realized when I was much younger. So I remember I had a project where it was a big e -commerce project and the customer was asking for us to speed up development time. So I had a programmer or two on the project.
And he wanted to speed up development time. So, you know, I took project management classes. So I knew that if you wanted to speed something up, you needed to add more resources, right? So I went and hired more programmers. And that would have all been fine and dandy. But what ended up actually happening is the reverse happened. The project slowed down. And there was a very specific reason for that. And that's because our software development was not modular.
there was nothing really for them to work on. There was one large module and two or three ancillary modules. And the one large module is where the bulk of the work had to be performed. And that couldn't be done in a vacuum. All the developers had to work together on it because it was so combined together. There wasn't enough components for a developer to go off and work on one particular component. So they all had to work on the one. And that caused everybody to start
trying to figure out what was going on, what they were working on. And more importantly, they started debating about what the right thing to do was. And then it became a contest to see who could over -engineer the best way to do it. So I knew I was in trouble. And so that's the basic reason why we had a problem, is it wasn't modular enough. So I learned very quickly that if you're going to have a software development project, you've got to break it down into,
Guy Reams (02:27.886)
least common denominator type of projects to work on so you can have multiple people working and not stepping on each other.
But what really caused the overengineering was not necessarily the lack of modularity. It's what they did as reaction to it. So I remember sitting in a code review where one guy brought the code forward to show what was going on. And they had elected to work on a completely separate idea that had nothing to do with our project. It was a great idea. He was basically...
passing the text through an interpreter so that it would provide high contrast visibility to anybody that was disabled and needed high contrast viewing on the screen. So that was a very admirable thing to do, but the customer wasn't paying us to do it. So that was a bad thing, right? And then the second one is the other new developer I hired took it upon themselves to re -engineer how we were parsing text. Now,
text strings. So I had already had a way to do that. I didn't need help with that. But decided to spend hours and hours and hours developing a new way to do that, which was nice, but unnecessary. We would learn later that the things that that person changed ended up really slowing the software down, and we had to remove it completely. So, lack of modularity causes the engineers to overdevelop and overengineer.
And that is exactly the same thing that happens in my personal life. So in my personal life, I have lots of things I'm responsible for and lots of things that I do.
Guy Reams (04:16.462)
I have a tendency to want to put them all together, right? I have a tendency to want to put them all together so I can work on them all at the same time. Or that if I do one thing, it applies to all of them, right? I want my life to be easy to understand. So I'm trying to create an organization structure that allows me to be more effective. But that doesn't work. What I need to do is have my life in modular chunks. And so I've actually learned.
It's actually been helping me by breaking my life down into modules where each module has a very specific goal and aspiration that doesn't interact with the other ones, doesn't need to interact with the other ones. I can go be the nonprofit organization person and I can go be the CEO or I can go be the investor or I can go be the husband or I can go be father.
And I don't have to worry about the other things getting stepped on or getting whatever. And because of that, when I go do the one thing, I don't over engineer it. I get what needs to be done and so that I can move on to the next thing. So by increasing modularity in my life, I reduce the tendency for me to want to over engineer. So I think this is a great thought concept, right? It's like,
building into your mindset that, okay, I'm now shifting to this role and in this role, this is my goal, right? Like, I oftentimes try to do two things at once and that just never works for me and it causes me to get anxious and over -complicate things. So, I believe that this practice to avoid over -engineering through increased modularity is something that applies also to the personal life.
So that's something I've been implementing lately and it's certainly been helpful. Thank you.