Podcasts about software analysis

AI Assisted Coding: Beyond AI Code Assistants: How Moldable Development Answers Questions AI Can't With Tudor Girba In this BONUS episode, we explore Moldable Development with Tudor Girba, CEO of feenk.com and creator of the Glamorous Toolkit. We dive into why developers spend over 50% of their time reading code—not because they want to, but because they lack the answers they need. Tudor shares how building contextual tools can transform software development, making systems truly understandable and enabling decisions at the speed of thought. The Hidden System: A Telco's Three-Year Quest "They had a system consisting of five boxes, but they could only enumerate four. If this is your level of awareness about what is reality around you, you have almost no chance of systematically affecting that reality." Tudor opens with a striking case study from a telecommunications company that spent three years and hundreds of person-years trying to optimize a data pipeline. Despite massive effort and executive mandate, the pipeline still took exactly one day to process data—no improvement whatsoever. When Tudor's team investigated, they asked for an architecture diagram. The team drew four boxes representing their system. But when Tudor's team started building tools to mirror this architecture back from the actual code, they discovered something shocking: there was an entire fifth system between the first and second boxes that nobody knew existed. This missing system was likely the bottleneck they'd been trying to optimize for three years. Why Reading Code Doesn't Scale "Developers spend more than 50% of their time reading code. The problem is that our systems are typically larger than anyone can read, and by the time you finish reading, the system has already changed many times." The real issue isn't the time spent reading—it's that reading is the most manual, least scalable way to extract information from systems. When developers read code, they're actually trying to answer questions so they can make decisions. But a 250,000-line system would take one person-month to read at high speed, and the system changes constantly during that time. This means everything you learned yesterday becomes merely a hypothesis, not a reliable answer. The fundamental problem is that we cannot perceive anything in a software system except through tools, yet we've never made how we read code an explicit, optimizable activity. The Context Problem: Why Generic Tools Fail "Software is highly contextual, which means we can predict classes of problems people will have, but we cannot predict specific problems people will have." Tudor draws a powerful parallel with testing. Nobody downloads unit tests from the web and applies them to their system—that would be absurd. Instead, we download test frameworks and build tests contextually for our specific system, encoding what's valuable about our particular business logic. Yet for almost everything else in software development, we download generic tools and expect them to work. This is why teams have tens of thousands of static analysis warnings they ignore, while a single failing test stops deployment. The test encodes contextual value; the generic warning doesn't. Moldable Development extends this principle: every question about your system should be answered by a contextual tool you build for that specific question. Tools That Mirror Your Mental Model "Whatever you draw on the whiteboard—that's your mental model. But as soon as the system exists, we want the system to mirror you back that thing. We make it the job of the system to show our mental model back to us." When someone draws an architecture diagram on a whiteboard, they're not documenting the system—they're documenting their beliefs about the system. The diagram represents wishes when drawn before the system exists, but beliefs when drawn after. Moldable Development flips this: instead of humans reading code and creating approximations, the system itself generates the visualization directly from the actual code. This eliminates the layers of belief and inference. Whether you're looking at high-level architecture, data lineage across multiple technologies, performance bottlenecks, or business domain structure, you build small tools that extract and present exactly the information you need from the system as it actually is. The Test-Driven Development Parallel "Testing was a way to find some kind of class of answers. But there are many other questions we have, and the question is: is there a systematic way to approach arbitrary questions?" Tudor explains that Moldable Development applies test-driven development principles to all forms of system understanding. Just as we write tests after we understand the functionality we need, we build visualization and analysis tools after we understand the questions we need answered. Both approaches share key characteristics: they're built contextually for the specific system, created by developers during development, and composed of many small tools that collectively model the system. The difference is that TDD focuses on functional decomposition and known expectations, while Moldable Development addresses architecture, security, domain structure, performance, and any other perspective where functional tests aren't the most useful decomposition. From Thousands of Features to Thousands of Tools "In my development environment, I don't have features. I have thousands of tools that coexist. Development environments should be focused not on what exists out of the box, but on how quickly you can create a contextual tool." Traditional development environments offer dozens of features—buttons, plugins, generic views. But Moldable Development environments contain thousands of micro-tools, each answering a specific question about a specific system. The key is making these tools composable and fast to create. Rather than building monolithic tools that try to handle every scenario, you build small inspectors that show one perspective on one object or concept. These inspectors chain together naturally as you drill down from high-level questions to detailed investigations. You might have one inspector showing test failures grouped by exception type, another showing PDF document comparisons, another showing cluster performance, and another showing memory usage—all coexisting and available when needed. The Real Bottleneck To Learning A System: Time to the Next Question "Once you do this, you will see that the interesting bottleneck is in the time to the next interesting question. This is by far the most interesting place to be spending energy." When you commoditize access to answers through contextual tools, something remarkable happens: the bottleneck shifts from getting answers to asking better questions. Right now, because answers come so slowly through manual reading and analysis, we rarely exercise the skill of formulating good questions. We make decisions based on gut feelings and incomplete data because we can't afford to dig deeper. But when answers arrive at the speed of thought, you can explore, follow hunches, test hypotheses, and develop genuine insight. The conversation between person and system becomes fluid, enabling decision-making based on actual evidence rather than belief. Moldable Development in Practice: The Lifeware Case "They are investing in software engineering as their competitive advantage. They have 150,000 tests that would take 10 days to run on a single machine, but they run them in 16 minutes distributed across AWS." Tudor shares a powerful case study of Lifeware, a life insurance software company that was featured in Kent Beck's "Test-Driven Development by Example" in 2002 with 4,000 tests. Today they have 150,000 tests and have fully adopted Moldable Development as their core practice. Their business model is remarkable: they take data from insurance companies, throw away the old systems, and reverse-engineer new systems by TDD-ing the business—replaying history to produce pixel-identical documents. They've deployed Glamorous Toolkit as their sole development environment across 100+ developers. Their approach demonstrates that Moldable Development isn't just a research concept but a practical competitive advantage that scales to large teams and complex systems. Why AI Doesn't Solve This Problem "When you ask AI, you will get exactly the same kind of answers. The answer comes quickly, but you will not know whether this is accurate, whether this represents the whole thing, and you definitely do not have an explanation as to why the answer is the way it is." In the age of AI code assistants, it might seem like language models could solve the problem of understanding systems. But Tudor explains why they can't. When you ask an AI about your architecture, you get an opinion—fast but unverifiable. Just like asking a developer to draw the architecture on a whiteboard, you receive filtered information without knowing if it's complete or accurate. Moldable Development, by contrast, extracts answers deterministically from the actual system. Software systems have almost no ambiguity in meaning—they're mathematical, not linguistic. We don't need probabilistic interpretation of source code; we need precise extraction and presentation. The tools you build give you not just answers but explanations of how those answers were derived from the actual system state. Scaling Through Language, Not Features "You need a new kind of development environment where the goal is to create tools much quicker. You need some sort of language in which to express development environments." The technical challenge of Moldable Development is enabling thousands of tools to coexist productively. This requires a fundamentally different approach to development environments. Instead of adding features—buttons and menu items that quickly become overwhelming—you need a language for expressing tools and a system for composing them. Glamorous Toolkit demonstrates this through its inspector architecture, where any object can define custom views that appear contextually. These views compose naturally as you navigate through your investigation, reusing earlier perspectives while adding new ones. The environment becomes a medium for tool creation, not just a collection of pre-built features. Making the Invisible Visible "We cannot perceive anything in a software system except through a tool. If that's so important, then the ability to control that shape is probably kind of important too." Software has no inherent shape—it's just data. Every perception we have of it comes through some tool that renders it into a form we can reason about. This means tools aren't nice-to-have accessories; they're fundamental to our ability to work with software at all. The text editor showing code is a tool. The debugger showing variables is a tool. But these are generic tools built once and reused everywhere, which means they show generic perspectives. What if we could control the shape of our software as easily as we write it? What if the system could show us exactly the view we need for exactly the question we have? That's the promise of Moldable Development. About Tudor Girba Tudor Girba is CEO of feenk.com and creator of Moldable Development. He leads the team behind Glamorous Toolkit, a novel IDE that helps developers make sense of complex systems. His work focuses on transforming how teams understand, navigate, and modernize legacy software through custom, insightful tools. Tudor and Simon Wardley are writing a book about Moldable Development which you can get at: https://moldabledevelopment.com/, and read more about in this Medium article. You can link with Tudor Girba on LinkedIn.

In this episode of Elixir Wizards, Xiang Ji and Nathan Hessler join hosts Sundi Myint and Owen Bickford to compare actor model implementation in Elixir, Ruby, and Clojure. In Elixir, the actor model is core to how the BEAM VM works, with lightweight processes communicating asynchronously via message passing. GenServers provide a common abstraction for building actors, handling messages, and maintaining internal state. In Ruby, the actor model is represented through Ractors, which currently map to OS threads. They discuss what we can learn by comparing models, understanding tradeoffs between VMs, languages, and concurrency primitives, and how this knowledge can help us choose the best tools for a project. Topics discussed in this episode: Difference between actor model and shared memory concurrency Isolation of actor state and communication via message passing BEAM VM design for high concurrency via lightweight processes GenServers as common abstraction for building stateful actors GenServer callbacks for message handling and state updates Agents as similar process abstraction to GenServers Shared state utilities like ETS for inter-process communication Global Interpreter Lock in older Ruby VMs Ractors as initial actor implementation in Ruby mapping to threads Planned improvements to Ruby concurrency in 3.3 Akka implementation of actor model on JVM using thread scheduling Limitations of shared memory concurrency on JVM Project Loom bringing lightweight processes to JVM Building GenServer behavior in Ruby using metaprogramming CSP model of communication using channels in Clojure Differences between BEAM scheduler and thread-based VMs Comparing Elixir to academic languages like Haskell Remote and theScore are hiring! Links mentioned in this episode: theScore is hiring! https://www.thescore.com/ Remote is also hiring! https://remote.com/ Comparing the Actor Model and CSP with Elixir and Clojure (https://xiangji.me/2023/12/18/comparing-the-actor-model-and-csp-with-elixir-and-clojure/) Blog Post by Xiang Ji Comparing the Actor model & CSP concurrency with Elixir & Clojure (https://www.youtube.com/watch?v=lIQCQKPRNCI) Xiang Ji at ElixirConf EU 2022 Clojure Programming Language https://clojure.org/ Akka https://akka.io/ Go Programming Language https://github.com/golang/go Proto Actor for Golang https://proto.actor/ RabbitMQ Open-Source Message Broker Software  https://github.com/rabbitmq JVM Project Loom https://github.com/openjdk/loom Ractor for Ruby  https://docs.ruby-lang.org/en/master/ractor_md.html Seven Concurrency Models in Seven Weeks: When Threads Unravel (https://pragprog.com/titles/pb7con/seven-concurrency-models-in-seven-weeks/)by Paul Butcher Seven Languages in Seven Weeks (https://pragprog.com/titles/btlang/seven-languages-in-seven-weeks/) by Bruce A. Tate GenServer https://hexdocs.pm/elixir/1.12/GenServer.html ets https://www.erlang.org/doc/man/ets.html Elixir in Action (https://pragprog.com/titles/btlang/seven-languages-in-seven-weeks/) by Saša Jurić Redis https://github.com/redis/redis Designing for Scalability with Erlang/OTP (https://www.oreilly.com/library/view/designing-for-scalability/9781449361556/) by Francesco Cesarini & Steve Vinoski Discord Blog: Using Rust to Scale Elixir for 11 Million Concurrent Users (https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users) Xiang's website https://xiangji.me/ Feeling Good: The New Mood Therapy (https://www.thriftbooks.com/w/feeling-good-the-new-mood-therapy-by-david-d-burns/250046/?resultid=7691fb71-d8f9-4435-a7a3-db3441d2272b#edition=2377541&idiq=3913925) by David D. Burns Special Guests: Nathan Hessler and Xiang Ji.

Bob Zeidman is the Founder of Zeidman Consulting, which provides hardware and software design services, engineering support, and expert witnesses for high-tech litigation. He created the field of software forensics and founded Software Analysis and Forensic Engineering Corporation to develop and sell software forensics tools.   Zeidman joins the show to discuss how he built up his career as a Silicon Valley consultant. He shares tips and tricks on how you can do the same.   Zeidman's cases have included ConnectU v. Facebook, on which the Oscar-winning movie The Social Network is based, and Oracle v. Google, which went up to the U.S. Supreme Court.   He is the inventor of the famous Silicon Valley Napkin on display at the Computer History Museum.   He is also a high-stakes poker player, and his latest tech venture is Good Beat Poker, a new way to play and watch poker online.   His book The Software IP Detective's Handbook is considered the standard textbook for software forensics. His latest novel is the political satire Animal Lab, a modern sequel to George Orwell's classic Animal Farm.     Website:  www.zeidman.biz www.zeidman.net www.zeidmanconsulting.com www.SAFE-corp.com www.GoodBeatPoker.com

Bob Zeidman created the field of software forensics and founded Software Analysis and Forensic Engineering Corporation to develop and sell software forensics tools. He is the founder of  Zeidman Consulting, an engineering consulting company that has worked on over 245 major litigations involving billions of dollars of disputed intellectual property. His cases have included ConnectU...

Steve spent 40+ years at IBM, where he started as a Software Programmer and later became the GTM Product Manager and Product Manager for Strategic Watson Partners. As a former GTM Product Manager at IBM, Steve's goal was to bring order out of chaos. He talks about the changes in the market and in AI from back then compared to now. Steve speaks with host Dwayne Samuels about his roles at IBM and tells us the difference and similarities between being a Software Analysis and a Product Manager.

In this episode of ByteCast, Rashmi Mohan hosts Denae Ford, a Senior Researcher at Microsoft Research in the Software Analysis and Intelligence Team (SAINTes) group and an Affiliate Assistant Professor in the Human Centered Design and Engineering Department at the University of Washington. Her research lies at the intersection of human-computer interaction and software engineering. In her work she identifies and dismantles cognitive and social barriers by designing mechanisms to support software developer participation in online socio-technical ecosystems. Ford is also a recipient of the National GEM Consortium Fellowship, National Science Foundation Graduate Research Fellowship, and Microsoft Research Ph.D. Fellowship. She is best known for her research on just-in-time mentorship as a mode to empower welcoming engagement in collaborative Q&A for online programming communities, including open-source software and work to empower marginalized software developers in online communities. In the interview, Ford relates how an undergraduate research project inspired her to pursue a PhD in computing. She describes her approach in designing various research studies, the process she used to identify challenges and barriers to engagement in communities such as StackOverflow and GitHub, and how she and her collaborators went about building interventions. They also discuss how some of these interventions can be applied by industry. Ford also shares some future directions and developments in computing that most excite her—and the possibilities in making the field more equitable and inclusive.

This week I sat down with my sister's friend Mike Mastro. He heard about my podcast and couldn't wait to be a part of it. We talk about Mike's process through college from first thinking chemistry was a great option to then going into the engineering field. Now he's working in the computer science world and figuring out how to stay productive while working from home. We also discuss some of Mike's hobbies and dreams. He loves staying active by working out, running, and golfing, but he also enjoys taking time to relax and be with friends or even by himself. He's hoping that maybe someday, he'll be floating up there in space looking at all of us. Check out Gabrielle Ooyama's music here: https://www.facebook.com/gabrielleooyamamusic and https://www.instagram.com/gabrielleooyamamusic/?hl=en&fbclid=IwAR3usGKn5XzYW7YEA3OCe_oW_7lM7Yot6JJ0_6qK7GRlLX6S-3gqzSTGLDc I love hearing from you all, so follow me on any of the following social media pages and send me a message. If you're interested in being on a future episode, I'd love to talk with you! Twitter: https://twitter.com/ExpeditionTry Instagram: https://www.instagram.com/expeditiontotry/ Facebook: https://www.facebook.com/expeditiontotry/ Blog: http://expeditiontotry.com/ --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app

FACEBOOK, GOOGLE, TWITTER AND OTHER TECH COMPANIES WILL APPEAR BEFORE SENATE INTELLIGENCE COMMITTEE THIS WEDNESDAY https://www.wsj.com/articles/lawmakers-are-set-to-start-tech-industry-hearings-1535999249 Lawmakers Are Set to Start Tech Industry Hearings Executives from Facebook, Twitter and Google are likely to face questions about political content, antitrust concerns and consumer privacy at hearings that begin Wednesday. This week, lawmakers will start a series of hearings delving into many of those concerns. The hearings will likely highlight the industry’s political troubles, and point to practices that might be addressed in legislation or executive action in the months and years ahead. Wednesday’s hearings before the Senate Intelligence Committee are expected to include Facebook Inc. COO Sheryl Sandberg, Twitter Inc.CEO Jack Dorsey and a representative of Google, as yet unconfirmed. Later in the day, the House Commerce Committee will examine Mr. Dorsey, whose platform has been a focus of many Republicans’ ire.–The Wall Street Journal Silicon Valley Tech Expert, Bob Zeidman, author: Good Intentions About Bob Zeidman Bob Zeidman is the president and founder of Software Analysis and Forensic Engineering Corporation, the leading provider of software intellectual property analysis tools. Bob created the field of Software Forensics, having invented the CodeSuite® program for detecting software IP theft and measuring software IP growth. Bob is also the president and founder of Zeidman Consulting, a premier contract research and development firm in Silicon Valley that now focuses on consulting to law firms regarding intellectual property disputes. His work has informed court rulings in high-profile court cases including ConnectU v. Facebook, made famous in the Academy Award-winning movie, “The Social Network,” and the landmark software copyright case of Oracle v. Google. Bob has worked on and testified in over 200 cases involving billions of dollars in disputed intellectual property. Bob holds 22 patents and earned two bachelor's degrees, in physics and electrical engineering, from Cornell University and a master's degree in electrical engineering from Stanford University. Bob has written five engineering books including The Software IP Detective’s Handbook and Just Enough Electronics to Impress Your Friends and Colleagues! in addition to numerous articles and papers. He has also written three award-winning screenplays and three award-winning no

https://variety.com/2018/digital/news/infowars-tweets-deleted-policy-violations-1202901574/ Infowars apparently scrambled Thursday to avoid getting kicked off Twitter — the only big digital platform that hasn’t yet booted the hate-mongering media outfit — by deleting old posts that violated the social-media company’s terms of service. Twitter chief Jack Dorsey defended the company’s decision on Tuesday to not suspend Infowars and its founder, Alex Jones, from the platform after YouTube, Facebook, Apple, Spotify and others took action to delete or block the far-right conspiracy theory site’s accounts or content. Dorsey, in a series of tweets, claimed Infowars had not violated Twitter’s policies. However, in a report Thursday, CNN cited about 20 past tweets from the accounts of Infowars and Jones that, by all appearances, did indeed contravene Twitter’s prohibitions against hateful conduct and harassment.–Variety Tech Expert, Bob Zeidman About Bob Zeidman Bob Zeidman is the president and founder of Software Analysis and Forensic Engineering Corporation, the leading provider of software intellectual property analysis tools. Bob created the field of Software Forensics, having invented the CodeSuite® program for detecting software IP theft and measuring software IP growth. Bob is also the president and founder of Zeidman Consulting, a premier contract research and development firm in Silicon Valley that now focuses on consulting to law firms regarding intellectual property disputes. His work has informed court rulings in high-profile court cases including ConnectU v. Facebook, made famous in the Academy Award-winning movie, “The Social Network,” and the landmark software copyright case of Oracle v. Google. Bob has worked on and testified in over 200 cases involving billions of dollars in disputed intellectual property. Bob holds 22 patents and earned two bachelor's degrees, in physics and electrical engineering, from Cornell University and a master's degree in electrical engineering from Stanford University. Bob has written five engineering books including The Software IP Detective’s Handbook and Just Enough Electronics to Impress Your Friends and Colleagues! in addition to numerous articles and papers. He has also written three award-winning screenplays and three award-winning novels including his latest, Good Intentions, a political satire about a future dystopia. Bob is an advisor and board member for several startups and several nonprofit organiz

911 – no matter what you say about that day it is too much, yet not enough. The feelings of helplessness, anger and disbelief changed our country. We are going to reveal the tragedy of senseless government regulations that caused hundreds to die torturous deaths in the aftermath:  The insane use of regulations in the face of a disaster prevented victims from getting help. If there are any survivors or interested parties left, please join us as we demonstrate our 911 software template that we still offer to any 911 support group who want to help.

Paul Klint is hoofd van de onderzoeksafdeling Software Engineering aan het Centrum voor Wiskunde en Informatica en leider van de onderzoeksgroep Software Analysis and Transformation. Hij is hoogleraar aan de Universiteit van Amsterdam en opleidingsdirecteur van de Master Software Engineering. Je kunt Paul op Twitter volgen via @paulkint. In deze aflevering praten we met Paul over de complexiteit van het onderzoek in het software vakgebied, de twee gezichten van het vak (software engineering en computer science) en de weg naar volwassen wetenschappelijk software engineering onderzoek. We discussiëren met Paul over de overdracht en afstand tussen de wetenschap en de praktijk en stippen een van zijn belangrijkste kennisgebieden aan: geautomatiseerde programmatransformaties. Als laatste geeft Paul zijn visie op certificering in ons vakgebied. Het interview is deze keer opgenomen door Arne Timmerman met Michel Rijnders als sidekick. Je kunt deze software craftsman en liefhebber van functioneel en dynamisch programmeren volgen op Twitter via @mrijn. In 1982 is Paul gepromoveerd op een onderzoek naar zogenaamde stringmanipulatietalen, programmeertalen die kunnen worden gebruikt bij het ontwikkelen van tekstverwerkers: From Spring to Summer. Als aanvulling op de voortdurende discussie die gaat over de twee gezichten van het software vakgebied, een bekend artikel van Steve McConnell: Software Engineering, Not Computer Science. Informatie over het onderzoek van de onderzoeksgroep van Paul vind je op de website van het Centrum voor Wiskunde en Informatica. Het bekende concurrency framework dat Paul noemt is Hadoop, gebaseerd op het MapReduce programmeermodel van Google. De Software Improvement Group is een van de belangrijkste spin-offs uit de onderzoeksgroep van Paul. Het belangrijkste project waar de onderzoeksgroep van Paul op dit moment aan werkt is de domein-specifieke taal Rascal. In deze presentatie wordt de 'software vulkaan' uitgelegd. Abonnees van de Automatiseringsgids kunnen een artikel van Paul uit 1999 online teruglezen. Snowbol, de moedertaal die Paul heeft gevormd. Twee boeken waar in de Podcast over wordt gesproken: The Inmates Are Running the Asylum van Alan Cooper en The Design of Everyday Things van Donald Norman. This podcast is in Dutch - Deze podcast is in het Nederlands My Podcast Alley feed! {pca-92dab0518ba527971101e35638ac61f8}