I play a form of group chess that has some interesting analogies to software development and maintenance of existing systems. This episode explains group chess and explores a few of those analogies.
Transcript for episode 99 of the Test & Code Podcast
This transcript starts as an auto generated transcript.
PRs welcome if you want to help fix any errors.
00:00:00 On today’s episode of Test and Code, we are going to talk about software maintenance and also chess.
00:00:18 Welcome to Test and Code, a podcast about software development, software testing, and Python, as far as titles go, so software maintenance and chess isn’t bad. I was going to deal with Chess in The Art of Software Maintenance as a nod to Zen and the Art of Motorcycle Maintenance, but I was afraid the reference would be a little bit too obscure, and software maintenance isn’t quite right either. What I’m really talking about is software development and maintenance of existing systems, which is a bit long.
00:00:53 I’m trying to avoid the term legacy software due to the baggage that term has, also because it’s not dead end legacy software, but really projects. You jump into where there’s already a large body of established working code, and it’s not really chess either, but a form of group chess that we play at work.
00:01:12 I’ll start by explaining this alternate chess, and then I’ll talk about how it relates to software development of existing systems. At the office where I work, there’s a break room.
00:01:22 Someone brought in a broken electronic chessboard and pieces and set it up. At first there was a piece of paper with a word white on one side and black on the other, even though the pieces are really light Gray and dark grey.
00:01:36 Then another piece of paper showed up with check on one side and checkmate on the other. The handwritten bits of scrap paper clearly wasn’t satisfying for someone, and they replaced it with printed cards placed inside of clear plastic badge sleeves.
00:01:53 A month or so later, a large wood board with wood pieces also showed up, and another set of cards were made to go with that, and then a third board, this time glass and smaller, with clear and frosted pieces, and another set of cards.
00:02:10 It’s now been these three boards for gosh at least a year or two, maybe four.
00:02:16 It’s been a while.
00:02:18 The cards are there because the games are not played at one sitting. Anyone can play.
00:02:23 The white black card indicates whose move it is, and it usually sits on top of the check bank card, which is brought out to indicate either state.
00:02:33 Some people play at one side consistently.
00:02:36 I personally have a rule for myself that I only make a move if I’m not the last one that played the other side. In other words, I won’t play two moves in a row, one for each side. That seems just wrong to me, but really there’s no rules other than normal chest movement rules.
00:02:55 The game can go on for a long time, but some are rather quick.
00:03:00 Endings are sometimes painfully slow and boring, so often a couple of people will sit and finish the game when there are very few pieces left. I appreciate that openings are also kind of boring, so I try to play frequently during the openings to keep the things rolling, and I think many others do too.
00:03:21 It’s the middle of the game that’s really fun, I think, because it’s a nonobvious puzzle.
00:03:27 You walk up to the board and try to assess quickly what are the threats on both sides, who’s ahead, who’s behind, who has better position, and of course, what’s the next best move.
00:03:39 Then make the move and flip the card and go back to working or finish your sandwich or refuel your kombucha or coffee or whatever.
00:03:47 But things can go wrong. People playing are at all levels and sometimes don’t see threats quickly.
00:03:54 Sometimes the board gets set up wrong, like the bishops and Knights get swapped and no one notices until it’s like ten moves into the game. Sometimes people move and forget to flip the card.
00:04:05 Sometimes someone moves flips the card and has second thoughts and moves the pieces back and forgets to refill up the card. Either way, sometimes one side gets two moves in a row.
00:04:17 Check can happen with someone forgetting to put the check card out, or maybe not even noticing that a check had happened with or without the check card. Sometimes someone will not respond to check and move some other piece, leaving the King in check.
00:04:35 One time I saw this and went ahead and captured the King and flipped the card just to see how long the game would continue without the King.
00:04:42 Even without mistakes, strategy is difficult, and a carefully placed night might get moved back to its previous spot. When you come in and check on the game again, someone might bump a board and the pieces shift. And I started noticing analogies to this wacky way of playing chess to software development and maintenance of existing software systems, which is what I want to talk about next.
00:05:10 This episode of Test and Code is sponsored by Reagan. Save time with crash reporting, detect, diagnose and destroy errors that are affecting your customers. With smart Python error monitoring software from Ray Gun, you can be alerted to issues affecting your users the second they happen, have complete visibility of your app or website so you discover and fix errors and perform issues before your customers experience them. Regan takes you to the exact line of code where the errors occurred and tells you how many times it’s happened and exactly who has been affected by it. All errors are reported to your Reagan dashboard automatically, along with full diagnostic details on how to solve them.
00:05:48 Regan has also fine tuned the filtering notification control so you can focus on fixing important issues and problems affecting most users and not be bombarded with redundant notifications. It takes just minutes to set up. Try it yourself by going to Raygun.com. That’s Raygun.com. Thanks, Raygan, for sponsoring this episode.
00:06:12 And now let’s talk about maintaining and developing an existing software systems. A lot of software development involves jumping into existing systems. There is this idea that I think we give people learning software development that there are really two types of software you work on. First, there’s new stuff that you get to design and invent and use all the shiny new techniques and frameworks, or just use this type of code you’re comfortable with. And second, there’s legacy systems, which are monolithic beasts written in a waterfall era with no tests and dark corners and missing or obsolete specs and a lot of bit shifting operations. And really, this software should just be put out of its misery and written by real coders.
00:06:54 I find this entirely wrong. In my experience, legacy seems like old. There’s a connotation there that I don’t like.
00:07:03 Existing software systems is more accurate. There is a lot of software out there that’s been useful in being sold and making money and supporting companies that needs to have new features added and gets used in new situations and gets ported to new hardware. And whatnot existing software is what pays the salary of developers that are not in startups. Don’t be dissing existing software or legacy systems just because it was written before you got hired. You got hired because the software that software made enough profit to bring on more developers.
00:07:39 Now, of course, there may be problems with the software that become more apparent as it gets modified and puts in new uses. But we’re professionals. That’s where automated tests, suites and careful refractoring techniques come into play.
00:07:54 But let’s have some fun with this anyway. You should be able to laugh at yourself and your own code, and you definitely should extend that to being able to laugh at prior programmers and the state of your system code.
00:08:06 Seriously, finding humor is what we do to keep us sane.
00:08:10 I tried to figure out some order to this chess software analogy, but failed. So in no particular order, here we go.
00:08:19 No obvious strategy. When I walk up to a chess board in mid game, I don’t know what defense or attack strategy the previous players had. I can spend some time understanding the current placement and try to infer a strategy, but it might be wrong and I might not have time to do that.
00:08:39 And I just want to move some pieces to get the game going. If it turns out to be a bad move, odds are no one will know that I made the bad move. Likewise, if I come up with a form of attack strategy, I can only do the four first move. Someone else will probably come after me and not know what I was trying to do.
00:09:00 Remind you of software it does for me. I’ve got to add some functionality to pre existing code. I can’t go back and watch all the discussions and decisions that went into the state of the software. As it is now. I can try to infer the design and strategy, but eventually, hopefully quickly, you’ve got to write some tests, change some code, and move on.
00:09:22 There may be written or illustrated designs or block comments, and hopefully those are always relevant and correct, but they won’t always be. I had a subsystem once that was so confusing and contradictory, and it had contradictory code comments and I couldn’t figure out the design until I ran a script to strip all the comments out of the code so I could just see the code. That experience caused me to think of code comments as future possible lies for a long time.
00:09:53 I now have a better relationship with code comments as long as they comment on the why and not the how.
00:10:02 Next analogy is you didn’t start it and you won’t finish it.
00:10:06 Really, even if you are there at the start of a software project, wouldn’t a feature of successful software be that it will keep on going even after you move on to other things?
00:10:18 The chess games are played by lots of people, even though only one person starts it and only one person ends it. Treat software like it’s going to live on after you. Be proud of it and be proud to pass it on. Fix what you’re not proud of. Make sure tests are in place to ensure future programmers don’t make silly moves just because they didn’t know your strategy. Know when you’re done the few games that were in checkmate that were not noticed or ignored.
00:10:47 Having acceptance tests and acceptance criteria in place while coding will help you know when you’re done misconfiguration.
00:10:55 I’ve come into games, you know ten or twelve moves into the game and notice that one or both of the bishops or Knights were swapped or the initial configuration must have been wrong to get into the state. What do you do then? Do you keep playing anyway? Do you reset the board? I don’t know. We’ve kind of done both things in the past.
00:11:16 Starting a project is important. Put tests in place, early set up and a minimum viable continuous integration workflow when it’s necessary, set up talks, set up, packaging and distribution.
00:11:31 All of this is way easier and faster with not much code in place already.
00:11:36 I’ve seen projects that were almost done, but without full acceptance tests, without packaging, without CI. These are not almost done projects. People just think they are doing all of that extra stuff at the end. It takes a long time. Doing it at the beginning might take a few hours or a day or two extra, but at the end of a multi month project it will cost you weeks, if not months, to put them in place.
00:12:03 Different levels of experience and expertise.
00:12:06 This is inevitable in both software and group chess.
00:12:11 How do we deal with that in software?
00:12:14 There’s a lot of ways keeping it simple. Simple software is easier to maintain, test debug, etc. For have clean, well documented APIs and have automated tests against those. If you don’t like documenting APIs, well, me neither. So don’t have wide APIs only put in functionality that’s absolutely necessary right now, not the we’ll need this function or flag or option later, so I’ll throw it in now. Don’t have dead code. It’s annoying to spend hours debugging or refactoring a function that you later realize is never called by the rest of the system. So delete that code out of there.
00:12:52 Complexity can be necessary. Comment those parts heavily, but not so much to obscure the code and unit, test complex algorithms heavily, or replace complexity with simplicity whenever possible.
00:13:06 Small is good. Don’t obfuscate for the sake of size, but a 20 line method is usually easier to understand and keep bug free than a three page method. If you can’t see all of it on the screen at once, the next developer will have a hard time keeping it all in their head at once.
00:13:26 Mentor each other pair programming can help code reviews debugging other people’s code. I’m sure I missed some, but there are lots of ways to keep things simple.
00:13:38 Forgetting to flip the card in chess for getting to flip the card is just a process error in software. There’s other things that can go wrong. There’s so many examples, actually.
00:13:50 Things like it’s a small change. I’ll just edit it on main and skip the merge request and code review.
00:13:58 Or this test is failing and just weird. Anyway, I’ll just comment it out and come back to do it later.
00:14:05 How about this is kind of ugly. I’ll refactor it later.
00:14:10 This comment is actually wrong. That’s weird. And leaving it there. Don’t leave it, delete it or fix it. Don’t leave confusing comments to confuse the next person.
00:14:23 Another analogy, there’s always someone better than you and worse than you.
00:14:28 In chess, arrogance is annoying and not fun. Same goes for software. Keep learning, keep teaching, be accepting and kind and compassionate to people who make mistakes, and to be kind to yourself and keep learning.
00:14:43 I think there are probably lots of more analogies to this group chess and software thing that I could make, but I think I’ll wrap it up there. Let me know if you think of more, and also let me know if you play this kind of chess. I think it’s a blast.
00:15:01 Thank you to Patreon supporters for continuing to support the show. Join them by going to test and code support. And thank you, Regan, for sponsoring this episode. Take charge of your app and web monitoring with Reagan. Find out more at Raygun.com. That link is also in the show. Notes at testandcode.com 99 I’ve got some amazing interviews and some really great topics lined up for 2020, but I’d also like to cover topics that you’d like to hear about and interview people you’d like to hear from. But I can’t do that unless you tell me. So tell me, or maybe even you’d like to be on the show. That’s awesome. Reach out and tell me what you want to talk about I am at Brian Hawkins on Twitter. The show is at test and code and at test podcast. I couldn’t decide on which one to use so I’ve got both open twice or DM or on either one.
00:15:54 Also there’s a contact form at testing Code.com so let me know that’s all for now. Now go out and test something.