() | () /
/\/| ,_ __ __ _ /\_|_ __ _ _ _ _ ,
/ |/ | / \_/ \_| |_|/ / \| / \_/ |/ |/ | |/ \_ / \_
/(__/ |_/\__/ \__/ \/ |__//(__/|_/\__/ | | |_/|__/ \/
/|
Casey Muratori recently published a video on Youtube, it's a lecture he presented to a University providing a use case for code simplification/optimization. It was quite good at breaking down the thinking process involved in improving the code, and I think it's a valuable watch for any programmer.
Simple Code, High Performance (Youtube)
One subject Casey brings up in this video is on code reuse, and how it is often misdirected. I've read something else on the subject, but that is a distant memory; so I doubt I can dig up a reference without significant effort. This idea of code reuse made a particularly strong impact on me when I transitioned from game dev to web dev back in 2008. I started working at a web shop that used Perl, and with Perl you get CPAN. CPAN is to Perl as Rubygems is to Ruby or npm is to NodeJS. Early on during my employment there I got instilled with this idea that it is better to find a pre-made software package through CPAN than it is to write something from scratch. This idea has continually been reinforced throughout my web development career. I think it's taken hold in game development too; although I don't have direct experience in that respect. The one point of evidence I have for this claim is the relative wealth of middlewares.
List of game Middleware (Wikipedia)
The problem with this is clearly outlined in Casey's lecture: You are paying the cost of doing all the things the external library is concerned about instead of doing the thing you need to do. The typical argument is that you save time on implementation, but I don't think that's typically the case; or at least not to a great enough extent to offset the cost of doing the extraneous things. For any third party library you adopt, you have to contort that library to do things in the way that works for your codebase. If you can do that without much effort, then you still need to learn how to use the APIs in the first place, and then test them to make sure they work how you expect. Sure, you don't have to build them from scratch, but you get that mismatch between the library trying to serve the needs of everyone compared with exactly the thing you need it to do. There are definitely high-quality libraries out there that are the exception rather than the rule here, but with modern high-level interpreted languages and the extremely low barrier to entry in the field, there is a proliferation of low-quality, high-cost libraries that are easy to unintentionally introduce as dependencies into our systems.
Modern Software Development (video clip)
I've only started to see some push back of this in web development relatively recently. Even at that, I think occurrences of dissenting opinion are few and far between.
Published on October 14, 2021