Discover
Dead Code
Dead Code
Author: Jared Norman
Subscribed: 9Played: 151Subscribe
Share
© Jared Norman
Description
The software industry has a short memory. It warps good ideas, quickly obfuscating their context and intent. Dead Code seeks to extract the good ideas from the chaos of modern software development.
Hosted on Acast. See acast.com/privacy for more information.
78 Episodes
Reverse
Jared talks with Kerri Miller, a Staff Engineer at GitLab, about Keela. It's her new open-source tool that finds unused code in Rails apps, and it's named after a UK police dog known for finding buried bodies. It began about three years ago as an attempt to cut GitLab's CI costs. Kerri didn't want a tool that deletes dead code all at once, so Keela uses regex to snapshot the methods it thinks are unused and fails the build when someone adds new dead code. An exclusion file handles false positives. So far the work has removed about 290 methods and saves GitLab around $150,000 a year in CI costs. Kerri has shipped five releases in six weeks, and partials are next on her list.Links:KeelaKerri Miller on GitHubSponsored LogsRubydexTOONLefthookSeattle.rbGitLabDead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
Jared talks with Noah Silvera, a Super Good Software engineer and the show's most frequent guest, about treating requirements as negotiable rather than as literal instructions. Requirements reach engineers through a game of telephone, so she argues you have to go back to the client, understand the reasoning, and lead them toward better decisions they arrive at themselves. Engineers own the outcome and cannot hide behind "that's just what they told me." She makes the case for spikes, formal or informal, on the grounds that understanding an unfamiliar part of the system first is usually cheaper than fixing it later. Which decisions deserve that investment depends on how expensive they are to undo: design is easy to change in production, while data models require migrations and leave permanent gaps in what you collected. When a launch date will not move and Brooks' Law rules out adding people, the only real lever is cutting scope, which requires knowing what the business actually needs at launch. Her advice to newer developers is that working within constraints is the engineering problem, not an obstacle to it.Links:Brooks' LawThe Mythical Man-MonthSpikeSpikes in SAFeExtreme ProgrammingBig Design Up FrontBoehm's cost-of-change curveTechnical debtGetting Empirical about RefactoringChurn vs. Complexity vs. Code CoverageMinimum viable productSchema migrationDead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
Charles Nutter has led JRuby for 20 years and still spends much of his time correcting the assumption that running Ruby on the JVM means writing Java. It doesn't. Rails and Hanami apps come over and run, and what you get underneath is world-class garbage collection, real parallel threads instead of 50 forked processes, the Maven Central ecosystem, and profilers you can attach to a live production server. He tells Jared how a $50 Ruby conference in 2004 pulled him out of Java enterprise work and into a project that had been idle since 2001. They also get into the startup time problem and how much recent JVM work has closed it, the compatibility jump through JRuby 10 and 10.1, invoke dynamic, fibers on virtual threads, and what Panama, Valhalla and Project Babylon could mean for Ruby. Charles now funds the work himself through Headius Enterprises after Red Hat's sponsorship ended.Links:JRubyJRuby on GitHubActiverecord-jdbc-adapterHeadius EnterprisesMaven CentralPrismHanamiTruffleRubyProject LoomProject PanamaProject LilliputProject ValhallaProject BabylonDead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
Host Jared Norman talks with Nik Suresh, who runs Hermit Tech, an extreme programming data consultancy in Melbourne, about why Scrum fails. Nik argues Scrum spread through dishonest marketing (Sutherland's "twice the work in half the time" promise) and that its rituals amplify bad management rather than fix it, from Fibonacci story points that are really just time estimates to one-hour standups he's seen more often than the correct version. His core point is that the map is not the territory: Jira boards and status PowerPoints give executives a simulated cockpit rather than an accurate picture, and he admits he once moved cards to done without doing the work and nobody noticed. He advocates treating any deadline slip as evidence the whole estimate was wrong, paying attention to morale and sick days as the real project signals, and tells engineers stuck in dysfunctional standups to just quit before the environment warps them. His closing lesson is that dropping Scrum alone won't help, since the conditions that produced it will just produce the next silly framework unless teams honestly ask how they came to follow a process on faith.Links:Tossed Salads and Scrumbled EggsPraise The Machine SpiritLudicity (Nik's blog)Hermit Tech (Nik's consultancy)The Agile ManifestoScrum: The Art of Doing Twice the Work in Half the Time by Jeff SutherlandDead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
On this episode of Dead Code, Jared talks with Nithin Bekal, a longtime Ruby developer at Shopify, about Sapphire, his hobby programming language: a gradually typed, object-oriented language inspired by Ruby but stripped of metaprogramming magic, implemented in Rust, with features admitted only if he'd use them in production code. Nithin built much of it with LLM coding agents, even prompting from his phone after his laptop died, and now has 10,000 to 15,000 lines of Rust he doesn't fully understand, so he plans to scale back to asking agents questions rather than letting them drive, a struggle Jared relates to after throwing away his own fully vibe-coded OCaml compiler before hand-building his ML-style language, Shroom. Nithin prioritized tooling early because developer experience is what he most wants to learn, cites the LLM-fueled wave of hobby languages like Matz's Spinel and Steve Klabnik's Rue as motivation, advises aspiring language builders to just dive in since parsing is more approachable than it looks, and plans a docs generator as Sapphire's first real codebase.Links:SapphireSpinelRueNithin BekalCrafting InterpretersSorbetRubyRustDead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.




