Software design is connected to human relationships within a development team, as poor relationships can lead to unhealthy software.
Incremental structural and behavioral changes disguised as feature or design work can lead to steady progress and continuous internal improvements.
Tidying up code by adjusting names can reduce coupling and reveal similarities, with structural changes being reversible but behavioral changes requiring careful consideration.
Type one decisions involve reversible choices, while type two decisions have irreversible impacts, emphasizing the need for caution and thorough testing. (Time 0:00:00)
Exploring the Connection Between Software Design and Human Relationships
Summary:
Software design is closely intertwined with human relationships.
Poor human relationships within a development team can lead to unhealthy software. Refactorings that require a significant amount of time can strain relationships and damage trust.
The key to successful software development lies in making structural and behavioral changes incrementally, disguising them as feature or design work.
This approach maintains the appearance of steady progress while ensuring continuous improvements internally.
Transcript:
Speaker 2
And now maybe a bit of a, you may see that as a provocative question. If you like, why not use big refactoring since then?
Speaker 1
Well, the first line I wrote in this book was software design is in exercising human relationships. What I wrote that and I thought, that doesn't make any sense. It's, you know, about coupling and cohesion, all about power laws. But the more I thought about it, the more I realized, if the human relationships that affect software development aren't healthy, the software is not going to be healthy. And what's fundamentally wrong with these cause refactorings, I don't have a good name for these, but I'll work on it. These, you know, where you say, Oh, we need a month to get this cleaned up. Is the effect that it has on the human relationships? That might be the most efficient way to do the to make the changes that you want to make. But if your users or your managers or your product people say, Oh, those programmers, that, you know, we, they can't be trusted. They just, you know, go away for a month. They say they're working really hard. But when they come back, the system does exactly the best case scenario with the system does exactly what it did before. Why did I wait a month for that? I could have had a bunch of features. And that damages the relationship. So part of the skill of empirical software design is this being able to make, you can't, if you're on radio, you can't see me lacing my fingers together. But to make the structure changes and the behavior changes in small enough steps so that from the outside, it looks like you're just working on features or you're just working on design. But inside, you know, you're going back and forth and back and forth and back and forth.
Speaker 2
Yeah. (Time 0:22:42)
Exploring Reversible and Irreversible Changes in Code and the Importance of Tidying Up
Summary:
Tidying up code by adjusting names can reveal similarities, leading to a reduction in coupling.
Structural changes are usually reversible, like renaming variables, but behavioral changes, which have irreversible effects in the outside world, require careful consideration. Type one decisions, advocated by Jeff Bezos, involve reversible choices, while type two decisions have irreversible impacts.
Reversible changes, like extracting helper functions or inlining functions, can be made quickly.
The reversible nature of structural changes allows for easy undoing if needed, unlike behavioral changes that affect users or other systems, emphasizing the need for caution and thorough testing.
Transcript:
Speaker 2
But also I guess there could be the case also sometimes some tidings that let you see things that you are not seeing before. I don't know. Something you extract the helper or?
Speaker 1
Yeah, 100%. You change some names and now you realize, oh, this code here is exactly like that code there. I couldn't see the similarity because the names were gratuitously different. And then I fix that. Now I see, oh, that's really doing exactly the same thing. And now I can unify the two and I can reduce coupling.
Speaker 2
Yeah, another thing that I find interesting is this difference between the structural and behavioral changes the reversibility aspect. So you say that the structural changes are generally reversible. I mean, most of the time, maybe depending on the side, but behavioral ones are often not reversible. So can you give us some examples? Sure.
Speaker 1
Jeff Bezos talks about the type one and type two decisions. It's the same concept. And when you need to make a decision, one thing to notice is whether you can undo that decision easily. If you can undo a decision easily, you don't have to carefully analyze should I do this. You know, people spend more time analyzing the potential effects of a decision than they will actually making the decision. If it's reversible, that makes no sense. Just do it. So I think that these four lines would make a good helper function. Just extract it. Just see. And if you have proper tooling that's going to be a snap, it'll have zero chance of breaking anything. Just do it because if you don't like it, you can undo it. You inline the function. Because of course, your ID has really good refactoring support. Some do and some don't. And so those changes are easily reversible. So they don't need to be carefully analyzed and thought through before you execute them. Behavior changes on the other hand, have effects in the outside world. You make it so new users can't sign up or you report the wrong numbers to the tax authority or you make payouts incorrectly or you ship things to the wrong address. All those are effects in the world that aren't easily reversible. And so you should take extra care when making those irreversible decisions. The mistake people make is they think, well, you know, we the structures like this and we'd like it like that. And so we're going to sit and think really carefully about whether we should do that. No, start moving the structure from how it is to how you think it should be. If you discover that's the wrong direction, you can easily reverse it. So don't treat those decisions the same way that you treat the decisions that have irreversible effects in the outside world where you want unit tests and functional tests and you want To double check with the users and you want to roll it out a little bit at a time and all that stuff. That's all to prevent irreversible effects. (Time 0:28:06)
