A prototype is a a preliminary model of something, from which other forms are developed or copied. This episode is about growing better designed software with the help of a prototype mindset.
Transcript for episode 172 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 A prototype is a preliminary model of something from which other forms are developed or copied in software, we think of prototypes as early things or an MVP application or proof of concept, but we don’t often think of prototyping during daily software development or maintenance. But I think we should. That’s what this episode is about, about growing better design software with the help of a prototype mindset thank you to PyCharm for sponsoring this episode.
00:00:28 Pycharm helps me to understand and play with my code. The refactoring tools are amazing. A simple one is just to rename a method, and it just gets renamed everywhere. There’s a whole bunch of other cool refactoring tools as well. If I changed a bunch of code, I can visually see the diff of my code and the get repo code, and I can even visually walk through the local history to see all of my changes. I actually love refactoring, and PyCharm helps me have fun while I’m doing it. Try PyCharm Pro for four months by going to testandcode.com PyCharm.
00:01:16 Welcome to Test and Code.
00:01:26 I enjoy writing both words and code. When writing a blog post or an essay or a book chapter, there will be more than one draft. I’ve often tried to convince software developers to treat new code as a rough draft, to expect to edit, reorganize, change a lot, and maybe even scrap it and start over. It also helps to have a rough outline before you start. That analogy works for me, but for people who don’t write essays or blog posts or documentation on a regular basis, this analogy might not help at all. So enter the prototype. I read a great article recently by Brett Cannon, which I’ll link to in the Notes. It’s called selecting a programming language can be a form of premature optimization.
00:02:11 In it, he encourages people to treat language selection as a form of premature optimization. We know it’s bad to optimize too early, and that includes the language. So he has these steps. First, prototype in Python. Second, optimize your data structures and algorithms. Third, try another Python implementation that doesn’t require many code changes. Fourth, use Python’s language bindings to optimize using another language. It’s a good article, but a bit of a tangent from where I’m trying to head in this episode. But the first few steps sounded a lot like how I treat new software as a first draft or a prototype. Let’s go back to the definition of prototype. A prototype is a preliminary model of something from which other forms are developed or copied. This works for applications, of course, but it also works for smaller bits like new functions, classes, modules, APIs, or even test functions. If we’re writing a prototype, we are writing something that is intended to be a model to copy from. We are trying to see if we can get the thing to work, but we don’t want to obfuscate the code because we want to be able to copy from it later. It’s okay if there’s big functions, if that’s what makes sense. It’s okay to duplicate some code or to duplicate something else.
00:03:31 However, of course, don’t avoid design principles or modularity, but don’t put extra functions in just because you think it’s going to be reused later or whatever. And with test code, don’t start with tons of parameterized test cases right away. This is a prototype, even if you’re pretty sure that you will have things parameterized. Start with one test case, a prototype test case. When we see it working, then we can go back and optimize the structure to pull off fixtures, if that makes sense, to move things into classes and modules and whatever. But we want to treat it lightly and even be okay with throwing it all away and starting over. The throwing away and starting over part is hard the first time and the second time, but it’s also liberating, and it’s super easy to do with source control. You don’t even have to actually throw it away. Just check in your progress on a branch and start a new branch from the main line and try it again. Try this with something small if that seems scary to you, until you prove to yourself that rewriting something a second time right after you’ve done it the first time with the first draft or the first prototype is super fast and way cleaner than the first one, and prototypes are not meant to be shipped. They’re meant to be. For learning, treat your initial writing of a function, class, or module as a learning experience. As a prototype, you’ll end up writing simpler code as well. And because of that, it actually might be fine as is and not need editing, at least right away. That brings me to maintenance.
00:05:07 When we work on some code to add a feature or fix a bug code that we wrote a long time ago or someone else wrote, we’re changing the code. Since we’re changing the code, then the design and structure of the code obviously isn’t perfect. If it was, why are you there? So maybe treat this part of the code as the prototype that just never got updated. If you need to restructure things to make it easier to read for future maintenance, why not? We’re just building the real thing from the existing prototype, right? Or writing the next draft. Whatever analogy works for you. Aim for simple, aim for easy to read, easy to use as an example for the next version the next time it needs to be rewritten. After all, you have your test suites to let you know if you’ve kept the behavior working right, and you could always revert the code or delete your branch. And even if you do that, even if by trying to make it better, you didn’t get to where you want it to be and it’s worse, you’ve learned more about the code. It wasn’t wasted effort if you know your code base better, that’s always a good thing.
00:06:22 Thank you, PyCharm for sponsoring this episode visit testandcode.com PyCharm for a four month free trial of PyCharm save time. Use PyCharm. Thank you Patreon supporters join them at testandcode.com support those links as well as a link to Brett’s article are in the show notes at testingcom that’s all for now. Now go out and prototype something.