Software Engineering Radio - The Podcast for Professional Software Developers: Recent Episodes
SE-Radio Team
Software Engineering Radio is a podcast targeted at the professional software developer. The goal is to be a lasting educational resource, not a newscast. Every 10 days, a new episode is published that covers all topics software engineering. Episodes are either tutorials on a specific topic, or an interview with a well-known character from the software engineering world. All SE Radio episodes are original content — we do not record conferences or talks given in other venues. Each episode comprises two speakers to ensure a lively listening experience. SE Radio is an independent and non-commercial organization. All content is licensed under the Creative Commons 2.5 license.
Jason Gorman, a software development expert and founder of Codemanship, joins host Giovanni Asproni to explore how best to use AI in software development. They start by considering how established technical practices — test-driven development, modularization, continuous integration, and continuous reviews — become more important, not less, when working with AI assistance. These practices help address several key limitations of LLMs, including keeping context windows as small as possible.
Looking at AI’s impact on team productivity, Jason offers some practical advice for teams to introduce AI tools into their workflows.
The episode also explores spec-driven development, agentic programming, and the importance of writing readable, understandable code — even when it’s AI-generated. Finally, Jason and Giovanni look at emerging research into the cognitive downsides of over-reliance on AI, and what developers can do about it.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show NotesRelated Episodes* SE Radio 711: Scott Hanselman on AI-Assisted Development Tools * SE Radio 710: Marc Brooker on Spec-Driven AI Dev * SE Radio 705: Murat Erder and Eoin Woods on Continuous Architecture * SE Radio 633: Itamar Friedman on Automated Testing with Generative AI * SE Radio 615: Kent Beck on “Tidy First?”
Related Resources* The AI-Ready Software Developer – Index * CRESS Principles for Context Engineering * Book: Process Over Magic: Beyond Vibe Coding by Uberto Barbini * What Is Agentic Coding? * Specification-Driven Development (SDD) * Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl * Ralph Loops * Kent Beck Canon Test Driven Development * Book: “Test-Driven Development: By Example”, Kent Beck * Modularity * Gas Town * Dora Metrics * Article: Super-intelligence or Superstition? Exploring Psychological Factors Influencing Belief in AI Predictions about Personal Behavior * Stack Overflow * Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task * AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking * How Does Naming Affect LLMs on Code Analysis Tasks?
Jason Gorman, a software development expert and founder of Codemanship, joins host Giovanni Asproni to explore how best to use AI in software development. They start by considering how established technical practices — test-driven development, modularization, continuous integration, and continuous reviews — become more important, not less, when working with AI assistance. These practices help address several key limitations of LLMs, including keeping context windows as small as possible.
Looking at AI's impact on team productivity, Jason offers some practical advice for teams to introduce AI tools into their workflows.
The episode also explores spec-driven development, agentic programming, and the importance of writing readable, understandable code — even when it's AI-generated. Finally, Jason and Giovanni look at emerging research into the cognitive downsides of over-reliance on AI, and what developers can do about it.
Sonali Varde, Senior Software Engineering Manager at LinkedIn, joins host Kanchan Shringi to discuss how AI is changing the role of the engineering manager. They explore how AI is showing up in day-to-day management work, including operational reviews, planning, communication, workflow automation, and preparation for leadership discussions.
The conversation looks at how engineering teams are adopting AI tools and agents, what kinds of skills and practices are becoming more important, and how managers can think about context, review, testing, and operational rigor as AI-assisted development becomes more common. They also discuss how AI affects coaching, performance conversations, hiring, onboarding, team composition, and collaboration with peers and leadership. The episode considers both the opportunities and limits of AI for engineering management, with attention to human judgment, curiosity, ownership, and the continuing importance of technical and organizational understanding.
Birgitta Boeckeler, a Distinguished Engineer and consultant focused on AI-assisted software delivery at Thoughtworks, joins host Priyanka Raghavan for a deep dive into harnesses for AI agents.
The episode begins by unpacking the concept of harnesses and harness engineering before exploring the core building blocks — guides and sensors — that help AI agents operate more reliably in engineering environments.
Priyanka and Birgitta discuss practical implementations of harnesses in real-world workflows, including the use of guides with .MD files and sensors with tools such as SonarQube and Semgrep, which steer agent behavior. The episode also explores how harnesses integrate with existing CI/CD pipelines and pull-request processes. Birgitta describes how stronger harnesses can improve trust in AI-generated code, while emphasizing that harnesses themselves require continuous maintenance as underlying foundation models evolve. The episode concludes with a thoughtful discussion on accountability between humans and agents, along with future directions for harness engineering and AI-assisted software development.
Garth Mollet, Senior Principal Product Security Engineer and Technical Advisor for Product Security at Red Hat, joins host Robert Blumen for a discussion of AI supply chain security. They start with the basics of supply chain security, including the key components of the AI supply chain, and how it differs from the conventional software supply chain. Garth discusses whether the attacks target model weights or inference, and describes the most common attacks and what's in it for the attacker, whether exfiltration, credentials, sabotage, or resources. The episode also considers SPIFFE, SPIRE, attestation, workload identity, and whether AI has the equivalent of "reproducible builds."
Brought to you by IEEE Computer Society and IEEE Software magazine.
Clare Liguori, a Senior Principal Engineer who works on developer tooling and agentic AI at Amazon Web Services, speaks with host Sri Panyam about the Amazon Strands Agents SDK. This episode explores the philosophy, design decisions, and emerging patterns behind building production-grade AI agents.
Clare frames any agent as three core components: a model, a set of tools, and a prompt. During this interview, she describes the origin story of Strands, the model-driven approach vs. workflows and custom orchestration, steering hooks, tools and MCP, sub-agents and multi-agents, memory layers, production readiness, testing and evaluation starting with use cases where trajectories can be evaluated deterministically, and anti-patterns for newcomers. She describes what's next for Strands, and offers some closing advice for getting results from working with agents
Jeroen Janssens, a senior developer relations engineer at Posit, and Thijs Nieuwdorp, a developer relations engineer at Polars, speak with host Gregory M. Kapfhammer about Polars, a Python package for transforming, analyzing, and visualizing data. After discussing the key features, they explore the implementation and use of the expressions data type provided by Polars. Along with comparing Polars to other data-manipulation packages like Pandas, they also share best practices for performing data analysis in Python with Polars. Jeroen, Thijs, and Gregory also discuss topics such as how to interface Polars with a SQL database.
Scott Kingsley, a VP of Engineering at SmartBear, speaks with host Gregory Kapfhammer about the Swagger ecosystem. They discuss the user interface, editor, and Swagger CodeGen and how these tools support the creation and documentation of OpenAPI-compatible APIs. Scott describes how Swagger fits into frameworks like FastAPI, as well as how Swagger APIs can be exposed through the Model Context Protocol (MCP). The discussion closes with best practices for designing and testing APIs and the role that APIs play in a landscape in which AI agents are building and interacting with APIs.
Danny Yang and Sam Goldman, both Software Engineers at Meta, speak with host Gregory M. Kapfhammer about the Rust-based Pyrefly type checker for Python. After a look at the foundational concepts for annotating and checking types for Python programs, Danny and Sam present a deep dive of the implementation of Pyrefly. While comparing and contrasting against various type checkers, they also describe how Pyrefly implements the language server protocol (LSP) for Python. The episode explores a range of other topics, including how to balance the features, performance, and language integrations of a type checker.
Jure Leskovec, Professor of Computer Science at Stanford University and Chief Scientist at Kumo.ai, speaks with host Sriram Panyam about relational and graph language models and their transformative impact on enterprise decision-making and predictive modeling.
Jure begins by establishing the critical importance of predictive modeling across industries - from fraud detection in financial institutions to customer churn prediction, lifetime value estimation, product recommendations, and healthcare risk assessment. He notes that while AI has made remarkable advances in natural language understanding and computer vision, predictive modeling over enterprise operational data stored in relational databases has been largely left behind, still relying on 30-year-old machine learning approaches that are expensive, time-consuming, and require manual feature engineering.
His proposed solution to the fundamental problem with current approaches is relational deep learning and relational transformers. The discussion explores how this approach differs from traditional graph neural networks (GNNs), which Jure pioneered and deployed successfully at Pinterest. Jure concludes with practical guidance for software engineers and data scientists interested in exploring this technology.
Dave Airlie, a Distinguished Engineer at Red Hat, speaks with host Gregory M. Kapfhammer about Linux kernel maintenance. After over-viewing the scale and structure of the Linux kernel, they dive deep into the review and validation of kernel patches, drawing on examples from the GPU subsystem. After discussing the features and benefits of the Linux kernel's maintenance model, they also explore kernel maintenance best practices and the supporting tools for these practices. Dave and Gregory also discuss topics such as the integration of Rust code in the Linux kernel and the ways in which AI-driven code review are influencing kernel maintenance.
Dwayne McDaniel, developer advocate at GitGuardian.com, joins host Priyanka Raghavan to talk about the engineering challenges of secrets management. They explore what "secrets" really are in modern systems—far beyond passwords—including API keys, tokens, certificates, and machine identities, and how "secret sprawl" emerges across the SDLC. Drawing on reports from GitGuardian and Verizon, they discuss the growing scale of secret leaks and why credential abuse and phishing remain dominant attack vectors. They examine common leak points—from code repos and logs to CI/CD pipelines, containers, and SaaS integrations—and how cloud, DevOps, and AI tooling are amplifying risks. Priyanka quizzes Dwayne about recent supply chain attacks from pyPi and trivy ecosystems, highlighting recurring root causes like poor access control, long-lived credentials, and weak security hygiene. Finally, they consider detection, response, and modern solutions—short-lived credentials, secret scanning, and identity-based approaches like OWASP NHIR and SPIFFE/SPIRE—ending with practical advice for engineers to reduce blast radius and design for secure secret lifecycle management.
In this episode, Rob Moffat, author of Risk-First Software Development and chief technical architect at the FinTech Open Source Software Foundation (FINOS), speaks with host Brijesh Ammanath about how all of software development is actually risk management. Rob introduces the concept of 'risk-first software development,' which sits in the context of existing methodologies like scrum and kanban. Showcasing multiple real-world project patterns to illustrate how things can go wrong when risk is ignored, he makes the case for why risk should be the primary lens behind every development decision, from architecture to prioritization. Through various examples, he shows how every developer action can be viewed as a risk trade-off and why making that explicit can lead to better outcomes. The conversation takes a deep dive into the risk-first framework and how teams can apply it in their existing processes.
Martin Dilger, founder and CEO of Nebuilt GmbH, speaks with host Giovanni Asproni about event sourcing -- a software architecture pattern in which, rather than storing just the current state of your data, you store a sequence of events that represents every change that has ever happened in the system. This episode starts by introducing the vocabulary around event sourcing, highlighting its relationship with event modeling, event streaming, and event storming. Martin describes some of the pros and cons of the approach, including which systems it is most suitable for. The conversation ends with guidance how to get started with event sourcing, for both greenfield and legacy systems.
Birol Yildiz, CEO and co-founder of iLert, joins host Kanchan Shringi to explore how iLert built an AI SRE — an autonomous agent for handling production incidents — and what the experience revealed about building AI agents in the real world. Birol explains why incident response is a fundamentally agentic problem, where the unpredictability of novel incidents makes rule-based runbooks insufficient and reasoning models essential. He describes how the AI SRE evolved from an early browser-based approach to its current architecture, built around two key ingredients: reasoning models and the Model Context Protocol.
The conversation examines the four layers of the AI SRE in depth: an orchestration layer that routes requests and abstracts model providers; a knowledge layer built on plain text memory and agentic search rather than vector databases; an evaluation framework based on recorded live investigations replayed against new model versions; and a human-in-the-loop constraint layer. The episode concludes with practical advice for teams building agents: own your context completely, avoid off-the-shelf frameworks that obscure what enters the model, and get out of the way of the reasoning model rather than over-prescribing its steps.
Will Sentance, educator and co-founder of Codesmith, joins SE Radio's Adi Narayan to discuss the evolution of JavaScript and modern best practices. They begin with JavaScript's origins as a simple scripting language and its growth into the backbone of modern web development, highlighting the core theme of the "don't break the web" constraint. The requirement that JavaScript must remain backward-compatible has shaped everything from naming decisions (e.g., flat instead of flatten) to the introduction of Symbols as a collision-safe way to extend objects.
Will explains how the TC39 group uses the open-source community as a filtration system, absorbing user land patterns (like those from Lodash or Moment) into the standard library only once demand is proven. The upcoming Temporal API is highlighted as a major win for native date/time handling. On the engine side, Will discusses the shift toward monomorphic object shapes in the V8 JavaScript engine for better just-in-time (JIT) compiler performance, and how developers can now write more engine-aware code. The conversation also touches on LLMs in coding: Will's view is that AI tools are useful but risk atrophying developers' under-the-hood understanding, which remains essential for debugging complex, production-scale systems.
In this episode, host Amey Ambade sits with Eric Tschetter, co-founder of Apache Druid and Chief Architect at Imply, to dissect the critical move toward Decoupling Observability. To begin, they define three pillars—logs, metrics, and traces—and consider why the rise of microservices has made traditional, tightly coupled stacks a major source of pain. Such coupled systems can lead to issues such as vendor lock-in, prohibitive scaling costs, and operational complexity.
Drawing parallels to the Business Intelligence world's separation, Tschetter presents an architectural solution with four distinct layers: Ingest/Route, Data Storage, Query/Compute, and Visualization. This framework aims to provide flexibility to combat the limitations of monolithic observability tools. The conversation moves into the practical challenges and significant benefits of this decoupled model, focusing heavily on data portability and the role of technologies such as OpenTelemetry in standardizing schemas so that data can flow freely between multiple back-ends. A significant portion of the discussion is dedicated to the Query/Compute layer, specifically how Apache Druid addresses the unique demands of real-time analytics on observability data, including indexing strategies and unifying results across hot and cold storage. They also delve into operational survival, covering critical topics like smart sampling to preserve high-value signals, best practices for buffering and backpressure, and the governance models required for multiple teams to safely access the same data lake.
The episode concludes with an honest look at the complexity trade-offs and a roadmap for organizations considering a migration from a coupled vendor stack.
Martin Kleppmann, Associate Professor at the University of Cambridge and author of the best-selling O'Reilly book Designing Data-Intensive Applications, talks to host Adi Narayan about local-first collaboration software. They discuss what the term means, how it leads to simpler application architectures compared to the cloud-first model, and the benefits to developers and users from keeping all of their data on their own devices. Martin goes into detail about how applications can synchronize data with and without a server, as well as conflict-resolution techniques, and the open-source library Automerge, which implements CRDTs and developers can use out-of-the-box. He also clarifies what kinds of applications would be suitable for the local-first approach. In the context of AI, they discuss vibe coding, local-first apps, and how the conflict-resolution work that enables data to be synchronized between users can also work with human-AI collaboration.
Sahaj Garg, co-founder and CTO of Wispr, a voice-to-text AI that turns speech into polished writing, talks with host Amey Ambade about designing systems for the ambiguity that's inherent in human input (text, voice, multimodal). Sahaj focuses on concrete architectural and training strategies for building robust AI systems. This episode examines the problem of ambiguity, where it shows up, building robust systems, personalization, communicating uncertainty, and evaluation. The conversation starts by exploring the difference between inherent and reducible ambiguity, major categories of ambiguity including lexical, syntactic, and pragmatic, and the additional sources of ambiguity in voice, such as homophones and accents. Garg details how to build systems through model training, including providing additional context and constructing datasets for good annotation. They discuss personalization with a focus on "revealed preferences"—learning from user behavior without explicit feedback—and fighting the problem of AI writing that "regresses to the mean." Finally, they consider how to communicate uncertainty to users without degrading the experience, as well as methods for evaluating ambiguity resolution through offline and online signals.
Costa Alexoglou, co-founder of the open source Hopp pair-programming application, talks with host Brijesh Ammanath about remote pair programming. They start with a quick introduction to pair programming and its importance to software development before discussing the various problems with the current toolset available and the challenges that tool developers face for enabling pair programming. They consider the key features necessary for a good pair-programming tool, and then Costa describes the journey of building Hopp and the challenges faced while building it.
Héctor Ramón Jiménez, creator of iced, an Elm-inspired, cross-platform GUI toolkit for Rust, speaks with SE Radio host Gavin Henry about building a GUI library in Rust. Héctor discusses why he created iced, what was needed, the process required to paint on the screen across different operating systems, how multi-operating systems are handled, and what the iced testing ecosystem is like. This episode explores the Elm architecture, how iced compares to other frameworks, what the core components of iced are, Elements, asynchronous functions, state, threads, 3d rendering, headless mode testing, end-to-end testing, test recorders, runtime emulators, ice test syntax, example apps, tiny-skia, DirectX, Vulkan, Metal, winit, wgpu, egui, tauri, comet, and why Android and iOS support is hard.
Dan Lorenc, co-founder and CEO of Chainguard, joins host Priyanka Raghavan to explore Sigstore and its role in securing the software supply chain. They unpack the challenges of supply chain security, including verifying the origin and integrity of software artifacts, and explain the problems Sigstore is designed to solve. The conversation goes under the hood to examine how Sigstore works, covering key components such as code signing, verification, the certificate authority model, and transparency logs—often compared conceptually to blockchain for their auditability. The episode also highlights real-world adoption, community resources for getting started, and closes with a discussion of Chainguard Images and how development teams can use them to build with more secure base images.
This episode is sponsored by IEEE Computer Society.
Scott Hanselman, the VP of Developer Community at Microsoft, speaks with host Jeremy Jung about AI-assisted coding. They start by considering how the tools are a progression from syntax highlighting and autocomplete. Scott describes the ambiguity and non-determinism of agentic loops, why vague high-level prompts usually don't give good results, and the need to express intent and steer the models. He explains how knowing fundamentals helps you create better plans and know what to ask the models, and how to treat agents differently based on your knowledge level. He discusses his experience porting Windows Live Writer to a modern .NET stack, and defining success and providing tools for models to verify their work. Finally, he explains why you need to read and understand generated code in production environments, plus methods for sandboxing agents.
Marc Brooker, VP and Distinguished Engineer at AWS, joins host Kanchan Shringi to explore specification-driven development as a scalable alternative to prompt-by-prompt "vibe coding" in AI-assisted software engineering. Marc explains how accelerating code generation shifts the bottleneck to requirements, design, testing, and validation, making explicit specifications the central artifact for maintaining quality and velocity over time. He describes how specifications can guide both code generation and automated testing, including property-based testing, enabling teams to catch regressions earlier and reason about behavior without relying on line-by-line code review.
The conversation examines how spec-driven development fits into modern SDLC practices; how AI agents can support design, code review, documentation, and testing; and why managing context is now one of the hardest problems in agentic development. Marc shares examples from AWS, including building drivers and cloud services using this approach, and discusses the role of modularity, APIs, and strong typing in making both humans and AI more effective. The episode concludes with guidance on rollout, evaluation metrics, cultural readiness, and why AI-driven development shifts the engineer's role toward problem definition, system design, and long-term maintainability rather than raw code production.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Bryan Cantrill, the co-founder and CTO of Oxide Computer company, speaks with host Jeremy Jung about challenges in deploying hardware on-premises at scale. They discuss the difficulty of building up Samsung data centers with off-the-shelf hardware, how vendors silently replace components that cause performance problems, and why AWS and Google build their own hardware. Bryan describes the security vulnerabilities and poor practices built into many baseboard management controllers, the purpose of a control plane, and his experiences building one in NodeJS while struggling with the runtime's future during his time at Joyent. He explains why Oxide chose to use Rust for its control plane and the OpenSolaris-based Illumos as the operating system for their vertically integrated rack-scale hardware, which is designed to help address a number of these key challenges.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Jens Gustedt, author of Modern C, senior scientist at the French National Institute for Computer Science and Control (INRIA), deputy director of the ICube lab, and former co-editor of the ISO C standard, speaks with SE Radio host Gavin Henry about the past 5 years in C, C2Y, and C23. They discuss what has happened in the C world since we last spoke 5 years ago, including how the latest C standard is going and what to expect. Jens discusses how the latest changes in the Modern C book apply to you, how a C transition header can help you get up to C23 if you're not there already, and presents a comprehensive approach for program failure. This episode explores C2Y, C23, bit-precise types, stdckdint.h, stdbit.h, 128 bit types, enumeration types, nullptr, Syntactic annotations, auto and typeof keywords, if let, as well as what's being added and removed in C2Y (possibly called "C28"), and Gustedt's four categories of program failure.
Brought to you by IEEE Computer Society and IEEE Software magazine.
In this episode, Subhajit Paul joins SE Radio host Kanchan Shringi to discuss how enterprise resource planning (ERP) systems work in practice and where machine learning and generative AI are beginning to fit into real-world ERP environments.
Subhajit grounds the conversation in ERP fundamentals, explaining core business flows such as order-to-cash, procure-to-pay, and plan-to-produce, and why ERP systems are central to running large enterprises. He then walks through the realities of ERP implementation, sharing examples of both successful and failed projects and highlighting common challenges around testing, process coverage, integrations, and change management.
The discussion also explores how AI is being applied in ERP today, including practical ML use cases such as inventory optimization and anomaly detection, as well as emerging generative AI and agent-based approaches.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Yechezkel "Chez" Rabinovich, CTO and co-founder at Groundcover, joins SE Radio host Brijesh Ammanath to discuss the key challenges in migrating observability toolsets. The episode starts with a look at why customers might seek to migrate their existing Observability stack, and then Chez explains some approaches and techniques for doing so. The discussion turns to OpenTelemetry, including what it is and how Groundcover helps with the migration of dashboards, monitors, pipelines, and integrations that are proprietary to vendor products. Chez describes methods for validating a successful migration, as well as metrics and signals that engineering teams can use to assess the migration health.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Murat Erder, CTO for Financial Services at Valtech in Europe, and Eoin Woods, independent consultant in the field of software architecture, join host Giovanni Asproni to talk about Continuous Architecture—an approach to software design where architectural decisions are made and refined continuously throughout the lifecycle of a system, instead of up front in a big design phase. The show starts with a definition of Continuous Architecture and a description of the six principles underpinning it. Following that is an explanation of the main reasons and advantages of this approach, which finishes with some hints on how to get started using it. During the conversation, they explore several key points, including how to empower teams to take architectural decisions and recording those decisions; using feedback loops to refine the architecture; the role of software architects and architectural governance; the importance of focusing on quality requirements; and the impact of artificial intelligence on the field.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Sriram Panyam returns to the show to discuss the system design interview (SDI) with host Robert Blumen. This challenging part of the hiring process is included in the interview loop for many jobs across tech, including management and for all levels from entry to senior. The conversation starts with a look at what the SDI is, who will face it, and how critical this interview is for hiring and leveling. Sriram shares some common system design questions and what the interviewers are generally looking for, including stated versus unstated requirements and ambiguity in the questions. He offers recommendations on how candidates should disambiguate their designs and manage their time. He shares some personal stories of interview failures and successes, and even discusses some mistakes that interviewers make.
Brought to you by IEEE Computer Society and IEEE Software magazine.
In this episode, Sahaj Garg, CTO of wispr.ai, joins SE Radio host Robert Blumen to talk about the challenges of building low-latency AI applications. They discuss latency's effect on consumer behavior as well as interactive applications. The conversation explores how to measure latency and how scale impacts it. Then Sahaj and Robert shift to themes around AI, including whether "AI" means LLMs or something broader, as they look at latency requirements and challenges around subtypes of AI applications. The final part of the episode explores techniques for managing latency in AI: speed vs accuracy trade-offs; speed vs cost; latency vs cost; choosing the right model; reducing quantization; distillation; and guessing + validating.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Derick Schaefer, author of CLI: A Practical Guide to Creating Modern Command-Line Interfaces, talks with host Robert Blumen about command-line interfaces old and new. Starting with a short review of the origin of commands in the early unix systems, they trace the evolution of commands into modern CLIs. Following the historic rise, fall, and re-emergence of CLIs, they consider innovative examples such as git, github, WordPress, and warp. Schaefer clarifies whether commands are the same as CLIs and then discusses a range of topics, including implementation languages, packages in the golang ecosystem for CLI development, CLIs and APIs, CLIs and AIs, AI tooling versus MCP, the object-command pattern, command flags, API authentication, whether CLIs should be stateless, and output formats - json, rich text.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Max Geurnsey III and Luniel de Beer, co-authors of the book Ready: Why Most Software Projects Fail and How to Fix It, discuss the concept of readiness in software engineering with host Brijesh Ammanath. Although Agile workflows and technical practices help delivery, many software efforts still struggle to achieve desired outcomes. Rework, shifting requirements, delays, defects, and mounting technical debt can plague software delivery and impede or altogether halt progress toward goals. The problem is often that implementation begins prematurely, before the team is properly set up for success. A strict system of explicit readiness work and gating, called Requirements Maturation Flow (RMF), has the potential to solve this problem in an SDLC-independent way. Teams that adopt RMF can dramatically improve progress toward real goals while reducing stress on engineering teams. In this episode, Max and Luniel deep dive into RMF and explain its foundational pillars.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Mojtaba Sarooghi, a Distinguished Product Architect at Queue-it, speaks with host Jeremy Jung about virtual waiting rooms for high-traffic events such as concerts and limited-quantity product releases. They explore using a virtual queue to prevent overloading systems, how most traffic is from bots, using edge workers to reduce requests to the customer's origin servers, and strategies for detecting bots in cooperation with vendors. Mojtaba discusses using AWS services like Elastic Load Balancing, DynamoDB, and Simple Notification Service, and explains why DynamoDB's eventual consistency is a good fit for their domain. To explain the approach, he walks us through how his team resolved an incident in which a traffic spike overloaded their services.
Brought to you by IEEE Computer Society and IEEE Software magazine.
In this episode, Benjamin Brial, CEO and co-founder of Cycloid, speaks with host Sriram Panyam about internal developer platforms (IDPs) and internal developer portals. The conversation explores how these platforms address the growing challenges of DevOps scalability, multi-cloud complexity, and cloud waste, all of which organizations face as they grow.
Benjamin begins by framing the core problems that IDPs solve: DevOps struggling to scale beyond small teams, the complexity of managing hybrid environments across on-premises, public cloud, and private cloud infrastructure, and the significant issue of cloud waste (averaging 35-45% according to major analysts). IDPs can serve as a bridge between DevOps teams and developers, providing access to tools, cloud resources, and automation for users who aren't DevOps or cloud experts. The technical discussion covers essential IDP components including service catalogs, versioning engines, platform orchestration, asset inventory, and FinOps/GreenOps modules. The episode concludes with Benjamin's practical advice: organizations should focus on understanding their specific pain points rather than following market trends, starting with simple use cases such as landing zones before building complex solutions, and adopt a GitOps-first approach as the foundation for any IDP implementation.
Brought to you by IEEE Computer Society and IEEE Software magazine.
In this episode of Software Engineering Radio, Srujana Merugu, an AI researcher with decades of experience, speaks with host Priyanka Raghavan about building LLM-based applications. The discussion begins by clarifying essential concepts like generative vs. predictive AI, pre-training vs. fine-tuning, and the transformer architecture that powers modern LLMs.
Srujana explains diffusion models and vision transformers, highlighting how multimodal AI is reshaping content creation. The conversation then moves to practical aspects—where LLMs make sense, where they don't, and a decision framework for evaluating use cases. They explore common application patterns such as retrieval-augmented generation (RAG) and agentic architectures, breaking down components like planners, orchestrators, memory, and tools. Key considerations for model selection, evaluation metrics, and safety guardrails are discussed in depth. The episode also touches on prompting strategies, automated prompt optimization, and emerging trends like multi-sensory AI and the "Internet of Senses." Finally, Srujana shares tips on staying current in a fast-moving AI landscape and emphasizes lifelong learning and curated knowledge sources.
Philip Kiely, software developer relations lead at Baseten, speaks with host Jeff Doolittle about multi-agent AI, emphasizing how to build AI-native software beyond simple ChatGPT wrappers. Kiely advocates for composing multiple models and agents that take action to achieve complex user goals, rather than just producing information. He explains the transition from off-the-shelf models to custom solutions, driven by needs for domain-specific quality, latency improvements, and economic sustainability, which introduces the engineering challenge of inference engineering. Kiely stresses that AI engineering is primarily software engineering with new challenges, requiring robust observability and careful consideration of trust and safety through evals and alignment. He recommends an approach of iterative experimentation to get started with multi-agent AI systems.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Flavia Saldanha, a consulting data engineer, joins host Kanchan Shringi to discuss the evolution of data engineering from ETL (extract, transform, load) and data lakes to modern lakehouse architectures enriched with vector databases and embeddings. Flavia explains the industry's shift from treating data as a service to treating it as a product, emphasizing ownership, trust, and business context as critical for AI-readiness. She describes how unified pipelines now serve both business intelligence and AI use cases, combining structured and unstructured data while ensuring semantic enrichment and a single source of truth. She outlines key components of a modern data stack, including data marketplaces, observability tools, data quality checks, orchestration, and embedded governance with lineage tracking. This episode highlights strategies for abstracting tooling, future-proofing architectures, enforcing data privacy, and controlling AI-serving layers to prevent hallucinations. Saldanha concludes that data engineers must move beyond pure ETL thinking, embrace product and NLP skills, and work closely with MLOps, using AI as a co-pilot rather than a replacement.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Dave Thomas, author of The Pragmatic Programmer, The Manifesto for Agile Software Development, Programming Ruby, Agile Web Development with Rails, Programming Elixir, Simplicity, and co-founder of the Pragmatic Bookshelf, speaks with SE Radio host Gavin Henry about building infrastructure for eBooks. They discuss what an eBook is, the various formats, what infrastructure is needed to build them, how an author writes an book, the history of the Pragmatic Bookshelf, how they have evolved, how to handle links within eBooks, why humans are so important in the writing process, and why AI can help with your writing -- once you've written your content. Thomas discusses PDFs, eBooks, Mobi files, ePub files, CI/CD pipelines, WYSWYG, Markdown files, Pragmatic Markup Language, embedding code, AI agents, images, printing PDFs, JVMs, Java, jRuby, and how Markdown won the plain text writing format wars.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Jennings Anderson, a Software Engineer with Meta Platforms, and Amy Rose, the Chief Technology Officer at Overture Maps Foundation, speak with host Gregory M. Kapfhammer about the Overture Maps project, which creates reliable, easy-to-use, and interoperable open map data. After exploring the foundations of geospatial information systems, Gregory and his guests dive deep into the implementation of Overture Maps through features like the Global Entity Reference System (GERS). In addition to discussing the organizational structure of the Overture Maps Foundation and the need for a unified database of geospatial data, Jennings and Amy explain how to implement applications using data from Overture Maps.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Mark Williamson, CTO of Undo, joins host Priyanka Raghavan to discuss AI-assisted debugging. The conversation is structured around three main objectives:
- understanding how AI can serve as a debugging assistant;
- examining AI-powered debugging tools;
- exploring whether AI debuggers can independently find and fix bugs.
Mark highlights how AI can support debugging with its ability to analyze vast amounts of data, narrow down issues, and even generate tests. From there, the discussion turns to AI debugging tools, with a particular look at ChatDBG's strengths and limitations, with a peek at time travel debugging. In the final segment, they consider several real-world scenarios and evaluate the feasibility and practicality of AI acting autonomously in debugging.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Sourabh Satish, CTO and co-founder of Pangea, speaks with SE Radio's Brijesh Ammanath about prompt injection. Sourabh begins with the basic concepts underlying prompt injection and the key risks it introduces. From there, they take a deep dive into the OWASP Top 10 security concerns for LLMs, and Sourabh explains why prompt injection is the top risk in this list. He describes the $10K Prompt Injection challenge that Pangea ran, and explains the key learnings from the challenge. The episode finishes with discussion of specific prompt-injection techniques and the security guardrails used to counter the risk.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Kacper Łukawski, a Senior Developer Advocate at Qdrant, speaks with host Gregory M. Kapfhammer about the Qdrant vector database and similarity search engine. After introducing vector databases and the foundational concepts undergirding similarity search, they dive deep into the Rust-based implementation of Qdrant. Along with comparing and contrasting different vector databases, they also explore the best practices for the performance evaluation of systems like Qdrant. Kacper and Gregory also discuss topics such as the steps for using Python to build an AI-powered application that uses Qdrant.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Florian Gilcher, co-founder of Ferrous Systems and the Rust Foundation, speaks with host Giovanni Asproni about the application of Rust in mission- and safety-critical systems. The discussion starts with a brief overview of such systems, and an introduction to Rust, emphasizing aspects that make it well-suited for critical environments.
Florian and Giovanni then discuss how Rust compares to C and C++ — two widely used languages in this sector. They proceed to outline important factors that companies should consider when assessing whether to move from C or other languages to Rust. The episode also touches on Ferrocene, an open-source Rust toolchain qualified for safety- and mission-critical systems, which was developed and supported by Ferrous Systems. The conversation ends with some reflections on the future of Rust for mission- and safety-critical applications.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Amey Desai, the Chief Technology Officer at Nexla, speaks with host Sriram Panyam about the Model Context Protocol (MCP) and its role in enabling agentic AI systems. The conversation begins with the fundamental challenge that led to MCP's creation: the proliferation of "spaghetti code" and custom integrations as developers tried to connect LLMs to various data sources and APIs. Before MCP, engineers were writing extensive scaffolding code using frameworks such as LangChain and Haystack, spending more time on integration challenges than solving actual business problems. Desai illustrates this with concrete examples, such as building GitHub analytics to track engineering team performance. Previously, this required custom code for multiple API calls, error handling, and orchestration. With MCP, these operations can be defined as simple tool calls, allowing the LLM to handle sequencing and error management in a structured, reasonable manner.
The episode explores emerging patterns in MCP development, including auction bidding patterns for multi-agent coordination and orchestration strategies. Desai shares detailed examples from Nexla's work, including a PDF processing system that intelligently routes documents to appropriate tools based on content type, and a data labeling system that coordinates multiple specialized agents. The conversation also touches on Google's competing A2A (Agent-to-Agent) protocol, which Desai positions as solving horizontal agent coordination versus MCP's vertical tool integration approach. He expresses skepticism about A2A's reliability in production environments, comparing it to peer-to-peer systems where failure rates compound across distributed components.
Desai concludes with practical advice for enterprises and engineers, emphasizing the importance of embracing AI experimentation while focusing on governance and security rather than getting paralyzed by concerns about hallucination. He recommends starting with simple, high-value use cases like automated deployment pipelines and gradually building expertise with MCP-based solutions.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Daniel Stenberg, Swedish Internet protocol expert and founder and lead developer of the Curl project, speaks with SE Radio host Gavin Henry about removing Rust from Curl. They discuss why Hyper was removed from curl, why the last five percent of making it a success was difficult, what the project gained from the 5-year attempt to tackle bringing Rust into a C project, lessons learned for next time, why user support is critical, and the positive long-lasting impact this attempt had.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Elizabeth Figura, a Wine Developer at CodeWeavers, speaks with SE Radio host Jeremy Jung about the Wine compatibility layer and the Proton distribution. They discuss a wide range of details including system calls, what people run with Wine, how games are built differently, conformance and regression testing, native performance, emulating a CPU vs emulating system calls, the role of the Proton downstream distribution, improving Wine compatibility by patching the Linux kernel and other related projects, Wine's history and sustainment, the Crossover commercial distribution, porting games without source code, loading executables and linked libraries, the difference between user space and kernel space, poor Windows API documentation and use of private APIs, debugging compatibility issues, and contributing to the project.
This episode is sponsored by Monday Dev
François Daoust, W3C staff member and co-chair of the Web Developer Experience Community Group, discusses the origins of the W3C, the browser standardization process, and how it relates to other organizations like TC39, WHATWG, and IETF. This episode covers a lot of ground, including funding through memberships, royalty-free patent access for implementations, why implementations are built in parallel with the specifications, why requestVideoFrameCallback doesn't have a formal specification, balancing functionality with privacy, working group participants, and how certain organizations have more power.
François explains why the W3C hasn't specified a video or audio codec, and discusses Media Source Extensions, Encrypted Media Extensions and Digital Rights Management (DRM), closed source content decryption modules such as Widevine and PlayReady, which ship with browsers, and informing developers about which features are available in browsers.
Brought to you by IEEE Computer Society and IEEE Software magazine.
In this episode, Will Wilson, CEO and co-founder of Antithesis, explores Deterministic Simulation Testing (DST) with host Sriram Panyam. Wilson was part of the pioneering team at FoundationDB that developed this revolutionary testing approach, which was later acquired by Apple in 2015. After seeing that even sophisticated organizations lacked robust testing for distributed systems, Wilson co-founded Antithesis in 2018 to make DST commercially available.
Deterministic simulation testing runs software in a fully controlled, simulated environment in which all sources of non-determinism are eliminated or controlled. Unlike traditional testing or chaos engineering, DST operates in a separate environment from production, allowing for aggressive fault injection without risk to live systems. The key breakthrough is perfect reproducibility -- any bug found can be recreated exactly using the same random seed.
Antithesis built "The Determinator," a custom deterministic hypervisor that simulates entire software stacks including virtual hardware, networking, and time. The system can compress years of stress testing into shorter timeframes by running simulations faster than wall-clock time. All external interfaces that could introduce non-determinism (network calls, disk I/O, system time) are mocked or controlled by the simulator.
The approach has proven effective with major organizations including MongoDB, Palantir, and Ethereum. For Ethereum's critical "Merge" upgrade in 2022, Antithesis found and helped fix several serious bugs that could have been catastrophic for the live network. The platform typically finds bugs that traditional testing methods miss entirely -- such as those arising from rare race conditions, complex timing issues, and unexpected system interactions.
This episode is sponsored by Monday Dev
Daniel Deogun and Dan Bergh Johnsson -- two of the co-authors of the book, Secure by Design -- discuss the intersection of good software design and security with host Sam Taggart. They describe how following certain software design principles can help developers create secure software without needing to become security experts. They talked about how this is the continuation of developers taking on more responsibilities: Agile asked developers to become responsible for testing their code. DevOps asked developers to work together with operations in deploying their code. Secure by Design asks developers to incorporate security into their designs.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Artie Shevchenko, author of Code Health Guardian, speaks with host Jeff Doolittle about the crucial role of human programmers in the AI era, emphasizing that humans must excel at managing code complexity. Shevchenko discusses these concepts and key takeaways from his book, including the three problems caused by complexity: change amplification, cognitive load, and the most severe, unknown unknowns. He suggests that maintaining code health should be viewed pragmatically as a productivity question, requiring an ownership mentality and product focus to balance short-term delivery with long-term maintainability. The episode also covers vital processes such as using design documents for upfront analysis and code reviews, highlighting four goals: high code quality, knowledge sharing, delivery speed, and -- most important for team productivity -- psychological safety.
This episode is sponsored by Monday Dev
Duncan McGregor and Nat Pryce, co-authors of Java to Kotlin: Refactoring Guidebook, speak with host Giovanni Asproni about their hands-on experiences migrating Java codebases. The episode starts by highlighting Kotlin’s seamless interoperability with Java, allowing teams to incrementally adopt Kotlin without disrupting existing Java code.
Duncan and Nat then describe some of the benefits of using Kotlin — including stronger type safety, non-nullable types, and better support for immutability — and some of the gotchas when refactoring from Java to Kotlin due to the different idioms supported by the two languages. Finally, they discuss the importance of testing and tooling, and the evolving role of AI-assisted tools in complex and large-scale refactorings — in the context of work done by teams, as opposed to individuals.
This episode is sponsored by Monday Dev
Qian Li of DBOS, a durable execution platform born from research by the creators of Postgres and Spark, speaks with host Kanchan Shringi about building durable, observable, and scalable software systems, and why that matters for modern applications. They discuss database-backed program state, workflow orchestration, real-world AI use cases, and comparisons with other workflow technologies.
Li explains how DBOS persists not just application data but also program execution state in Postgres to enable automatic recovery and exactly-once execution. She outlines how DBOS uses workflow and step annotations to build deterministic, fault-tolerant flows for everything from e-commerce checkouts to LLM-powered agents. Observability features, including SQL-accessible state tables and a time-travel debugger, allow developers and business users to understand and troubleshoot system behavior. Finally, she compares DBOS with tools like Temporal and AWS Step Functions.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Luke Hinds, CTO of Stacklok and creator of Sigstore, speaks with SE Radio's Brijesh Ammanath about the privacy and security concerns of using AI coding agents. They discuss how the increased use of AI coding assistants has improved programmer productivity but has also introduced certain key risks. In the area of secrets management, for example, there is the risk of secrets being passed to LLMs. Coding assistants can also introduce dependency-management risks that can be exploited by malicious actors. Luke recommends several tools and behaviors that programmers can adopt to ensure that secrets do not get leaked.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Wesley Beary of Anchor speaks with host Sam Taggart about designing APIs with a particular emphasis on user experience. Wesley discusses what it means to be an “API connoisseur”— paying attention to what makes the APIs we consume enjoyable or frustrating and then taking those lessons and using them when we design our own APIs. Wesley and Sam also explore the many challenges developers face when designing APIs, such as coming up with good abstractions, testing, getting user feedback, documentation, security, and versioning. They address both CLI and web APIs.
This episode is sponsored by Fly.io.
Chris Love, co-author of the book Core Kubernetes, joins host Robert Blumen for a conversation about kubernetes security. Chris identifies the node layer, secrets management, the network layer, contains, and pods as the most critical areas to be addressed.
The conversation explores a range of topics, including when to accept defaults and when to override; differences between self-managed clusters and cloud-service provider-managed clusters; and what can go wrong at each layer -- and how to address these issues. They further discuss managing the node layer; network security best practices; kubernetes secrets and integration with cloud-service provider secrets; container security; pod security, and Chris offers his views on policy-as-code frameworks and scanners.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Jacob Visovatti and Conner Goodrum of Deepgram speak with host Kanchan Shringi about testing ML models for enterprise use and why it's critical for product reliability and quality. They discuss the challenges of testing machine learning models in enterprise environments, especially in foundational AI contexts. The conversation particularly highlights the differences in testing needs between companies that build ML models from scratch and those that rely on existing infrastructure. Jacob and Conner describe how testing is more complex in ML systems due to unstructured inputs, varied data distribution, and real-time use cases, in contrast to traditional software testing frameworks such as the testing pyramid.
To address the difficulty of ensuring LLM quality, they advocate for iterative feedback loops, robust observability, and production-like testing environments. Both guests underscore that testing and quality assurance are interdisciplinary efforts that involve data scientists, ML engineers, software engineers, and product managers. Finally, this episode touches on the importance of synthetic data generation, fuzz testing, automated retraining pipelines, and responsible model deployment—especially when handling sensitive or regulated enterprise data.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Samuel Colvin, the CEO and founder of Pydantic, speaks with host Gregory M. Kapfhammer about the ecosystem of Pydantic’s Python frameworks, including Pydantic, Pydantic AI, and Pydantic Logfire.
Along with discussing the design, implementation, and use of these frameworks, they dive into the refactoring of Pydantic and the follow-on performance improvements. They also explore ways in which Python programmers can use these three frameworks to build, test, evaluate, and monitor their own applications that interact with both local and cloud-based large language models.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Brian Demers, Developer Advocate at Gradle, speaks with host Giovanni Asproni about the importance of having observability in the toolchain. Such information about build times, compiler warnings, test executions, and any other system used to build the production code can help to reduce defects, increase productivity, and improve the developer experience. During the conversation they touch upon what is possible with today’s tools; the impact on productivity and developer experience; and the impact, both in terms of risks and opportunities, introduced by the use of artificial intelligence.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Vilhelm von Ehrenheim, co-founder and chief AI officer of QA.tech, speaks with SE Radio's Brijesh Ammanath about autonomous testing.
The discussion starts by covering the fundamentals, and how testing has evolved from manual to automated to now autonomous. Vilhelm then deep dives into the details of autonomous testing and the role of agents in autonomous testing.
They consider the challenges in adopting autonomous testing, and Wilhelm describes the experiences of some clients who have made the transition. Toward the end of the show, Vilhelm describes the impact of autonomous testing on the traditional QA career and what test professionals can do to upskill.
This episode is sponsored by Fly.io.
In this episode of Software Engineering Radio, Abhinav Kimothi sits down with host Priyanka Raghavan to explore retrieval-augmented generation (RAG), drawing insights from Abhinav's book, A Simple Guide to Retrieval-Augmented Generation.
The conversation begins with an introduction to key concepts, including large language models (LLMs), context windows, RAG, hallucinations, and real-world use cases. They then delve into the essential components and design considerations for building a RAG-enabled system, covering topics such as retrievers, prompt augmentation, indexing pipelines, retrieval strategies, and the generation process.
The discussion also touches on critical aspects like data chunking and the distinctions between open-source and pre-trained models. The episode concludes with a forward-looking perspective on the future of RAG and its evolving role in the industry.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Luca Palmieri, author of Zero to Production in Rust and Principal Engineering Consultant at MainMatter, speaks with SE Radio host Gavin Henry about Rust in production.
They discuss what production Rust means, how to get Rust code into production, specific Rust issues to think about when getting an application into production, what Rust profiles are, expected performance, telemetry options, error handling and what parts of Rust to use and avoid.
Palmieri discusses docker containers, tracing, robust Rust error handling, how performant Rust is in the real world, p50, p99, docker build techniques, project layouts, crates, speeding up Rust build times, unwrap(), panics, budgeting resources, inner development loops, the Facade Pattern, structured logging, and how to always use clippy.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Will McGugan, the CEO and founder of Textualize, speaks with host Gregory M. Kapfhammer about how to use packages such as Rich and Textual to build text-based user interfaces (TUIs) and command-line interfaces (CLIs) in Python. Along with discussing the design idioms that enable developers to create TUIs in Python, they consider practical strategies for efficiently rendering the components of a TUI. They also explore the subtle idiosyncrasies of implementing performant TUI frameworks like Textual and Rich and introduce the steps that developers would take to create their own CLI or TUI.
This episode is sponsored by Fly.io.
In this episode, SE Radio host Sriram Panyam explores HTMX with its creator, Carson Gross, who is also creator of Hyperscript, the mind behind the Grug Brained Developer, a professor of software engineering at Montana State University, and co-author of Hypermedia Systems.
HTMX is a modern JavaScript library that allows developers to access AJAX, WebSockets, CSS Transitions, and Server-Sent Events directly in HTML using attributes. It represents a return to hypermedia-driven application architecture while supporting modern user experiences. The episode starts with a look at the current complexity in web development and how HTMX offers an alternative approach. Carson explains the core philosophy of "HTML as the interface" and how hypermedia principles influenced HTMX's design. From there, they dive into HTMX's technical concepts, including its attribute system, server-side integration, event handling, and state management approach.
Carson shares some real-world implementation strategies, including migration paths from JavaScript frameworks, architectural patterns, and performance considerations -- as well as a few scenarios in which HTMX might not be the best fit. Finally, they look at the growing HTMX ecosystem, community contributions, and future development roadmap. Throughout the episode, Carson provides concrete examples and case studies of HTMX in production environments.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Matthias Endler, Rust developer, open-source maintainer, and consultant through his company Corrode, speaks with SE Radio host Gavin Henry about prototyping in Rust.
They discuss prototyping and why Rust is excellent for prototyping, and Matthias recommends a workflow for it, including what parts of Rust to use, and what parts to avoid at this stage. He describes the key components that Rust provides to help us validate ideas via prototypes, as well as tips and tricks to reach for.
In addition, the conversation explores type inference, unwrap(), expect(), anyhow crate, bacon crate, cargo-script, Rust macros to use, generics, lifetimes, best practices, project layout styles, and how to design through types.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Steve Summers speaks with SE Radio host Sam Taggart about securing test and measurement equipment. They start by differentiating between IT and OT (Operational Technology) and then discuss the threat model and how security has evolved in the OT space, including a look some of the key drivers. They then examine security challenges associated with a specific device called a CompactRIO, which combines a Linux real-time CPU with a field programmable gate array (FPGA) and some analog hardware for capturing signals and interacting with real-world devices.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Ashley Peacock, the author of Serverless Apps on Cloudflare, speaks with host Jeremy Jung about content delivery networks (CDNs). Along the way, they examine dependency injection with bindings, local development, serverless, cold starts, the V8 runtime, AWS Lambda vs Cloudflare workers, WebAssembly limitations, and core services such as R2, D1, KV, and Pages. Ashley suggests why most users use an external database and discusses eventually consistent data stores, S3-to-R2 migration strategies, queues and workflows, inter-service communication, durable objects, and describes some example projects.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Eran Yahav, Professor of Computer Science at Technion, Israel, and CTO of Tabnine, speaks with host Gregory M. Kapfhammer about the Tabnine AI coding assistant. They discuss how the design and implementation allows software engineers to use code completion and perform tasks such as automated code review while still maintaining developer privacy. Eran and Gregory also explore how research in the field of natural language processing (NLP) and large language models (LLMs) has informed the features in Tabnine.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Malcolm Matalka, founder of Terrateam, joins host Giovanni Asproni to talk about the reasoning behind choosing a not-so-widespread language (OCaml) and (almost) totally avoiding frameworks for the development of Terrateam. While discussing the reasons for choosing this specific programming language and the advantages and disadvantages of using external frameworks, they also consider a range of related topics, including static vs. dynamic typing, the use of monorepos, and the advantages of choosing a single language that can be used both for web front ends and server back ends. The episode ends with lessons learned that can be applied to other contexts and projects.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Emre Baran, CEO and co-founder of Cerbos, and Alex Olivier, CPO and co-founder, join SE Radio host Priyanka Raghavan to explore “stateless decoupled authorization frameworks. The discussion begins with an introduction to key terms, including authorization, authorization models, and decoupled frameworks.
They dive into the challenges of building decoupled authorization, as well as the benefits of this approach and the operational hurdles. The conversation shifts to Cerbos, an open-source policy-based access control framework, comparing it with OPA (Open Policy Agent). They also delve into Cerbos’s technical workings, including specification definitions, GitOps integration, examples of usage, and deployment strategies. The episode concludes with insights into potential trends in the authorization space.
This episode is sponsored by Penn Carey Law school
Tyler Flint, CEO of qpoint.io, joins host Robert Blumen for a conversation about managing external vendor dependencies, including several best practices for adoption. They start with a look at internal versus external services, including details such as the footprint of external services within a micro-services application, and difficulties organizations have tracking their service consumption, quantifying service consumption, and auditing external services. Tyler also discusses the security implications of external services, including authentication and authorization. They examine metrics and monitoring, with recommendations on the key metrics to collect, as well as acceptable error rates for external services. From there they consider what can go wrong, how to respond to external service outages, and challenges related to testing external services. The episode wraps up with a discussion of qPoint’s migration from a proxy-based solution to one based on eBPF kernel probes.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Software architect and author Vlad Khononov joins host Jeff Doolittle for a discussion on balancing coupling in software design. They start by examining coupling and its relationship to complexity and modularity. Vlad explains the historical models for assessing coupling and introduces his updated approach, integration strength, which aims to simplify earlier frameworks and adapt them for modern practices.
The episode explores three dimensions of coupling:
- integration strength (knowledge sharing),
- distance (proximity of components), and
- volatility (likelihood of change).
Vlad illustrates how design decisions can lead systems toward complexity or modularity, and he emphasizes the importance of managing coupling to minimize cognitive load and cascading changes. The conversation wraps up with insights on applying these principles to real-world software projects and a reminder of coupling's critical role in software architecture. Brought to you by IEEE Computer Society and IEEE Software magazine.
Sunil Mallya, co-founder and CTO of Flip AI, discusses small language models with host Brijesh Ammanath. They begin by considering the technical distinctions between SLMs and large language models.
LLMs excel in generating complex outputs across various natural language processing tasks, leveraging extensive training datasets on with massive GPU clusters. However, this capability comes with high computational costs and concerns about efficiency, particularly in applications that are specific to a given enterprise. To address this, many enterprises are turning to SLMs, fine-tuned on domain-specific datasets. The lower computational requirements and memory usage make SLMs suitable for real-time applications. By focusing on specific domains, SLMs can achieve greater accuracy and relevance aligned with specialized terminologies.
The selection of SLMs depends on specific application requirements. Additional influencing factors include the availability of training data, implementation complexity, and adaptability to changing information, allowing organizations to align their choices with operational needs and constraints.
This episode is sponsored by Codegate.
Pete Warden, CEO of Useful Sensors and a founding member of the TensorFlow team at Google, discusses TinyML, the technology enabling machine learning on low-power, small-footprint devices. This innovation opens up applications such as voice-controlled devices, offline translation tools, and smarter embedded systems, which are crucial for privacy and efficiency.
SE Radio host Kanchan Shringi speaks with Warden about challenges like model compression, deployment constraints, and privacy concerns. They also explore applications in agriculture, healthcare, and consumer electronics, and close with some practical advice from Pete for newcomers to TinyML development.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Brenden Matthews, a seasoned software engineer, entrepreneur, and author of the Idiomatic Rust and Code Like a Pro in Rust books (both from Manning), speaks with SE Radio host Gavin Henry about Idiomatic Rust. They start with a look at what "idiomatic" means, and then discuss Generics, Traits, common design patterns you'll see in well written Rust code, and anti-patterns to avoid. Matthews suggests some tools that can help you immediately write idiomatic Rust, as well as what building blocks can also help. This episode examines what Generics are and how they compare to other languages, as well as what Traits are, how macros help, what a Fluent Interface is, and why unwrap() is bad. They also discuss what code smells to look out for, Clone, Copy, and a really nice place to go read real-world Idiomatic Rust code.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Tanya Janca, author of Alice and Bob Learn Secure Coding, discusses secure coding and secure software development life cycle with SE Radio host Brijesh Ammanath. This session explores how integrating security into every phase of the SDLC helps prevent vulnerabilities from slipping into production. Tanya strongly recommends defining security requirements early, and discusses the importance of threat modeling during design, secure coding practices, testing strategies such as static, dynamic, and interactive application security testing (SAST, DAST and IAST), and the need for continuous monitoring and improvement after deployment.
This episode is sponsored by Codegate.ai
Hong Minhee, an open source developer and creator of the Fedify ActivityPub library, discusses the ActivityPub protocol and the fediverse with SE Radio's Jeremy Jung. They explore ActivityPub use cases, including microblogging applications such as Mastodon and Misskey, as well as activities built into the specification such as Like, Follow, and Accept. They also discuss extending the specification to include properties like Discoverable and Suspended, how different implementations communicate when they don’t implement the same extensions, ND the use of JSON-LD and why it is challenging to implement. Finally, they consider the HTTP-based inbox communication model, difficulties with scaling when using a push rather than a pull model, account migration, and resources for implementing the ActivityPub specification.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Ivett Ördög speaks with host Sam Taggart about rewrite versus refactor -- a choice that many projects face as they grow. It's a topic that inspires a lot of dogmatic feelings. They discuss how companies and projects end up at this crossroads and consider some strategies to try to avoid it. Ivett challenges the myth that you should never rewrite but points to two key factors that need to be present for a successful large-scale rewrite or refactor. They end by talking about how to get management on board for such large-scale rewrite or refactor projects.
Brought to you by IEEE Computer Society and IEEE Software magazine.
In this episode, Charles Humble speaks withhost Brijesh Ammanath about skills that can provide developers a grounding in systems thinking.
Charles is a 30-year veteran of the IT industry, including as a former software engineer, architect, and CTO, as well as former editor in chief of InfoQ and chief editor for Container Solutions. He has published “Professional Skills for Software Engineers” as a series of 14 O’Reilly shortcuts covering communication, critical thinking, documentation, and networking.
Underlying his work is the idea that as complexity increases in IT systems, the roles of architects and leaders move from linear thinking to something that might be more broadly defined as systems thinking -- looking at problems and systems as a whole rather than just the individual parts. This requires a skill set that isn’t generally taught or widely valued as an industry -- in part, because it's hard to test in whiteboard interviews. It requires a mixture of communication skills; interpersonal skills; critical thinking; the ability to synthesize large amounts of information.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Chris Patterson, founder and principal architect of MassTransit, joins host Jeff Doolittle to discuss MassTransit, a message bus framework for building distributed systems. The conversation begins with an exploration of message buses, their role in asynchronous and durable application design, and how frameworks like MassTransit simplify event-driven programming in .NET. Chris explains concepts like pub/sub, durable messaging, and the benefits of decoupled architectures for scaling and reliability.
The discussion also delves into advanced topics such as sagas, stateful consumers for orchestrating complex processes, and how MassTransit supports patterns like outbox and routing slips for ensuring transactional consistency. Chris highlights the importance of observability in distributed systems, sharing how MassTransit integrates with tools like OpenTelemetry to provide comprehensive monitoring.
The episode includes advice on adopting event-driven approaches, overcoming leadership hesitancy, and ensuring secure and efficient implementations. Chris emphasizes the balance between leveraging cutting-edge tools and addressing real-world challenges in software architecture.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Asanka Abeysinghe, CTO at WSO2, joins host Giovanni Asproni to discuss cell-based architecture -- a style that's intended to combine application, deployment, and team architecture to help organizations respond quickly to changes in the business environment, customer requirements, or enterprise strategy. Cell-based architecture is aimed at creating scalable, modular, composable systems with effective governance mechanisms. The conversation starts by introducing the context and some vocabulary before exploring details about the main elements of the architecture and how they fit together. Finally, Asanka offers some advice on how to implement a cell-based architecture in practice.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Related Episodes * SE Radio 396: Barry O’Reilly on Antifragile Architecture * SE Radio 331: Kevin Goldsmith on Architecture and Organizational Design * SE Radio 263: Camille Fournier on Real-World Distributed Systems * SE Radio 236: Rebecca Parsons on Evolutionary Architecture * SE Radio 213: James Lewis on Microservices * SE Radio 210: Stefan Tilkov on Architecture and Micro Services * SE Radio 203: Leslie Lamport on Distributed Systems
Christian Mesh, tech lead of the OpenTofu project, speaks with host Robert Blumen about OpenTofu. They start with the history of terraform, terraform providers, license changes to open source projects, the origin of OpenTofu as a fork of terraform, and the structure of the OpenTofu organization. They further explore compatibility issues for HCL, providers, and modules, performance issues, and adoption, as well as significant features in the OpenTofu-included dynamic-provider iteration, and the roadmap for the project going forward.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Paul Frazee, CTO of Bluesky, speaks with SE Radio's Jeremy Jung about the Authenticated Transfer Protocol (ATProto) used by the Bluesky decentralized social network. They discuss why ATProto was created, as well as how it differs from the ActivityPub open standard, the scaling limitations of peer-to-peer solutions, cryptographic decentralized identifiers, and creating a protocol based on experience with distributed systems. They also examine the role of personal data servers, relays, and app views, the benefits of using domain names, allowing users to create algorithmic feeds and moderation tools, and the challenges of content moderation.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Robert Seacord, the Standardization Lead at Woven by Toyota, the convenor of the C standards committee, and author of The CERT® C Coding Standard, Effective C, and Secure Coding in C and C++, speaks with SE Radio host Gavin Henry about What's New in the C Programming Language.
They start with a review of the history of C and why it has a standard, and then they discuss what C23 brings and how programmers can take advantage of it. They consider the sectors in which C is most used and whether you should use C to start a brand new project in 2025. Seacord discusses 8 new things that C23 brings, use case examples, must haves, floating point numbers, how automotive systems use C, why C is used there, Rust vs C, compile time checks vs static analysis, all the various safety standards they can use, why you should use the right tool for the job and never trust user input no matter the language.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Lukas Gentele, CEO of Loft Labs, joins host Robert Blumen for a discussion of kubernetes vclusters (virtual clusters). A vcluster is a kubernetes cluster that runs kubernetes application on a host kubernetes cluster. The conversation covers: vcluster basics; sharing models; what is owned by the vcluster and what is shared with the host; attached nodes versus shared nodes; the primary use case: multi-tenancy vcluster per tenant; alternatives - namespace per tenant, full cluster per tenant; trade-offs - isolation; less resource use; spin up time; scalability; how many clusters and how many vclusters should an org have? Deployment models for vclusters - helm chart with standard resources; vcluster operator; persistent storage models for vclusters; vcluster snapshotting, recovery, and migration. how many vclusters can run on a cluster? ingress, TLS and DNS.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Matthew Adams, Head of Security Enablement at Citi, joins SE Radio host Priyanka Raghavan to explore the use of large language models in threat modeling, with a special focus on Matthew's work, Stride GPT. The episode kicks off with an overview of threat modeling, its applications, and the stages of the development life cycle where it fits in. They then discuss the STRIDE methodology and strideGPT, highlighting practical examples, the technology stack behind the application, and the tool's inputs and outputs. The show concludes with tips and tricks for optimizing tool outputs and advice on other open source projects that utilize generative AI to bolster cybersecurity defenses. Brought to you by IEEE Computer Society and IEEE Software magazine.
Praveen Gujar, Director of Product at LinkedIn, joins SE Radio host Kanchan Shringi for a discussion on how generative AI (GenAI) is transforming digital advertising technology platforms. The conversation starts with a look at how GenAI facilitates scalable ad content creation, using self-attention mechanisms for customized ad generation. They explore AI's role in simplifying campaign management, automating tasks such as audience targeting and performance measurement. Praveen emphasizes that ad tech platforms use AI models tailored to different needs leveraging both first-party and third-party data sources, with privacy maintained through methods such as CAPI (conversion API). They also consider the differences between retrieval-augmented generation (RAG) and fine-tuning in AI models: Whereas RAG uses brand-specific data at runtime for precise ad content, fine-tuning focuses on broader model optimization. The segment highlights the importance of vector embeddings and vector search in storing and retrieving contextual content. Lastly, Praveen discusses the integration of AI teams within product development to improve collaboration and AI proficiency across organizations. Brought to you by IEEE Computer Society and IEEE Software magazine.
Matthew Skelton joins host Giovanni Asproni to talk about team topologies—an approach to organizing teams for fast flow of value. The episode starts with a description of the underlying principles before exploring the approach in more detail. From there, they discuss when to consider implementing the approach; keys to a successful implementation; and some common mistakes to avoid. Brought to you by IEEE Computer Society and IEEE Software magazine.
Vinay Tripathi, a senior network engineer in Google Backbone Engineering and an 18-year network engineering veteran, discusses BGP optimization, a technique that's critical in achieving top goals in distributed applications. Host Philip Winston speaks with Tripathi about BGP, autonomous systems, peer grouping, router hardware and software, software-defined networks, and shared network optimization and debugging stories. Brought to you by IEEE Computer Society and IEEE Software magazine.
Tim McNamara, a well-known Rust educator, author of Rust in Action (Manning), and a recipient of a Rust Foundation Fellowship in 2023, speaks with SE Radio host Gavin Henry about error handling in Rust. They discuss the errors that Rust prevents, what an error is in Rust, what Tim classes as the "four levels of error handling," and the lifecycle of your journey reaching for them.
McNamara explains why Rust handles errors as it does, how it differs from other languages, and what the developer experience is like in dealing with Rust errors. He advocates best practices for error handling, what Result is, the power of Rust Enums, what the question mark operator is, when to unwrap, what Box really means, how to deal with errors across the FFI boundary, and the various Rust error-handling crates that you can use to give you more control.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Ganesh Datta, co-founder of Cortex.io, joins host Robert Blumen for a conversation about production readiness. The conversation covers the history of production readiness; its relationship to microservice architecture; the Google SRE model's impact on production readiness; production readiness checklists; the process; and production readiness transparency.
Simon Wijckmans, founder of c/side — a company that focuses on monitoring, securing, and optimizing third-party JavaScript — joins SE Radio host Kanchan Shringi for a conversation about the security risks posed by third-party browser scripts. Through real-world examples and insights drawn from his work in web security, Simon highlights the dangers, including malicious attacks such as the recent Polyfill.io incident. He emphasizes the need for vigilant monitoring, as these third-party scripts remain essential for website functionalities like analytics, chatbots, and ads, despite their potential vulnerabilities. Simon explores the use of self-hosting solutions and content security policies (CSPs) to minimize risks, but he stresses that these measures alone are insufficient to fully safeguard websites.
As the discussion continues, they delve into the importance of layering security approaches. Simon advocates for combining techniques like CSPs, real-time monitoring, and AI-driven analysis, which his company c/side employs to detect and block malicious scripts. He also touches on the complexities of securing single-page applications (SPAs), which allow scripts to persist across pages without full reloads, increasing the attack surface for third-party vulnerabilities. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show NotesRelated Episodes* SE Radio 552: Matt Frisbie on Browser Extensions * SE Radio 541: Jordan Harband and Donald Fischer on Securing the Supply Chain * SE Radio 489: Sam Boyer on Package Management
Other References* c/side | Monitoring, Securing, and Optimizing 3rd-Party Scripts * PCI DSS 4.0 complete guide and steps * “I’m harvesting credit card numbers and passwords from your site. Here’s how.” (blog post) * “How I Hacked Your Website and You Didn’t Even Know” (video)
Catherine Nelson, author of the new O’Reilly book, Software Engineering for Data Scientists, discusses the collaboration between data scientists and software engineers — an increasingly common pairing on machine learning and AI projects. Host Philip Winston speaks with Nelson about the role of a data scientist, the difference between running experiments in notebooks and building an automated pipeline for production, machine learning vs. AI, the typical pipeline steps for machine learning, and the role of software engineering in data science. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes Software Engineering for Data Scientists (O’Reilly, 2024) * Building Machine Learning Pipelines* (O’Reilly, 2020) * LinkedIn: CatherineNelson1
Related Episodes* Episode 315: Jeroen Janssens on Tools for Data Science * Episode 286: Katie Malone Intro to Machine Learning * Episode 594: Sean Moriarity on Deep Learning with Elixir and Axon * Episode 588: José Valim on Elixir, Machine Learning, and Livebook * Episode 450: Hadley Wickham on R and Tidyverse
TranscriptTranscript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact content@computer.org and include the episode number.
Philip Winston 00:00:35 Welcome to Software Engineering Radio. This is Philip Winston. My guest today is Catherine Nelson. Catherine is a freelance data scientist and the author of two O’Reilly books: this year’s Software Engineering for Data Scientists and her 2020 book, Building Machine Learning Pipelines co-authored with Hannah Kafka. Previously, she was a principal data scientist at SAP Concur, and before that she had a career as a geophysicist. Catherine has a PhD in Geophysics from Durham University and a master’s of Earth Sciences from Oxford University. She is currently consulting for startups in the generative AI space. Welcome Catherine.
Catherine Nelson 00:01:16 Thanks Philip. It’s great to be on the podcast.
Philip Winston 00:01:19 Today we’re going to discuss the role of the data scientist and how this role can overlap with or intersect software engineering. Let’s start with what is a data scientist?
Catherine Nelson 00:01:31 That’s such a great question because what a data scientist is depends on where you work. At some companies it can be more in the data analytics space and at others it can mean that you’re spending all your time training machine learning models. But overall, I’d say being a data scientist involves translating business problems into data problems, solving them where possible, and then sometimes building machine learning powered features.
Philip Winston 00:01:57 So what skills does a data scientist need either prior to getting the role or what skills do they need to develop to be good at the role?
Catherine Nelson 00:02:05 They need to have skills for working with data. So those would include a knowledge of statistics, a knowledge of coding to be able to manipulate the data, take courses in basic machine learning, learn about the algorithms that make up machine learning, data visualization, sometimes storytelling with data, how to weave those data visualizations together to a coherent whole. A lot of data scientists will take courses on data ethics, data privacy, because sometimes that is part of the data scientists job as well. It’s a real mixed bag.
Philip Winston 00:02:43 It seems like data scientists need perhaps more domain knowledge or business knowledge than some engineering roles. Why do you think this is?
Catherine Nelson 00:02:55 I’d say that’s right. I think it’s because you are translating the problems from a business problem to a data problem. So you might be tasked to answer a problem such as why are our customers churning? Why do some customers leave the business? And you dig into the data to try and see what features of a company are correlated with them stopping using your product. So it might be something like the size of the business or they might have left given you feedback that has some reasons for that. So you can’t really answer a problem like that without having a good sense of what the business does, what products that are, how things fit together. So yeah, I think it involves a lot more context.
Philip Winston 00:03:41 On a typical project, who does the data scientists have to communicate with, typically?
Catherine Nelson 00:03:46 The interesting thing I’ve found with my data science career is I wouldn’t say I have a typical project. So I’ve done some projects where it’s been extremely exploratory. It’s been like, we might be considering creating a new feature for the product, is this even possible? It’s really blue sky. And then there’s other projects I’ve worked on where it’s been towards the production end of things, deploying new models into production. So I’m going to be working with different people depending on the type of project, but some commonalities would be a product organization and obviously engineers if it’s involving building features.
Philip Winston 00:04:32 For most of the episode we’re going to be talking about machine learning and AI, but as I understand it, there’s more to data science than just these two fields. Can you give me example of a problem you solved or a solution you came up with in data science that didn’t involve ML or AI?
Catherine Nelson 00:04:51 Actually, the example that I just mentioned, looking at why customers might leave a business that involved no machine learning at all. It was a predictive modeling problem, but I didn’t use a machine learning solution. So the projects that are more around answering questions versus building features are the ones where there’s a lower level of machine learning, AI usage, and more statistics or data visualization or general data analysis skills.
Philip Winston 00:05:20 I want to mention two past episodes related to data science. There’s Episode 315, Jeroen Janssen’s on Tools for Data Science. That was in 2018 and Episode 286, Katie Malone, Intro to Machine Learning, 2017. Katie Malone is a data scientist. So now let’s move into talking about machine learning and AI to start with. What is the difference between these two fields? And in my research, I think I’ve seen the term AI has been evolving a lot, so I’m wondering what definitions you use.
Catherine Nelson 00:05:55 The most useful definition I’ve heard and the one that I’ve adopted and continue to use was from a podcast that I heard with Christopher Manning who’s a professor at Stanford University in their natural language processing. And that is that if you’re dealing with machine learning, then you are training a model for one particular problem, one particular use. But an AI model can answer many problems. So you might use your AI model to power a chat bot, but you could use the same model to summarize some text or extract some information for some text. Whereas in classical traditional machine learning, if you wanted to have a model that extracted some information from some text, you’d go and collect the dataset designed for exactly that problem. You take some of the input text and what the output that you wanted it to produce and then you’d train your model and measure how accurate it was on that particular problem.
Philip Winston 00:07:00 I’d like to talk a little bit about the use of notebooks like Google’s CoLab in data science. This is a technique or a method that I think is more common in data science than in software engineering at large. So I’m wondering what are the pros and if there are any cons of doing your work inside of a notebook?
Catherine Nelson 00:07:21 Definitely. I’m a huge fan of Jupyter Notebooks. I love being able to get the instant feedback on what my code is doing, which is particularly useful when I’m looking at data all the time. I can print that data, I can plot a small graph of that data, I can really interact with that data while I’m coding. I find them incredibly useful when I’m starting a project, I don’t quite know where things are going. I’m really exploring around and trying to see what the data I’m working with can do for me. Or I’m starting with a basic machine learning model and seeing if it learns anything about the problem that I’m working on.
Philip Winston 00:08:06 What sorts of signs are there that maybe you need to switch to just a traditional Git repository? What starts to become difficult with a notebook?
Catherine Nelson 00:08:17 For me, I refactor when I’m at the point where I want to train that model repeatedly. So in a machine learning problem, I have chosen the features that I want to work with. I’ve chosen the data that I want to work with. I’ve trained an initial model, it’s getting a reasonable result, but then I want to train it repeatedly and optimize the high parameters and then eventually move towards deploying it into production. So I think that’s the main difference is that when I just have code that I may only run once, I donít know where I’m going, I donít know exactly what the final code base will look like, that’s when I’m happiest in the Jupyter Notebook. But when it’s going to be run repeatedly, when I need to write tests, when I need to make sure that code is robust, that’s when I do that refactor.
Philip Winston 00:09:19 In a little while, we’re going to talk through the steps in a machine learning workflow, focusing on what it would be like to make an automated reusable pipeline out of them. But let’s talk a little bit more about roles. So I think you mentioned data analyst relative to data scientists. Let’s talk about a machine learning engineer that certainly comes up. What is your feeling about their role and how it differs from either data science or software engineer?
Catherine Nelson 00:09:49 Many companies, I think it’s the data scientists that will make some initial explorations. Take a fresh problem and say like, is this even a problem that we should be solving with machine learning? What type of algorithms are suitable for this particular problem? Train an initial model, prove that that model is going to answer the question that’s under consideration. And then it’s the machine learning engineer that takes over when that has been established, when those initial experiments have been done and then puts that model into production. And then they look more on the side of monitoring that model, checking that it’s performance, checking that it returns, it’s the influence happens in the right amount of time and so on.
Philip Winston 00:10:37 How about at a smaller company? I imagine that people end up wearing multiple hats until you’re able to hire for all of these different roles. Have you seen that?
Catherine Nelson 00:10:47 Absolutely. And sometimes at bigger companies too, if the data science team is small, then one person might wear a lot of hats. That’s challenging because it’s a different mindset that you have for when you’re running an experiment and being very like open to trying lots of different things, versus you want to be in your production mindset where everything has to run repeatedly where it has to be very robust.
Philip Winston 00:11:13 Let’s specifically zoom in on the relationship between data science and software engineering. What motivated you to write your latest book software engineering for data scientists?
Catherine Nelson 00:11:25 A couple of things really. One is that it’s a book that I wanted to read earlier in my career as a data scientist. So a while ago I joined a team where I was the only data scientist on a team of developers, designers and so on. And I found it hard to just even understand the language that the developers were using. Like many data scientists, my education didn’t include any kind of computer science courses. I didn’t have that much familiarity with software engineering ways of working. When I started as a data scientist and I had questions like, what is an API? How do you build one? And I started getting interested in how I could write better code. And the books that were available, the examples were in Java or they were owned at web development. They weren’t very accessible to me writing code in Python and not needing to have all the skills and background of a web developer. And there’s also data scientists have a reputation for writing bad code and I wanted to help change that.
Philip Winston 00:12:36 I think you answered this. I was going to ask how much software engineering training do data scientists have? And I think you’re saying that on the lower end it can be more or less none, I guess.
Catherine Nelson 00:12:45 Yep. There’s a couple of main routes for people getting into data science. One is from a hard science background, often physical sciences or other science PhDs. So they have their data analysis, but they might be writing more academic code but doesn’t need to be particularly robust. Doesn’t need to be particularly well tested. And then another way is through data science undergraduate degrees or masters, which may include some level of growing courses. But there’s so many things to try and cover in a data science degree that don’t, it’s hard to do that in depth.
Philip Winston 00:13:26 From your book. Can you pick just maybe two skills that you think would be most beneficial for a data scientist to learn?
Catherine Nelson 00:13:35 One where I see there’s often a gap is in writing tests. That’s often something that’s not familiar to people from a data science background. And that’s because data science projects can be so ad hoc, so exploratory, it’s not obvious when to add tests. You can’t add tests to every single piece of code that you’re writing in the data science project because half of them you’re going to throw away because you found that that particular line of inquiry goes nowhere. There’s not really a culture of going back and adding those tests later, but if you then move on from that exploratory code to putting your machine learning model into production, it’s a problem if your code’s not tested. Another one is that, again, that comes from this exploratory nature. Often data scientists are reluctant to use version control when it’s just an individual project. It seems like it’s more hassle than it’s worth. It’s not obvious what the benefits of that are until you start working on a larger code base.
Philip Winston 00:14:35 What programming languages are commonly used for data science? I know Python is common to machine learning in general, but there is other more data science specific languages?
Catherine Nelson 00:14:49 I would say Python is the biggest data science language at this point. Previously R was pretty big as well, but the proportion is declining a bit. Some people use Julia, but it’s not received this widespread adoption that Python has.
Philip Winston 00:15:06 Those are the other two I had down here. R and Julia maybe tackling the same question from a different angle. What should software engineers keep in mind about working with data scientists?
Catherine Nelson 00:15:19 I think that data scientists will be coming from a different mindset than a software engineer. So they’re used to tackling very vague problems and turning those into more data-focused problems. And the thing with data science projects is that you often don’t know at the start where you’re going to end up. If you are working on a machine learning problem, you might find that the algorithm that you end up using is very simple or you might end up using something that’s very complex. You might start off with, say it’s a text data extraction problem, you might start off with trying a random forest-based approach with some very simple text features, but that doesn’t actually perform very well, but accuracy is low. Then you might move on to trying a deep learning model, seeing if that works any better. So this makes it hard to estimate at the start of the project how long it’s going to take or even what the final outcome is going to be. Is this going to be a large model, a two-gigabyte model where we’re going to need some specialized infrastructure to deploy it or is it going to be very small and it’ll scale very easily? So I think keeping in mind that uncertainty, and it’s not that the data scientist is just bad at estimating, that is the nature of these projects. It’s not clear what from the start, what the end is going to look like.
Philip Winston 00:16:55 I could imagine a scenario where the software engineers are eager to start deep into the implementation phase, but the data scientist hasn’t yet found the model for sure. And that might take some patience and some time to iterate before it’s ready for application.
Catherine Nelson 00:17:10 Exactly, exactly. Yeah, it’s not clear what that model is going to be.
Philip Winston 00:17:15 Let’s go through some typical machine learning workflow steps and explain from a data science point of view, what are some considerations, what’s the procedure or technique that might be used? And if we’re working with software engineers to create an automated pipeline, what are some things to keep in mind about this particular workflow step? Basically, what sorts of tools or techniques should we keep in mind for each step? So the first one I have down is data ingestion. So I guess there’s a lot of different projects, but what are some things we might be ingesting and what are we feeding it into?
Catherine Nelson 00:17:54 Yeah, this step is when you take your data from wherever it’s stored in your company’s infrastructure and feeding it into the rest of the pipeline, this is the point where you might also make the split into training data and validation data. It’s picking up that data from whatever format it’s stored in and then potentially transforming it into a format that can move through the rest of that pipeline.
Philip Winston 00:18:24 Can you give an example of unstructured or structured data?
Catherine Nelson 00:18:28 Yeah, usually we call text or images, unstructured data and structured data is data that’s in a tabular format so that the tabular data could be data about the sizes of companies that you’re considering or the unstructured data could be something like the text of the complaints that you’re trying to make a prediction from.
Philip Winston 00:18:54 So are there any specific tools that might come into play here, whether they’re standalone tools or libraries that are commonly used for ingestion?
Catherine Nelson 00:19:02 There’s a few different solutions for the entire pipeline that have a data ingestion component. TensorFlow extended is one of these. There’s also Amazon’s SageMaker pipelines, and I believe ML Flow has a similar structure, although I haven’t worked with that myself.
Philip Winston 00:19:24 The next step I have is data validation. You talked about dividing the data into training and validation sets, but that might be a different type of validation.
Catherine Nelson 00:19:33 Yeah, that’s right. So when you’re dividing your data into training and a validation set that’s used during the model training or analysis model or validation step to check whether that model is sufficiently accurate for the problem that you’re working on, data validation is checking that the data that you’ve ingested is what you expect. So some problems that you might have with that data could include there’s the data’s missing, something’s gone wrong upstream, and suddenly you’re getting null values in your data and then your machine learning model wouldn’t be able to train with those null values in there. So the point of the data validation step is that if there’s a problem with your data, you can stop the pipeline at this point rather than go through the lengthy training step only to find out that there’s an error at that point or your model isn’t as accurate as you’ve expected because there’s a quality issue with the data.
Philip Winston 00:20:35 Let’s pause for a second and talk about when we would rerun the pipeline or why we’re rerunning the pipeline. So if this was just a one-off exploratory investigation and we created a model and produced a visualization and that was the end, but in this case, we’re talking about building a pipeline. So when is it that we rerun this pipeline? Is it because we have new data? Is it because we’re trying to train a better model? Or what situations, and I guess related to that is do we rerun the entire thing or is it being able to rerun portions of it?
Catherine Nelson 00:21:07 So for many business problems, the data doesn’t stay static. The data changes through time, people behave differently with your product and so on. So that causes the model performance to degrade with time because if you’ve trained a model at a specific point in time, it’s been trained on that data and then as your usage pattern changes, then that model is not quite so relevant to that data. So the performance drops, that’s the time when you might want to retrain that model and usually, you’d want to run the entire training pipeline all the way through. If you just run part of it, you don’t actually change anything because the artifact that you get at the end of the pipeline that you’re going to deploy into production is that trained model on that updated data.
Philip Winston 00:22:03 So as part of validation, how do you measure data quality or under what situation would the data fail? Validation that might be specific to a project.
Catherine Nelson 00:22:15 Yeah, if you had some numeric data, then you would look at basic statistics of that data, like the mean, the standard deviation, you could look at the proportion of nulls in that data. If that goes up, that’s a signal that your data quality has decreased. If you are using text data, then it’s less obvious what you should check, but you could check the length of that text if something has gone wrong upstream, you might be getting empty strings coming through into your pipeline. So that’s something you could check.
Philip Winston 00:22:47 And what are your options if the data fails validation, is that basically signaling for someone to intervene or is there any automated step you could take to allow you to continue?
Catherine Nelson 00:23:01 You could consider rerunning the ingestion step if it’s something that’s gone wrong in that step, you could change the data that you are putting into that pipeline, but in general, it’s a kind of safety valve against the final model being incorrect rather than anything that you’d need to change automatically like that.
Philip Winston 00:23:22 That kind of raises the question, how long is this whole pipeline going to take? I’m sure it varies drastically by application, but in the systems, you’ve worked on, can you give me idea of the range of time that the full pipeline take? And the reason I ask that is because if we’re preventing proceeding with bad data, we’re saving this amount of time. And so I guess if the whole thing was very short, it wouldn’t be a big deal. But if the whole thing was long, then early out could benefit us a lot.
Catherine Nelson 00:23:52 The systems I’ve worked on, it’s usually been in the minutes to hours scale, so it’s not days and days, but the point is that ideally you would have this pipeline set up so that it runs automatically without any interference from myself without needing to do anything. So it’s more than being able to automate it from the start to the end than particularly the time saving. That’s important here.
Philip Winston 00:24:17 I think I might know the answer to this, but does the data have to be perfect or how can we judge how tolerant our pipeline is to bad data?
Catherine Nelson 00:24:26 I think that the data should be sort of reflective of the real world that it’s trying to model. So like if you have data about your customers, about a bunch of different companies, then that’s going to be very variable. One thing is that some machine learning algorithms can’t cope with missing data. So in that situation, all the values do need to be filled out and it needs to be perfect from that point of view, but it can have a very wide distribution and that’s fine.
Philip Winston 00:25:00 So let me read the next four steps so we have some idea where this is going and maybe what to talk about at which step. So I have next data, pre-processing, then model training, then model analysis and validation, and then deployment. So let’s talk about data pre-processing next. I don’t know if this is an official step or is this depend on the workflow, but I guess how is pre-processing different from the previous steps?
Catherine Nelson 00:25:27 Pre-processing is often synonymous with feature engineering, so that’s translating the raw data into something that you can use to train the model. So if your raw data was text, then it might be word frequencies or something like that. And that’s different from the validation step because in the validation step you are describing the data; you are checking that the data doesn’t contain nulls and so on.
Philip Winston 00:25:56 Has deep learning kind of eroded the necessity for feature engineering? I remember I worked on a project a long time ago and a huge amount of effort was put into feature engineering, and more recently I worked on something and they’re kind of saying that feature engineering kind of goes away in some cases. What has your experience been?
Catherine Nelson 00:26:18 Yeah, I think that’s right, especially, I’ve worked on a lot of text models and it’s become a lot better to put to not do much with the text, put it in pretty much raw, and have a more complex model that’s able to learn a lot more from that text rather than doing extensive feature engineering to extract those features from the text and then train the model. That seems right to me.
Philip Winston 00:26:44 Okay. Let’s move on to model training. How about this idea of training from scratch versus fine tuning an existing model? Are both of these possibilities in a pipeline?
Catherine Nelson 00:26:59 I’d say there’s actually three possibilities. There’s training from scratch, there’s fine tuning, and there’s retraining the exact same model on new data. Training from scratch, I wouldn’t do that in my machine learning pipeline. I would do that separately in standalone codes to get that model established the first time around, check that it is actually accurate enough to solve that problem, then I would build a machine learning pipeline only when I knew that I had that model and was going to be retraining it. Fine tuning you can certainly do within the pipeline because you might want to tweak the hyper parameters of that model when there’s new data. So you might want to have a small step within that.
Philip Winston 00:27:45 You mentioned hyper parameters. I was wondering when you say have the model and then retrain it, what is the model at that point? Is it all the parameters associated? I guess what would be part of the model that then gets retrained? What stays?
Catherine Nelson 00:28:01 Yeah, that’s a great point. Sometimes it’s the model architecture and those hyper parameters, and sometimes it’s just the model architecture. So if you’re in the neural network world, then the number of layers in that model, the types of layers in there, how they’re connected, that’s probably going to stay static because changing that up within a pipeline is hard because you don’t have quite such instant feedback on whether the model is working as you do in a separate piece of training code that’s just designed to run through those experiments. You’ve got a lot of other code around that model that makes it a little more complex to debug them.
Philip Winston 00:28:47 You mentioned the duration of the pipelines you’ve worked with range from minutes to hours. Is most of that time in the model training?
Catherine Nelson 00:28:56 Yes. Yeah, that’s right. Usually the other steps are shorter and it’s the model training that’s the long one. So that’s why it’s important to have those other steps separate so that you know that your data is in good shape by the time it gets to the time-consuming training step.
Philip Winston 00:29:14 Another element of time would be how long we’re going to use a model before retraining. How does that vary? I think very early on, I imagine people used models for a long period of time and more recently I feel like people are retraining more and more often. Is that a trend?
Catherine Nelson 00:29:36 Yeah, I think from what I’ve worked on that depends on the maturity of the use of machine learning in that organization. So early on you might have built these models fairly ad hoc, and then it’s a big effort to deploy them into production. But when you do that, it makes a big step change in the accuracy of your product. Whereas as time goes on, you are making smaller improvements in your product, but you want to make that more frequently. So having that pipeline set up allows you to change your model often as the input data changes. So yeah, I think that’s why you’re saying that.
Philip Winston 00:30:19 I guess taking a step back for a second, during all of these steps of creating a pipeline, in what cases are we able to just hand this over to software engineers and kind of give them the information about the model? And in what cases do you feel the data scientists needs to be involved? What’s the trade off from either a handoff situation or a collaboration like side by side situation?
Catherine Nelson 00:30:44 Part of this is going to depend on the team that you have, and the skillset sets available, but I would say it’s very useful to have the data scientist involved in setting up the initial pipeline. In particular things like what are the criteria for the data validation step, what is a sensible distribution of your data, what are the hyper parameters that you should be considering when you’re training the model? And particularly in the step that we haven’t talked about yet, which is the model analysis step. I think that’s where the data scientist has a really crucial part to play. I think any data scientist can learn the skills that they need to deploy a pipeline, but often being able to debug that complex system, being able to set it up so that it interfaces with the rest of the product, making sure that it’s well tested and so on. That’s where a software engineer can add so much value here.
Philip Winston 00:31:46 I’ve worked with many scientists unrelated to data science, but just sort of a, you know, biologist or physicist and yeah, they can learn to code as just part of their education or sort of on the side, but then there are certain skills that they don’t have as much experience in. But I definitely feel that many people end up learning to program by necessity. And I think that’s a good thing for the most part.
Catherine Nelson 00:32:12 And for me it’s also because I enjoy being able to write better codes. It’s a lot of fun being able to do this well and write code that’s robust and scales and so on.
Philip Winston 00:32:22 You mentioned model analysis and validation, that’s the next step. So because the word’s the same, how is this different from a data validation? I guess it’s a question of what are we validating?
Catherine Nelson 00:32:34 Yeah, so this is where we are looking at the performance of the model in terms of how accurate it is, what’s the precision and recall, and also sometimes splitting that accuracy down into finer grained sectors. So if you had a model that you were deploying in lots of different countries, does it perform equally well on the data from all those countries? That’s something that you could do with your validation data, which is the split of your data goes into the training data and validation or test data. And I know that we’re using the word validation way too many times in this, but that seems to be the way that the terminology’s gone. So analysis is looking at that accuracy across different aspects. This is a point where you might look for bias in your model as well. Is it providing better performance for certain groups? Is it providing better performance on your female users versus your male users? That would be something you’d want to look for at this step. And then the validation part of that is the model should only be deployed if it is acceptable in all the analysis criteria. So this is kind of your final go or no go step before you deploy that model into production setting.
Philip Winston 00:33:56 I wanted to flag the term precision and recall. We’re not going to try to go through all that, but I’m guessing that relates to false positives versus false negatives.
Catherine Nelson 00:34:05 Yes. And a classification problem. That would be some of the metrics you’d look at.
Philip Winston 00:34:10 And when you say deciding whether the model is good enough, the reason we might want to make that decision is maybe we have a previous model that was pretty good already and we don’t want to make it worse.
Catherine Nelson 00:34:21 Exactly. That’s exactly right. So you’ve taken the same model and retrained it on new data. Does it perform better as a result of this?
Philip Winston 00:34:30 How about overfitting versus generalization? I don’t know if those are too technical, but can we just give an idea for what those have to do with the model analysis?
Catherine Nelson 00:34:40 This is where if you have overfit your model, then you’ll see a higher accuracy on your training sets than on your validation set. And then you’ll know that your model is too closely replicating your training set and it’s not able to generalize to new data. And what you want it to be able to do is exactly generalize it to new data when you’re deploying it into production.
Philip Winston 00:35:07 This might be a naive question, but is the size of the model unrelated to the amount of training data you have, or does the model size grow? Depending on the dataset.
Catherine Nelson 00:35:19 If you have a small dataset and a large model, then it’s very prone to overfitting because your model is basically able to memorize the data that you have, so then it might perform not that great on when it sees new data. Yeah, yeah, that’s a good question.
Philip Winston 00:35:38 And I have this down as interpretability. I don’t know if that’s really part of this step, but I guess that’s a element of a model, whether you really understand what it’s doing or whether it’s sort of a black box?
Catherine Nelson 00:35:51 Yeah, that’s definitely part of model analysis, but it’s probably not something that you, you might not put this in the pipeline because for models where there’s like you need to explain it, that’s almost the opposite of automating the problem. If you need to look very carefully into what features are causing it to make a certain prediction, you can’t really do that as part of an automated setup that’s going to deploy a model as soon as it’s trained. You got to take that step back. If you needed to interpret your model, you might run the pipeline up to this point, but then maybe this is where your data scientist steps in to really take a good look at that model and then it’s a manual step to deploy it to production.
Philip Winston 00:36:41 That also kind of raises the point, maybe if we have a large team, we’re working on building this pipeline with the involvement of data scientists and software engineers, but then maybe there’s some other data scientists working on sort of a next generation model or something like that so that these things could be happening in parallel. It’s not like we just drop everything and build a static pipeline.
Catherine Nelson 00:37:04 That’s right. Yeah.
Philip Winston 00:37:06 So let’s start talking about deployment at this point. We have a pipeline; we can run it hopefully with minimal intervention. Hopefully it runs kind of straight through. Maybe it retrains with more data. What is different about deployment or maybe production? And I’m sure it varies based on the project, but in general, kind of what is this transition from. I have a pipeline I can run to, it’s been deployed, which maybe means it’s running at a larger scale or it’s running more often.
Catherine Nelson 00:37:41 Yeah, this is really the point at which I kind of hand off my tasks to the software engineers as well. The pipeline produces a model artifact, which can be a saved set of model weights and so on. And then that’s when that model gets handed over and is set up to run inference. So that’s really the point at which the data scientistsí job is done. That newly trained model has been produced and now it can be put into the product so it can provide the service that it’s planned to do.
Philip Winston 00:38:14 How does scaling enter into the equation here? Is it possible that our model is too large or too computationally intensive that we can’t put it in production? Or is that something you’ve thought of from very early on? Is there sort of a point here where we have to decide if we can even deploy this?
Catherine Nelson 00:38:35 Ideally you would know that before you have started building the pipeline, because a lot of what affects that will be the model architecture, the number of layers, the size of the layers if you’re dealing with a neural network. So ideally you would want to know what some of the requirements are for inference at the experimentation stage when you’re trying out lots of models. Because if you need your model to be extremely fast, you might limit yourself in those experiments to models that are small and fast.
Philip Winston 00:39:08 This might apply to all the steps, not just deployment, but what is your opinion on heavily refactoring and evolving the initial sort of pipeline versus rewriting or having a sort of clean start when you’re implementing the pipeline?
Catherine Nelson 00:39:26 A lot of the pipeline solutions, like TenseFlow extended or Amazon SageMaker pipelines, they will take as inputs scripts like your training script. So you don’t necessarily have to rewrite, you can just kind of pick up the code that you’ve used from training and drop that into the pipeline code. That works pretty well because you already know that that’s working. You don’t have to completely rewrite from scratch. But a lot of the boilerplate around code around the pipeline is that’s new that’s coming up from scratch to actually link those pieces together and make sure that one step goes to the next, to the next and so on.
Philip Winston 00:40:10 One role we didn’t talk about at the start was MLOps, which I guess is an offshoot of DevOps that’s more specific to machine learning. Do you have any experience with sort of what could go wrong in deployment that maybe is special to machine learning? So in regular backend work, there’s certain problems that crop up. I’m wondering if there’s any machine learning specific. Maybe it has to do with monitoring the inference time or the memory used or something.
Catherine Nelson 00:40:40 So one problem that I have heard about, but not the experience myself, is called training and serving SKU. And what this is, is when you might have feature engineering code and model training code, and you need to do that feature engineering when your model is deployed and running inference as well as when you’re training the model. So what you might do is update that feature engineering code in your training pipeline, and then train a model based on those particular features, and then deploy that model and forget to update the feature engineering code. So when your model is running inference, the data’s coming in, it’s getting the old feature engineering, but the new model. So the data might be completely valid after it’s had that feature engineering step. The features might be completely valid, but they aren’t the right distribution for that particular model. So your model performs worse and you’re not quite sure why. So that’s a subtle one that can come up.
Philip Winston 00:41:49 Yes. That does sound like very machine learning specific debugging where yeah, the behavior of this model that we validated and analyzed is not where we thought it would be. And maybe we have to roll something back or maybe, we have to fix it.
Catherine Nelson 00:42:06 So it’s good to have monitoring in production to be able to sniff out these kinds of things to check that the model accuracy is what you expect.
Philip Winston 00:42:15 Okay. It sounds like we did all the steps of the pipeline. Let’s start wrapping up. We talked about different roles throughout this episode. Do you see any new roles on the horizon or roles that you think are changing or becoming more prominent?
Catherine Nelson 00:42:33 Yeah, I think there’s a couple of things here. Now that I’ve started working on generative AI solutions, AI engineer is the obvious one. Someone who’s not necessarily building the model or training the model that is designing applications that are based on AI models, that’s huge. And that’s only going to continue to grow as well. The other thing I see is that I think there’s a big place for data scientists in the world of AI and that’s making sure that that’s in evaluating AI models. So if you are trying to use an LLM for some particular business application, it’s actually very hard to check how accurate that model is. So I think that’s a huge growth area for data science.
Philip Winston 00:43:23 And again, I think, yeah, when we say AI engineer, we’re talking about people working with foundation models of some type. It could be LLM or not. Maybe they’re just working through an API, and they don’t run any machine learning locally at all. I guess in some cases they’re programming, you know, in English writing prompts and things.
Catherine Nelson 00:43:44 Yeah, I think that’s going to be huge in the future, and it already is huge right now
Philip Winston 00:43:49 We try to focus on collaboration. Moving beyond just the software and machine learning, what collaboration methods have you found been useful between data scientists and software engineers or other members of the team, whether it be a tool or just a technique that you find is helpful?
Catherine Nelson 00:44:07 I think the best way of collaborating is having a team that’s open to ideas. It doesn’t speak really to any tools or techniques. It’s all about valuing each other’s ideas. And the best teams I’ve worked on for that have been where people are very supportive of each other and supportive of those, of someone bringing in new ideas. That seems to me to be the key rather than any particular tool or piece of software.
Philip Winston 00:44:38 So continuing to wrap up, what are you excited about looking ahead in machine learning projects you’re working on or that you see in the wider industry?
Catherine Nelson 00:44:47 So having relatively recently started working with LLMs, it just makes me so just so blown away by the capabilities at the moment. I’ve been working on a project to showcase a good example of a use of an LLM for a startup and I’m working with, and the project we decided to choose was extracting people’s flight details out of an email. So you send the servers an email with your flight details, and it will extract the origin, the destination, the time of departure, time of arrival, and so on, and populate those into whatever kind of app you want to work on. And I’ve worked on similar projects before and seen things like big piles of regular expressions or doing all this complex feature engineering to get this out of it, but now I can do it in a five-line prompt to open ai and it works better than all those previous incredibly complicated solutions. And you can even do things like you can ask it for the airport code instead of the name of the city, and even if the airport code isn’t in the email, you can still get that because the LM has that context. So I’m just really excited about what we’re going to be able to do with these things in the future.
Philip Winston 00:46:11 Yeah. I guess that leads to the question at the end of a project, all the technical successes there, but what is the business value and sort of what, in the projects you’ve worked on, what are they doing sort of for the next version? Is it usually kind of doubling down on techniques or is it tackling a completely new area of the business? Or like what are the possible directions at the end of a project?
Catherine Nelson 00:46:34 Yeah, so some of the projects I’ve worked on, it adds a new feature that wasn’t possible without machine learning. And a lot of these have been extracting information out of unstructured data, and that gives you the capability to add something that you didn’t think you were going to be able to do, offer some new feature to your customer, and then you know, you might spend some time optimizing that so that the accuracy improves and so on. So I think, yeah, it’s a balance between improving these existing models, improving the accuracy, and then the step change of adding a completely new feature.
Philip Winston 00:47:09 Okay. Where can listeners find out more about you or your new book?
Catherine Nelson 00:47:14 Best place is to follow me on LinkedIn.
Philip Winston 00:47:17 Okay. I’ll put your handle for your LinkedIn name in the show notes. Thanks for talking to me today, Catherine.
Catherine Nelson 00:47:25 Thanks, Philip. It’s been great talking to you.
Philip Winston 00:47:28 This is Philip Winston for Software Engineering Radio. Thanks for listening.
[End of Audio]
Jonathan Horvath of Z-bit discusses physical access control systems (PACS) with host Jeremy Jung. They start with an overview of PACS components and discuss the proprietary nature of the industry, the slow pace of migration to open standards, and why Windows is commonly used. Jonathan describes the security implications of moving from isolated networks to the cloud, as well as credential vulnerabilities, encryption using symmetric keys versus asymmetric keys, and the risks related to cloning credentials. They also consider several standards, including moving from Wiegand to the Open Supervised Device Protocol (OSDP), as well as the Public Key Open Credential (PKOC) standard, and the open source OSDP implementation that Jonathan authored.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes* Z-bit * OSDP.Net * ONVIF Profile C * Wiegand Interface * Open Supervised Device Protocol (OSDP) * Public Key Open Credential * How Hackers Extracted the “Keys to the Kingdom” to Clone HID Keycards * Flipper Zero
Cody Ebberson, CTO of Medplum, joins host Sam Taggart to discuss the constraints that working in regulated industries add to the software development process. They explore some general aspects of developing for regulated industries, such as medical and finance, as well as a range of specific considerations that can add complexity and effort. Cody describes how translating regulatory requirements into test specifications and automating those tests can help streamline software development in these regulated environments. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show NotesRelated Episodes* SE Radio 523: Jessi Ashdown and Uri Gilad on Data Governance * SE Radio 571: Jeroen Mulder on Multi-Cloud Governance * SE Radio 342: István Lam on Privacy by Design with GDPR
TranscriptTranscript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact content@computer.org and include the episode number.
Sam Taggart 00:00:35 This is Sam Taggart for SE Radio. I’m here today with Cody Ebberson to talk about navigating regulated environments. Cody is a co-founder and CTO of Medplum, a developer platform that provides tools for security, interoperability and compliance in the healthcare sector. Cody began his career as a software development engineer at Microsoft over 15 years ago and has since held various roles in a variety of healthcare related tech companies such as director of engineering, COO and CEO. Welcome.
Cody Ebberson 00:01:01 Thanks Sam. Happy to be here.
Sam Taggart 00:01:03 Yeah. So we’re going to talk about regulated industries. Why don’t we start by just defining what we mean by regulated industries?
Cody Ebberson 00:01:09 Yeah, it’s a great question. I think it applies in quite a few different places. Typically, people think of it as, I mean, everywhere has regulations, but when we think of excessively regulated or high regulation, it’s places like healthcare or finance or security where there’s quite a few additional layers of requirements to make sure that you’re meeting legal requirements, ethical requirements, you’re protecting user rights, user data, user safety, and they’re all over the place. And I think there’s regulation everywhere, but maybe there’s a spectrum of some that are more or less regulated.
Sam Taggart 00:01:40 Yeah, I was going to say a lot around financial stuff I imagine and personal information and those type of things as well.
Cody Ebberson 00:01:47 Absolutely, yep. Certainly compared to something like video games where, it’s fun, but when you’re talking about financial data or healthcare data, I think people have a higher expectation of reliability and security.
Sam Taggart 00:01:57 Yeah. So who makes these regulations? Like where do they come from?
Cody Ebberson 00:02:01 That’s a great question. It’s typically a government or an industry standards body. So in our case, we’re primarily in healthcare. It’s usually originating from healthcare government bodies like HHS, Health and Human Services. And they provide a whole bunch of different regulations. Most famously HIPAA, but there’s quite a long list. There’s also quite a few industry standard bodies and customers will often dictate those. So where the government might not fully regulate something, the market ends up filling those as well.
Sam Taggart 00:02:30 Is that like the, what is it, PCIS or the credit card?
Cody Ebberson 00:02:33 It’s finance. Yeah, PCIS. Like SOC 2 is a big one to make sure that you have adequate data and security controls and those are typically driven by the market.
Sam Taggart 00:02:42 And what are these regulations generally trying to prevent?
Cody Ebberson 00:02:45 I think there’s a lot of it that’s, you might hear about it and think, well that’s kind of common sense, right? Like that the user’s data is being adequately protected, that you have sufficient controls to make sure that like a rogue software engineer can’t go and steal data or do something malicious. That it’s protecting the user’s data to protecting the user’s safety on the ethical side, not that you can truly regulate ethics, but trying to codify those in into systems so that the software is going to be reliable. I mean I think the CrowdStrike attack from what that last week was or two weeks ago, was a notable one of there was a lot of damage that was financial damage, human time wasted. Those regulations are often put in place to try to protect against incidents like that.
Sam Taggart 00:03:27 So how do regulations vary over geography and what challenges have you run into with that?
Cody Ebberson 00:03:33 Thatís a great question. Regulations are often quite different cross-country boundaries. The US healthcare system is perhaps one of the largest healthcare systems. It has its own idiosyncratic regulations, but there are quite a few that go across international boundaries as well. For example, sometimes there’s data format requirements and there’s regulations to try to improve interoperability across those different systems. There is a push from the ISOs so there are many of these ISO standards now which are an attempt to try to standardize and regulate as an international standards body. There’s a long list of the ISO standards and the US government is oftentimes steering into those to align with like the rest of the world.
Sam Taggart 00:04:14 So in the US we have the federal government, we also have state governments. Do you notice any differences between states that apply to healthcare in particular since that’s your area?
Cody Ebberson 00:04:23 There’s definitely a lot of state level requirements for the practice of medicine, so on doctors and nurses and the variety of different rules. As a healthcare provider with regards to healthcare technology, the rules are typically pretty similar. One thing that’s interesting for healthcare is there’s the notion of an HIE and Health Information Exchange, which allows regional hospitals to share data with each other. And you can kind of think of those like a homeownerís association where they have all their special rules that define who can share what data between different hospitals. And that’s very, very regional, but not typically so much from the state at that point. It’s typically going to be the market driving those rules.
Sam Taggart 00:05:01 So have you ever encountered regulations that are at odds with each other and what do you do in those situations?
Cody Ebberson 00:05:07 That’s a great question. In healthcare, a good example of this would be the US government involved. A lot of governments are now pushing the right to be forgotten, for patients to be able to request their data to be deleted and purged and which is a very sensible consumer protection. But then on, if you think about the medical legal liability requirements where you have to retain many of your records for seven years and up to 18 years in some cases. So now you have to retain records for legal purposes. And those two are totally at odds with each other in practice. Those don’t come into conflict very often. And when they do, that’s when you call up your lawyers and try to figure out how you’re going to handle that. Putting data into vaults or escrow or trying to semi anonymize data. It’s often a long and complicated process, but when the conflicts come, you typically get the lawyers involved.
Sam Taggart 00:05:53 Yeah, I was going to say, I would imagine if you told your doctor you were allergic to something, you would probably want him to remember that.
Cody Ebberson 00:05:58 Yes. Or if you had a surgical operation and the statute of limitations on how like the process of suing for a complication can be available for up to seven years. But if you want to have your data deleted, like how do you reconcile those things?
Sam Taggart 00:06:12 So have you noticed similarities across different industries and what are some of the common requirements?
Cody Ebberson 00:06:18 Yeah, absolutely. And that’s where, so SOC 2 is a big one that’s very cross-cutting and there’s a lot of common-sense things in there. Sometimes it’s difficult to operationalize, but it can be common sense of making sure that you have like you’re using SSL or TLS on all of your cloud endpoints and that you have adequate data protections. So those are cross-cutting. And then it certainly, if you’re going to do any work with the federal government, then you have something like FedRAMP, which is kind of the gold standard of all regulations and it’s going to make sure that you’re running continuous security training, you have all your security audits, your pen tests on a regular basis. You have to demonstrate that you can respond very quickly to security vulnerabilities or changing security requirements. And that’s not industry specific at all. Anytime you want to work with a federal agency, you have to make sure that you’re conforming with those requirements. And now the market has adopted those rules in some cases as well. So even if you’re not working with the federal government, you may need to say, okay, yes, we’re FedRAMP compliant.
Sam Taggart 00:07:16 Okay. How do these regulations affect developers? How do they translate down to the code level?
Cody Ebberson 00:07:22 Absolutely. That’s a great question. And I think that there’s the surface level knee-jerk reaction that most software engineers have, which is gross. I don’t want to deal with that, right? It’s going to be a long slog, a lot of complicated, boring requirements. I think that there’s a more positive interpretation, maybe this is my personal bias, I actually personally kind of like them because I view them as just a very clear and explicit bright line set of constraints. And software engineering often is about working with constraints and using constraints to define project specs and specs, translating into feature requirements and feature requirements translating into code. So for example, our organization, we’ve made it one of our core competencies of taking those rules and regulations and translating into unit tests, translating into integration tests so that every time we run our CICD pipelines we’re going to know very clearly like this change break or violate one of those compliance and certification programs.
Sam Taggart 00:08:18 Do you have a specific example?
Cody Ebberson 00:08:20 Yes. So everything inside of our SOC 2 that we can translate into CICD checks, we have a lot of those would be mostly on data privacy and protections, like things like access controls. I think most systems inevitably have a gazillion checks for permissions and access controls, making sure that various groups can only access the data that they’re supposed to have access to, et cetera, et cetera. So there’s things like third party tools here as well. So things like we use Sonar Cube for a lot of our automated testing, which will run through a huge battery of security tests. Mozilla Observatory, that’s a great one for all of the like HTTP and TLS and SSL endpoints. All of those tools are great and we try to run them in an automated fashion as much as possible.
Sam Taggart 00:09:04 So that brings me to another question. So when things go wrong and somehow one of these regulations gets violated, where does the liability typically lie? Does it ever lie directly with the developers or is it more of a company level thing or how does that work?
Cody Ebberson 00:09:16 Yes, it can lie with the developers and so that makes us very keenly aware. It makes you sit up straight and pay attention. I think that there’s typically like a remediation period and then there’s an ongoing investigation to figure out how did this go wrong, why did it go wrong? And they do try to look at intent and with what level of seriousness were you operating. And if it’s gross negligence, then that’s where the really big penalties and the big fines come out. If it’s something that was like a very deep and complicated edge case that then there’s maybe a little bit more leniency in those situations. But typically a government agency will roll up their sleeves, dig into what happened and try to make that type of assessment before levying fines and penalties.
Sam Taggart 00:09:58 So something that just popped into my head is how do you balance, and maybe this isn’t a question for you, but just curious if you’ve seen it done balancing the desire for people to actually report incidents so that everybody can learn from them versus if you smack people really hard, they’re going to be reluctant to disclose some of those incidents?
Cody Ebberson 00:10:17 Yeah, the first thing that comes to mind there is like the security industry at large in the culture that exists there of things like bug bounties. And I think that that’s been very fascinating to watch over the last 10 or 20 years how that’s evolved because I think that for a long time, software developers and software organizations generally wanted to swat those people away. If someone came to you and said, hey, I think I found our vulnerability, the first thing you’d want to do is try and shut them up and make them go away. And what I think the industry has found over time is that you should welcome those, you should invite those people and make sure that you have a responsible disclosure program so that the issue can get fixed in a timely fashion. So I think that that has evolved nicely and has done very, very well with regards to like how government agencies enforce this.
Cody Ebberson 00:11:04 It’s perhaps a little bit less mature because it happens less frequently, it is done on a somewhat case by case basis for sure. Certainly in the cases of the kind of gross negligence, there have been cases in the past where there’s just like an open FTP server accessible on the internet where you can download lots of patients’ data and it was just security through obscurity. There was, if you knew the IP address you could just log in and grab a bunch of data. That’s pretty bad. And I don’t think they hold back at all when it comes to penalties and fees and fines. But if it’s you were using outdated encryption library and in like an old version of SSL that had some long tail vulnerability, I think that they’re generally pretty forgiving and understanding in those situations.
Sam Taggart 00:11:45 Great. So what are some of the challenges that you’ve seen complying with regulations?
Cody Ebberson 00:11:53 I think there’s just often like it feels like a large body of work associated with it, right? You sometimes you get the packet and so okay, we’re going to start up a new compliance program for a new certification or we have a new customer that’s based in Europe and now we need to figure out how to make sure that we’re meeting all the requirements for the EU or for Switzerland or whatever. So you typically, there’s a variety of vendors that you’re going to work with who may or may not have automated tools. If you’re lucky there’s a high degree of overlap with some of your existing compliance programs. If you’re unlucky, that could be hundreds of pages of very technical and dry legal documentation that you just need to start going through and translating into product and feature requirements and process requirements. And that’s just, it’s a form of work, but it’s also, that’s part of the value proposition of the industry too. So it’s definitely a challenge. I’d say, if you think about the umbrella of software engineering, we often think about challenges as being hard technical problems, but more often than not, I think software engineering is working with process problems and cross-functional coordination problems and compliance certification is just another layer of that. It’s another kind of role, another party in the room with your compliance and security folks and just making sure that all of those requirements are represented.
Sam Taggart 00:13:09 Okay. Yeah. My next question that popped into my head was the process for taking these regulations and figuring out like how we have to implement them in the software? How does that work? Is that mostly the security people or the compliance people making those decisions or are they doing it with the developers? Are they just pushing it off, the developers being like, you got to comply with this? How does that work?
Cody Ebberson 00:13:28 Yeah, that’s a great question. It’s a little bit of all the above. There are some that are just global, you just have to do it, right? In our case, in healthcare, HIPAA, it’s just kind of like it’s table stakes. And so you have to pretty much have that as part of your process on day one. I think SOC 2 is kind of becoming at that level. Is it becoming a table stakes certification that you just pretty much have to start it and do it. In other cases it might be at the time that you’re evaluating some new like business opportunity, a new customer, a new sale, or moving into a new market. And then it’s perhaps a little bit more of a cost benefit analysis. the lawyers and the compliance team will be in the room and part of that conversation, but you can boil that down to a dollars and cents pros and cons analysis.
Cody Ebberson 00:14:11 Then there’s the as these regulations are not static, they change over time and new rules can get added. And so typically every year or so the rules may change and you have to recertify or go through an audit again. That always happens as well. And in that case it just depends. Sometimes it is a long process of sitting down and translating requirements. There’s some, I will definitely give a shout out to various US government agencies that have now started publishing automated testing tools. So for example, Health and Human Services has started publishing some of their tools. So you can actually take your public HTTP API endpoints and plug it into some of their automated tooling and they’ll run their battery of tests against your publicly accessible endpoints. And that’s a fantastic way to do it. It takes a lot of the guesswork out of it. It takes a lot of the legal costs of pouring through boring documentation, but that’s still relatively rare. I think it’s a great model for the future, but whenever it happens it’s fantastic.
Sam Taggart 00:15:06 Yeah. One question I had was kind of how you maintain it over time. Do the agencies publish when they change regulations? Is it your responsibility to constantly stay up on that? How does that work?
Cody Ebberson 00:15:18 They do publish new versions and technically yes, it is our responsibility to stay on top of all that. And as we recertify, that’s on us. Most of the certification programs there is like an audit step and so there’s approved third party auditors that will go through your product and all of your documentation, all of your policies to make sure that you’re up to date and you’re in compliance. In practice, most organizations will use a security tool or provider. So for example, Vanta is the big player in this space. There’s quite a few other competitors as well who they provide automated tooling that will scan your environments, like actual agents that will run inside your cloud environments or agents that will run on your servers inside your private networks to ensure that this whole battery of checks is actually being met. Then they’ll turn around and produce a lot of that documentation for you. It doesn’t produce a hundred percent, maybe 80 or 90%. So it does a lot of the work, but ultimately as a provider, our organization is still responsible. It’s still our but on the line to work with the auditors and make sure that all of their requirements are satisfied.
Sam Taggart 00:16:23 So you mentioned cost earlier, do you have any idea how much costs the regulations add? And then as an add-on to that question, have you ever run into situations where you’ve had to cancel a project due to cost or do you usually figure out a way to pass that onto the customer? How does that work?
Cody Ebberson 00:16:39 Okay, well one at a time, an approximation of cost is kind of tricky and I think that it does change depending on the size of your organization as well. But, it’s easily measured in the cost of like full-time employees. So it’s a non-trivial cost for sure. But it’s I guess part of the cost of doing business for working in the space with regards to how customers, like the easiest maybe example would be you’re going to move into a new market and in particular going into Europe or like Australia, these are countries that often have very strict data sovereignty requirements and their domestic government agencies will have their own requirements. And then yes, at that point it usually is a costing exercise to go through the requirements and try to make a guesstimate of like both time, money, engineering effort, what’s it going to take. Sometimes you can pass that on to the customer. That’s usually part of the overall like enterprise deal negotiations and it’s kind of a mixed bag where that’s all going to net out. I think most organizations that becomes more of like a strategy question than a technical question of like, is this market, is this geography important to us and do we think it’s worthwhile moving into it? If it’s you, you go for it.
Sam Taggart 00:17:47 Okay. So bringing things back to developers, how can developers be quote ìagileî for whatever that means anymore and maintain velocity in regulate environments? Yeah. Do you have any specific examples of that?
Cody Ebberson 00:17:59 I think it comes back to that idea of constraints and there is this popular perception that compliance certification and regulations is like slow. And I would maybe try to reframe that just a little bit, which is, it can be slower to start, but I personally believe after years of doing this that going through that initial pain of building out all those unit tests, all those integration tests to take all those regulations and translate that into product requirements and translate that into infrastructure, it’s technical, it’s going to run on every build or every deployment. I actually find that if you’re willing to kind of pinch your nose and power through on that, that it, you end up in a place where you actually have very, very high velocity because you now have all these systems in place in an automated fashion and you can ship with confidence, you can build, add new features with confidence, you can refactor with confidence that over time that is like the truest form of velocity that you can as you grow and scale you can ship faster and faster. And that just gets back to, and I think that there’s an element of just software engineering best practices there of making sure that you have your product requirements represented with some form of automated testing so that it doesn’t have to be a big manual effort. It doesn’t have to be a big legal or compliance push that your tools and your processes and your systems are the ones that are really keeping you accountable over time.
Sam Taggart 00:19:18 So you mentioned requirements. What happens when the requirements change? And along those lines, do you separate out product requirements from compliance requirements?
Cody Ebberson 00:19:29 We use a variety of techniques to try to stay organized within that realm. So there’s a very high degree of overlap between those two. As you can imagine, we use a combination of a code organization putting various compliance packages into just different folders or different packages or modules with our documentation and issue tracking, we use various like sub-projects or tags to represent all the different compliance and verification programs. Some of the programs are, are more specific on this point than others. For example, I’ve gone through FDA medical device before, that’s a whole separate process for clearing a medical device. And the FDA has a set of requirements regarding, they call it the traceability matrix. So for any given feature than you have to go and make sure that you’ve identified and iterated all the potential risks. And for every one of those single risks you need to make sure that you’ve iterate through all the different tests that you can use to try to mitigate those risks.
Cody Ebberson 00:20:26 And you have to have a full tagging system that connects every single one of those concepts. And that has to be represented both in your documentation but also in your processes and in your code. So our current product is not FDA regulated, but we’ve tried to take a lot of those same concepts and apply it to our processes just because once you get over the initial hump of doing all that work, then you end up in a good place where you have all that infrastructure, those systems in place, but you can really crank through the documentation and you can add new programs and new certifications relatively quickly.
Sam Taggart 00:20:57 It’s interesting you mentioned traceability matrixes, because that was going to be my next question because we used to do those in the nuclear industry a lot.
Cody Ebberson 00:21:04 Yes. It’s daunting when you first see that, right? I mean I remember as I was first entering healthcare and first encountering FDA and you kind of get those packets of regulation, it does kind of hit you in the face with, whoa, this is going to be a lot of work. But I do believe that if you can power through on it, it creates a lot of value and both like financial value for your organization, but just also technical value in terms of really maturing and leveling up processes and systems.
Sam Taggart 00:21:33 Yeah, I think you built a lot of tooling around that pretty quickly. because otherwise I think you would be hating life.
Cody Ebberson 00:21:38 . Yes, yes. You would need a lot of manual effort to go through and try to reverse engineer all that documentation and all those requirements.
Sam Taggart 00:21:45 So what role does, CICD play in all of this?
Cody Ebberson 00:21:48 We’re big believers in CICD and we have embraced that since day one so that on every commit it’ll go through the battery of tests and if it satisfies everything it rolls straight out to production. And so we deployed dozens of times per day. That is per, it’s not required anywhere. And I still think that it’s probably not quite the norm, especially in healthcare just yet. It’s changing. I personally believe that CICD is a huge role to play if you’re willing to go through that pain of translating all those requirements into the test. And that is work for sure and I don’t think there’s any shortcuts there, but it’s trending in a good direction.
Sam Taggart 00:22:23 So do you find you’re generally able to make those tests reusable across projects or are they specific to a project?
Cody Ebberson 00:22:28 Certain tests, yes. Like anything where it’s like, oh this is an HGPN point, therefore it has to meet all these big basic security requirements. And that generalizes really nicely across the board when you get into the more nuanced and like feature specific then maybe not some of the data requirements with regards to like mandating and requiring sort of like data formats. So if like in our world in healthcare things like HL seven and FIR are very common as standard and required data formats and data representations that those become all of our schema validation and object validation data type validation, all that is very deeply ingrained in all of our tests. And so that applies across the board. So that’s another good one.
Sam Taggart 00:23:10 Good. So I’m personally a big fan of testing development and this idea of like emergent or just in time design, do you find that the regulations force you to do more design upfront or are you able to kind of design as you go or how does that work?
Cody Ebberson 00:23:23 So our team includes mostly experienced industry veterans. And I think that after being in the space, you develop some scar tissue, and you develop a strong desire to do some of that work upfront to make sure that your systems are going to support it. It’s like you’re laying the foundation of the house, you want to make sure that you’re building on a rock-solid foundation, the kind of evolving nature of requirements or oh shoot, we need to add a garage to the side of the house, and we didn’t have a foundation or didn’t, there was no concrete there. Like that never feels great and it feels like you have to do this mad dash and lots of like organizational refactoring and code refactoring and project refactoring. So that doesn’t feel as good. I think that when we do embrace it and we know our list requirements upfront and we can plan accordingly to have everything properly organized, it definitely gives a better sense of security and sustainability as you think about the future and ongoing growth of the project.
Sam Taggart 00:24:17 Yeah, that just brought up an interesting thought in my head for some reason, and that is if you have multiple groups working on different parts of a project, how do you coordinate between them and how do you make sure that they’re all staying in compliance and that like the workflow between the groups stays in compliance? I would think that would be a challenge.
Cody Ebberson 00:24:34 And I think that one of the hardest parts of any software system to test in an automated fashion is like your contract testing or boundary testing, right? And that’s not even so much a unique challenge to regulated environments. That’s just a hard software engineering challenge. And I think what that comes down to is making sure that your tests are represented at multiple different layers. So it’s not just unit test for each of the kind of component modules, but also as you’re deploying to like canary environments and staging environments and whatnot, that you’re running integration tests that properly test the full end-to-end requirements or user stories or what have you. That has to be kind of tested at that holistic level as well.
Sam Taggart 00:25:13 So what mix would you say are unit tests versus end-to-end tests in general?
Cody Ebberson 00:25:18 Good question. I personally don’t love that distinction because I think that there’s kind of a blurry area in the middle there too. for things like data formats or like basic algorithms that conform nicely to a unit test, that’s always better, right? You’re closer to the code that’s going to run faster. The development and test cycle are just a tighter loop and you can just move so much faster. When you get to the notion of like very complex systems and you have like microservices, you’re just, and any degree of multiple services that are interacting with each other now you basically force yourself into a world of requiring those like integration tests and end-to-end tests. I’d say if I were to just put some like simplified numbers on it, we’re probably not too far off from a 50/50 blend of lots of small unit tests and then lots of integration tests that, and those integration tests have to go all the way from making sure that you’re testing against a proper database and a Redis cluster and multiple servers and multiple database instances to make sure that the full complexity of the system is being represented there.
Sam Taggart 00:26:22 Yeah, so do you find then you don’t do a lot of mocking, or do you do a lot of mocking and test stubs and things like that?
Cody Ebberson 00:26:28 We try to avoid mocking as much as possible. Just as a general principle, the key points where if you’re using various like third party cloud services for sending emails or for storing objects in like an in AWS S3 or something like that, we mock those endpoints, but for everything else we have a tendency to avoid mocking as much as possible. Well I think perhaps one of the more controversial ones would be like whether you mock out your database calls and so most of our server-side application that would ever result in something running a SQL query against a Postgres database, we have a strong preference for making sure that those are actually hitting Postgres when as we run our test suites. I personally believe that trying to mock database queries is, for us at least, it’s not a good fit and we, we get a lot more confidence when it’s actually touching the database. And where that has proven to be very valuable is as our project grows in age and you start to go through various versions of Postgres or various versions of Redis and you, okay, the Postgres 12 to 14 upgrade uncovers a whole bunch of subtle changes in various syntactic differences that would not have happened if we had been mocking out those various infrastructure components. So integration testing at that level, I’m a huge fan of.
Sam Taggart 00:27:41 Good. So how does regulation affect maintaining legacy code?
Cody Ebberson 00:27:46 There’s a good question there and I think that there’s, maybe it’s a case where sometimes the regulation can be at odds, what the market wants and certainly what customers want because sometimes the regulation is going to push you to upgrade to newer features, newer security protocols, newer encryption protocols, et cetera, et cetera. And from a software engineering perspective, I think that’s great. We should keep moving the line forward, but oftentimes there for a variety of reasons, maybe some customers a partner does not want to upgrade. And so now you have a bit of a pickle there of how far back you should maintain backwards sup support, legacy support, and that’s kind of a case-by-case basis. I think that there are typically, there’s outs for like grandfathering things in, I think in healthcare one of the funniest examples is faxing.
Cody Ebberson 00:28:34 Typically we think of faxing as crazy outdated legacy technology, but it’s still very widely used in healthcare as an interoperability format primarily because it’s grandfathered in. And I personally think it’s hilarious when you read through these various like healthcare requirements and it’s, oh, mandating this form of encryption and this security protocol, da dah dah, dah, and then you get to the section on faxing and it’s like, try to make sure the fax machine is in the back room so people can’t see the pages as they’re getting printed out. And so that’s a pretty stark juxtaposition. But I think it’s just acknowledging the truth that sometimes legacy systems are important, and you have to maintain them just as a pragmatic matter.
Sam Taggart 00:29:13 Yeah. So how do you balance the security versus stability? Because I would think that, and I think maybe you hinted on this a little bit, but security says that you should update your things to patch the latest vulnerabilities, but then that has to affect stability. And then in addition to that, I assume there’s some cost to revalidate stuff after you change it.
Cody Ebberson 00:29:31 Yes, absolutely. And it’s a very common pattern for us. We, as we’re introducing a new feature we believe strongly in things like feature flags and deploying to production, but in a disabled fashion or running multiple implementations in parallel you have your existing implementation, which is providing the customers with whatever services you’re providing, but you’re running your next version in parallel as a bit of like an internal smoke test or an internal canary and comparing the results of here’s what the old version did, here’s what the new version did, are they producing the same results? And if yes, great. If no, okay, let’s set off some alarm bells and, either that comes back to our team and we need to check our assumptions and see like, hey, is this breaking something? Or if it’s something about how the client was interacting with the service, then we might need to engage them in a conversation and start a migration process.
Cody Ebberson 00:30:26 So obviously it’s a known bad thing to test in production and have your customers do your testing for you. But I think that when you deploy multiple versions and, and have one in a kind of shadow enabled fashion that you can quote, unquote let your customers test for you, but you’re doing it in like a log only fashion until you’ve achieved some level of confidence that okay, we know that all of our existing customers and all of our current usage is we can flip the switch and high confidence that it’s going to work as expected.
Sam Taggart 00:30:53 Yeah, I’ve heard of that before. I believe I’ve heard, seen that referred to as the strangler fig pattern.
Cody Ebberson 00:30:58 Strangler, I’m not familiar with that term.
Sam Taggart 00:31:00 Basically, yeah, I think there’s these fig trees that grow up and they grow around an existing tree and then eventually the existing tree dies, and you just end up with this hollow shell or something.
Cody Ebberson 00:31:09 I love it. Yes, it’s a great metaphor and itís kind of perfectly describes it.
Sam Taggart 00:31:14 You also mentioned logging. Can you talk about some of the challenges with logging?
Cody Ebberson 00:31:19 I mean, one of the big challenges is that we log a ton of data. If you, if a user runs a search and that search includes data from potentially multiple patients or multiple concepts or entities or resources or whatever, we’re going to log a whole bunch of stuff in that moment. Because if, I mean, mostly due to compliance or regulatory requirements, but often because that’s what customers want as well, because if anyone has ever seen any bit of data, they want to be able to track that, record it and analyze it and look for anomalies, et cetera, et cetera, et cetera. So we, we do log a ton primarily for security and just like access controls and safety. But also I do think that it contributes to, I mean there’s setting aside the compliance and regulatory, I’m a big believer in logging a ton, both like log lines but also telemetry metric, like open telemetry system, health system performance, dashboards, dashboards, dashboards for all that alerting and that that’s more of a system health and system stability perspective, but it all comes together in kind of a unified package.
Sam Taggart 00:32:18 Yeah, I’ve got a bunch of questions about logs. So one question I have is, how do you avoid logging sensitive information?
Cody Ebberson 00:32:24 We treat our logs as PHI, so in healthcare Protected Healthcare Information. And so the log data itself, it has the exact same protections and controls as the production database has. And I think this is relatively common in healthcare, you can have a kind of like a subscriber relationship to subsets of logs. So as a service provider, we can pipe the relevant logs to our customers as well. And that becomes part of that kind of handoff agreement about we can either strip all of the protect information. So rather than showing a person’s name or a lab results, it can just be, everything can be distilled down into just identifiers and abstract values like that. And if that’s what they want, that’s what they want. It’s also possible to have hydrated data as well. And that’s more of a question of like what the use case is for the data.
Sam Taggart 00:33:14 Yeah, I would imagine the full data is probably better for developers trying to debug stuff.
Cody Ebberson 00:33:20 I mean, it’s always a trade-off. Yeah. And developers accessing that data is all long conversation all by itself. And I think that there’s a kind of funny irony when it comes to data controls and access that’s like, I think Google, if you think about the access controls that exist for something like Gmail famously like high, high, high bar for protected data so that no one can ever access that data. It’s a major process to, if for some kind of system stability or a bug or an investigation, you do need to get access to that data. There’s a long list of processes and controls you need to go through to kind of break glass and investigate there. I think that the rest of the software engineering world should aspire to get to that level of controls and we certainly have an eye towards that future where everything is at that level of protection. I think itís really the gold standard that we should all be striving for.
Sam Taggart 00:34:12 Yeah. I have another question around logs. How do you ensure immutability for like auditing purposes and things like that?
Cody Ebberson 00:34:19 So first, for our production databases, we are strong advocates for the, like the worm model, WORM, right? Once read many times. So most of our databases are appended only. And so, and quote unquote update operation is really creating a new version of a resource. And so for any given like the, a notion of a patient or the notion of an appointment, that’s really, every single change is being represented as a new version. So you have perfect historical tracking of every change and who made that change? And that’s in the production database itself. And then as that kind of flows through the system and ends up in logs and analytics and data warehouses, that’s more of a process question than it is a strict technical question. But everything is configured to be appended only, right? Only making sure that that data stays perfectly protected and hygienic.
Cody Ebberson 00:35:07 Like some of the compliance programs we talked about earlier, in particular, something like SOC 2, it comes with a list of controls and that translates that into like configurations. For example, inside of our Amazon Web Services environment, there’s various AWS features like Cloud trail, and I think it’s GuardDuty. These are AWS features that you can put various features or services into this lockdown mode. And if anyone tries to change it or make any changes to anything, it’s just going to set up a whole bunch of alarm bells. It’s going to send emails, it’s going to send Slack notifications that like, hey, someone’s in there trying to make a change to one of these protected services. Someone should probably check this if they had access at all in the first place.
Sam Taggart 00:35:50 Okay. And then I guess that would also apply then just to configuration stuff in general. So if you like have some, in your case I think you guys are doing more like web service stuff, but if you had some sort of device that you gave to somebody and it and it and it had some configuration on it, you would somehow validate that as well?
Cody Ebberson 00:36:04 Yes. Like the golden bits model of you, you’ve kind of produced an artifact, whether that’s a binary or a distributor bit of code. And it’s goes through its own validation. Like for, in our case, we have our primary, our web services, we have some on-premises agents for connecting with legacy devices that are not cloud enabled necessarily. And same thing there. And I think there’s a set of industry best practices. You produce the binaries, you produce the artifacts, you also produce the checksums and publish the test reports that are associated with those and just trying to follow best practices across the board on things like that.
Sam Taggart 00:36:35 Great. So we mentioned the CrowdStrike incident earlier and I saw an interesting take and I wanted to get your thoughts on it. And there are a lot of people saying though they should have done more manual testing. And someone else pointed out that if you have manual tests and then something falls through the cracks, the solution is then to add another checkbox. But how do you verify that that checkbox actually gets checked and the work actually gets done versus if it’s automated, you update your script once and then hopefully that should never happen again because it’s now in the script. Do you have any thoughts on that?
Cody Ebberson 00:37:05 I would tend to agree with the belief that it should have been an automated test. I mean, human testing and manual validation have been with us for a long time, and they will probably be with us for a long time into the future. But I think that that’s getting pushed further and further out. And as an industry it’s just better if we embrace more of the automated testing. The automated testing certainly gets more complicated, especially as you start to think about the, in their case that’s a huge number of different devices and network configurations and deployment configurations. But that’s also, I guess part of the job, right? To make sure that you’re getting your services and your code into environments that are representative of the real world as much as possible.
Sam Taggart 00:37:47 So, I guess in the medical and other more highly regulated industries, you try to control that hardware as much as you can if you have the option, I will imagine.
Cody Ebberson 00:37:54 Yeah, absolutely. I mean, the extreme case here would be things like embedded devices like a pacemaker, right? Where you have old school software engineers who are writing code that blurs the lines of application code and operating system code. Embedded devices — because it needs to run for a period of years in a completely automated and offline environment — and that’s probably where some of the most extreme regulations and testing requirements exist: for those embedded medical devices. And then the spectrum kind of goes from there.
Sam Taggart 00:38:25 Great. All right. Well thank you very much.
Cody Ebberson 00:38:29 Thank you so much, Sam. It’s great chatting with you.
Sam Taggart 00:38:31 For SE Radio, this is Sam Taggart.
[End of Audio]
Nick Tune and Jean-Georges Perrin join host Giovanni Asproni to talk about their proposed approach to modernizing legacy systems. The episode starts with some high-level perspective to set context for the approach described in their book, Architecture Modernization (Manning, 2024). From there, the discussion turns to important details, including criteria for deciding which aspects to revisit; some of the activities, processes, and tools; and the importance of data engineering in modernization efforts. Nick and Jean-Georges describe how to successfully implement an architecture-modernization effort, and how to fit that work with the teams’ other priorities. The episode finishes with some warnings about the typical risks associated with modernizing a legacy system, and suggestions on how to mitigate them.
This episode is sponsored by QA Wolf.
Show NotesArticles and Resources Book: Architecture Modernization* (Manning, 2024) * Conway’s Law * Domain-driven design * Event Storming * Journey to Product Teams * Team Topologies * Value-Stream Mapping * Wardley Mapping
Related Episodes* SE Radio 615: Kent Beck on “Tidy First?” * SE Radio 602: Nicolas Carlo on Improving Legacy Code * SE Radio 601: Han Yuan on Reorganizations * SE Radio 566: Ashley Peacock on Diagramming in Software Engineering * SE Radio 554: Adam Tornhill on Behavioral Code Analysis * SE Radio 525: Randy Shoup on Evolving Architecture and Organization at eBay * SE Radio 396: Barry O’Reilly on Antifragile Architecture * SE Radio 363: Jonathan Boccara on Understanding Legacy Code * SE Radio 331: Kevin Goldsmith on Architecture and Organizational Design * SE Radio 308: Gregor Hohpe on It Architecture and IT Transformation * SE Radio 295: Michael Feathers on Legacy Code * SE Radio 242: Dave Thomas on Innovating Legacy Systems * SE Radio 236: Rebecca Parsons on Evolutionary Architecture * SE Radio 228: Software Architecture Sketches with Simon Brown * SE Radio 226: Eric Evans on Domain-Driven Design at 10 Years * SE Radio 166: Living Architectures with John Wiegand * SE Radio 142: Sustainable Architecture with Kevlin Henney and Klaus Marquardt * SE Radio 132: Top 10 Architecture Mistakes with Eoin Woods * SE Radio 115: Architecture Analysis * SE Radio 93: Lessons Learned From Architecture Reviews with Rebecca Wirfs-Brock * SE Radio 64: Luke Hohmann on Architecture and Business
TranscriptTranscript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact content@computer.org and include the episode number.
Giovanni Asproni 00:00:51 Welcome to Software Engineering Radio. I’m your host Giovanni Asproni and today I’ll be discussing Architecture Modernization with Nick Tune and Jean-Georges Perrin. Nick works with the product and technology leaders to map strategy, model domains, design, architecture, and build continuous delivery teams. He’s the author of Principles and Practices of Domain Driven Design and co-author with Jean-Georges Perrin of Architecture Modernization. Jean-Georges is JGP for short, is the Chief Innovation Officer at ABI Data. The chair of the open data contract standard is a co-founder of the IDA user group and author of multiple books including † Implementing Data Mesh Sparking Action, 2nd edition , and of course † Architecture Modernization with Nick. Nick and Jean-Georges, welcome to Software Engineering Radio. Is there anything I missed that you’d like to add?
Jean-Georges Perrin 00:01:41 Well, thank you. Thank you for having us. Just to show off a little bit, I’m also a lifetime IBM Champion. I’m a PayPal Champion and recently I’ve been data mesh MVP — and MVP stands for Most Valuable Player, not minimum viable product here.
Giovanni Asproni 00:01:57 Nick, anything to add?
Nick Tune 00:02:00 I think I came like third in a hundred meters at primary school, at Sports Day once.
Giovanni Asproni 00:02:05 .
Jean-Georges Perrin 00:02:06 You beat me.
Giovanni Asproni 00:02:07 So let’s talk now about the subject of this podcast, so about architecture modernization. So let’s start with, some context for our listeners. So my first question is, what is architecture modernization as you propose it? Is it a set of activities, is a process, is a methodology or something else?
Nick Tune 00:02:26 So the general concept is as we build software systems, they get older and the world around us changes, new technologies become available and new patterns and practices and ways of doing architecture become available. Our company’s business model changes and so we have a software system that is quite behind what’s possible in the modern day. So modernization is really removing those disadvantages of the old systems by using modern practices, telling and thinking I would say. So it’s really a topic or a theme. I wouldn’t say it’s a process. I wouldn’t say it’s a technology. I wouldn’t say it’s a very specific thing, it’s just the process or the act of doing something in a general sense.
Giovanni Asproni 00:03:08 Okay. So is it aim at large scale changes or incremental improvements? Because from reading the book the way it is described there is also the concept of creating a group of people that will supervise these changes and will help the teams in doing this. So reading it seems to be a large scale and they already something that is a kind of a big thing or is it more incremental improvements in day-to-day work?
Nick Tune 00:03:34 Well, I think it depends on the context, but I mean for a lot of companies, nobody wants to do modernization. Nobody wants to spend three, five years fixing their legacy systems. But at the same time, business leaders want to be able to build new products to expand to new customer segments and new countries. And when the legacy system doesn’t allow you to do that, sometimes you have to do large scale changes. Obviously, we would all prefer to do smaller day-to-day changes and if you have good discipline and good practices and you don’t build up technical debt, yeah you can do this on a more gradual ongoing basis and not need to do big projects.
Giovanni Asproni 00:04:10 Okay. And it’s also kind of one of activity or an ongoing one or a bit of both. What I mean is does it have a kind of a start and an ending and then you say now we have a modern architecture or it’s something that you continuously do to keep the architecture somehow relevant?
Nick Tune 00:04:31 I mean there might be periods where we’re doing more or less modernization. The more technical debt we build up, the more difficult our legacy systems we come to work with, the more we have to invest in those. So there might be a period where the company’s talking about modernizing and then when the system becomes less of a bottleneck, less of a blocker to the business kind of starts to, we stop talking about that. So there’s not really an end date, not really a start date either, but there are exceptions. One of the case studies in the book is OpenTable. They did a big modernization around 2012, around that time period they basically stopped all product development work, did this big modernization project for nine months and then carried on again as normal. So you can do it that way, but most of the time it’s more of a fuzzy thing with big peaks and then starts to taper out maybe. And there’s always this ongoing, continuing to add product features versus doing modernization work. That’s usually a difficult topic. That’s always a challenge, especially when it comes to OKRs and roadmaps and everything.
Giovanni Asproni 00:05:43 Yeah. Because I guess everybody wants to have a system with more features that serves more customer needs and so spending time on modernization seems to be kind of maybe a cost more than something that will enable future business. I would imagine at least this is the perception that some have.
Nick Tune 00:06:01 Yes. An investment. Yeah.
Giovanni Asproni 00:06:03 Yes. So this looks to me that is kind of a bit of both a one-off activity and ongoing one and this depends very much on the current context of the system. So some kind of periods of big modernization efforts then work as usual, maybe the team trying to keep the technical debt that under control and then again potentially another big effort and so on and so forth.
Nick Tune 00:06:28 Yeah, I think it’s a business question, what does your business want to achieve? Are you looking to expand into new countries? How difficult, how expensive would it be to do that? With your current systems it might not be possible. So that would be the driver of the scope. What are the business goals and how does the current system constrain those goals?
Giovanni Asproni 00:06:48 Yeah, okay. And another aspect, you say that modern software architecture is social technical, so involves both technological and social aspects. How does that affect the architecture modernization choices and decisions? What I mean is how these social and technology aspects work with each other?
Nick Tune 00:07:08 Yeah, so at the end of the day we have to make decisions about which team own which parts of the system and that can actually have an impact on how we design the system. Sometimes there are different ways to slice your architecture and the way to think about that is if we slice it up in one way and we had teams owning this bit and this bit versus slicing it another way and teams owning different bits, what will allow teams to work more independently so that they’re not blocked or having to coordinate their work. And we can also think from a reliability perspective, which way of slicing the architecture and the teams is likely to result in the fewest bugs. So that might involve doing some domain driven design and looking at what do we consider transactions to be, which bits of data do we need to update atomically that will shape our architecture boundaries and our team boundaries.
Giovanni Asproni 00:08:06 In terms of these two aspects, is there one that is more important than the other? Like are social aspects more or less important than the technology one or they are at the same level? What would you say in your experience?
Nick Tune 00:08:20 It’s hard to really say that one’s more important than the other. I think both need to be done really well. I wouldn’t like to say either one’s easy, so no, I wouldn’t pick either one. I would say both are difficult challenges and the actual problem is how to do a joint optimization to find a compromise that spans across both the organization and the software.
Giovanni Asproni 00:08:41 Hmm, okay.
Jean-Georges Perrin 00:08:42 If I may add to that a little bit, it also depends on where you are in the project because the socio aspect to your project or to your modernization, whether it’s software or data, you may feel it differently at different time of your project. Okay. So first at the very beginning, it’s a business decision as Nick said, and you’ve got to go through acceptance of that part. So there’s already a bit of socio going on there. And then as you roll out, your architecture methods are changing and then when you use a magic change word, okay, you’ve got to coach people with this change. And that’s also where the socio aspect is really important. And in my experience I think it’s often undermined.
Giovanni Asproni 00:09:31 Yeah, and talking about these things, I’d like to know if you, from your experience, so now of course when we talk about social aspects, there is always Conwayís Law that comes in play. So for our listeners, is basically Conwayís Law says that the shape of the team structure follows the shape of the system being built. Now usually when we talk about Conwayís Law, we talk from a system perspective, say this is the architecture now this is how the teams should be structured to create, to implement the system according to this design. Have you seen in some companies, maybe you can have some examples of doing the other thing, like this is a team structure we have that we cannot change and so we need to match the architecture to what we’ve got in terms of structure. Have you ever seen anything like that?
Nick Tune 00:10:23 Yeah, so I have worked in the UK governments and they were doing a digital transformation and the digital bit was being built by this new digital organization and they had their own CTO and the internal facing stuff owning a lot of the legacy systems and databases that was owned by the enterprise IT team who had their own CTO. And so when you’re building a digital service, and digital usually means customer facing UI website front end. When you are implementing a new feature, your data has to come from somewhere. When you want to store data, you have to store it somewhere. And so a feature runs all the way from UI, from front office to back office. You’ve got the integration in between the databases I talked about. So yeah, I was on this project, we had this problem, I gave some talks about this almost 10 years ago now actually.
Nick Tune 00:11:21 And we proposed to change the architecture so that we didn’t have this dependency like this front and back on the front we are all doing stuff in-house, sitting together in an agile way. The backend bits, they were outsourcing lots of it to different vendors using different technology stacks. So very difficult to collaborate. When a feature crossed this organizational boundary, it was very difficult to even help. A lot of coordination was needed. So we proposed a restructuring, but that would’ve meant one of these CTOs would have to give something to the other one. And they were both fighting to become the global overall CTO. So neither of them wanted to obviously give away anything. It was all about power structure, very dominated by politics.
Giovanni Asproni 00:12:09 That’s interesting. This is where the social aspects actually had the really were the most important thing in this case. So they, even if maybe a system designed differently changing the structure, would they be more efficient to use, maybe easier to support still the way that there was this structure there that nobody wanted to change.
Nick Tune 00:12:28 Some bits were flexible, but some bits were not. And the two different departments were going in completely different directions that would make it harder to change at different tech stacks, different ways of working. It was, it wouldn’t have been possible to bring it together later on either.
Giovanni Asproni 00:12:44 How did you manage to deliver this project? Must have been really hard.
Nick Tune 00:12:49 Yeah, it was quite difficult. There were situations where we were building this new UI and we wanted to change the user experience. Like we had user researchers, they were going out every week talking to citizens of the UK, they were involving developers, they were presenting these videos of all the user research sessions, and we were like, oh, it’s amazing. So many things we can improve and make our citizens happy. And it would be like, let’s add a new bit of data on this page, let’s add some more data, let’s collect a bit of information over here. And then we started to hit these blockers and it’s like, well we have this legacy database which sits in A DMZ owned by a different vendor and the X in our schemas here. And it passes through these different systems. So if you want to change a scheme and you have to update it in four places, you need to pay a vendor like tens of thousands of pounds just to give you a quote for how much it will fix. So yeah, you just can’t improve the product. And I think people started to call this lipstick on a pig. You can do these digital services, but if you can’t actually change the business rules and the data and make those deep improvements, you’re just putting a new website on an old legacy system. Which has some benefits but not as much as it could be having.
Giovanni Asproni 00:13:57 Yeah, I think we’ll talk about this maybe later also when we talk a bit how to go with implementing an architecture modernization program because these kinds of problems seem to be potential showstoppers. Now a question about the architecture modernization approach you propose in the book. Now there are other also books about improving legacy systems, modernizing architectures in a way. What is different in what you propose compared to what was already there?
Nick Tune 00:14:28 I don’t really think there was much there, to be honest. I don’t really think there’s a lot of content out there on this topic. There are books that talk about refactoring like Michael Featherís Working with Legacy Code , but this book really isn’t about that on a tactical implementation level. It’s more on a, what are all of the dots you need to put together to do modernization successfully? So I was writing blog posts about this for a number of years, the different aspects, thinking about how this all fits together. I didn’t really see that much out there. And the book doesn’t really talk about an approach or a framework. The book covers the different topics you need to think about to do modernization well from a strategic level to an architecture level, to a migration level, but doesn’t say a specific way of doing things. It recommends techniques like wordly mapping and event storming and DDD, but you don’t have to use those and there’s no certification. It’s not a step-by-step process, it’s more tools and how you can fit them together.
Giovanni Asproni 00:15:28 And I guess the way I see it is also basically doesn’t stop simply what you need to do at the code base. It’s more general what you need to do at the system, broadly defined also what you’ve got around your software system or the organization, how it works, how people work together and skills and everything else. So it seems to be more general than the typical things you read about refactoring systems on improving architecture.
Nick Tune 00:15:58 Yeah, it’s not a refactoring book, it’s not many technical patterns in there. There is some stuff on DDD, there is some stuff around how you can migrate from your old to your new architecture. Typically you are going to be using some form of the strangler fig with an incremental migration. So you’ve got your new system and your old system running in parallel and you’re moving bits across and you have to ask questions like, do we migrate the res or the rights first? So we can take a bit out of the legacy. Maybe it’s a part of your website and it’s presenting some data, but the information still comes into your system from the legacy. So you have to have some synchronization between those two. So touches on those migration patterns. It shows how you can do things like software design, event storming and what that would look like in your code. But yeah, it’s not a detailed book about refactoring patterns.
Giovanni Asproni 00:16:51 Yeah. Okay. And now if we go into a bit more detail. So basically as we said, there is looks at all aspects of the system. And so as I understand it, this approach is about potentially revisiting pretty much everything around the old system. Technologies, the design, the features, the team structure, the team skills as opposed to doing the same things but better somehow. So it’s kind of revisiting things and having a better look at what we are doing with our system and see how we can have a better one, more than in many respects. But now I have a question about what kind of criteria we can use to decide in our system that if you want to modernize it, which aspects to revisit and which aspects to keep the same.
Nick Tune 00:17:38 Yeah, so some of the aspects we might want to revisit are the UI for example, do we just fix the code or do we make some UI improvements as well? Like the government example I talked about. Something else we might ask is do we make some improvements to the domain model and the data model? The simplest or the lowest version might be you just rebuild the old system in a new tech. But if your code’s tightly coupled and poorly designed, you’re going to bring that into the new version. So you might also desire to improve your domain model. Domain model is how you represent business concepts in your code. It’s the language you use. As systems get older, very often the way people talk about the products doesn’t match the words used in the software. Very generically we might talk about things like a customer, but in the code we might use words like a client.
Nick Tune 00:18:26 That’s a simple example. But over time we get these mismatches. So that’s one of the areas we can invest in the domain model. And for me the question is always what’s the business potential? We need to understand if we could completely modernize the UX, completely refactor our code and make it a perfect domain model, what would that be worth? How much would it cost? And then we can do that on a case-by-case basis for different parts of our system and work out what’s the best ROI for each area. In some cases it might just be lift and shift to the cloud and in some cases, it might be a complete revamp from the code infrastructure, UX domain model.
Giovanni Asproni 00:19:09 What about team structure, team skills and all these kinds of aspects as well? How do you decide that? Does it come after you decide, well ideally the domain model and potentially the architecture? Is this the ideal situation?
Nick Tune 00:19:25 Yeah, so as we are thinking about the new architecture and what the new boundaries will be, we have to start thinking how do we break up our business and how, what might we structure our teams around the architecture? So those three things are always the same equation.
Giovanni Asproni 00:19:40 Okay. So you mentioned UI, user experience, domain model. So of all these many aspects, are there some that are special in the sense that you always want to revisit them?
Nick Tune 00:19:53 Probably not. No. I don’t think anything is always. Sometimes you might keep your existing software and you might just change the code, you might fix some of the most complex bits in your legacy. Sometimes you might change the tech and not much change in the actual design of the software. So I think each of those bits is independently changeable. Obviously, it depends. Sometimes you might have a legacy system where the UI is very coupled to the code, and we can’t change one without the other. Or sometimes a legacy code might be so difficult to work with that if we want to change a tech, it’ll be so expensive we may as well fix it the main model as well. So the things can be changed separately, but we have to look at how coupled they are and how difficult it is to change each part independently.
Giovanni Asproni 00:20:40 Okay. Have you got a kind of real-life example showing how to apply some of these criteria how to think about what we need to revisit and how to proceed. Have you got any real project example you can give us? Of course, you know, without naming names.
Nick Tune 00:20:57 Yeah. So we could start with the UK governments. That was 10 years ago so probably not too many secrets there anymore. In that example, the government system had existed for decades. The business rules had existed for someone told me maybe even more than a hundred years. What was happening was when businesses were submitting their property tax assessments, the government works out how much tax you should pay and legally you are allowed to dispute that and complain. So everyone was taking their legal rights and disputing how much tax they pay. Government was getting a lot of these cases building up, they didn’t have enough support workers to process all the cases. And so businesses were taking the government to court. The government wasn’t even turning up at court because they didn’t have enough people to be there. They were losing a lot of money. Bad reputation doesn’t look good.
Nick Tune 00:21:51 So obviously when we’ve got a crisis like that, it’s very easy to make a case for modernizing and modernizing properly. I think the other aspect of the government was there was an initiative on a whole government level to do some modernization work and the government set global standards on what’s acceptable in terms of how the UX works, in terms of technology practices. So we have the individual business areas that have varying needs and then we might have global policies in our company that dictate where we have constraints where we must do things to a certain standard for example.
Giovanni Asproni 00:22:29 Hmm. In this case the government was setting some expectations and some standards at least for parts of the user experience in the systems stockholder?
Nick Tune 00:22:38 Oh yeah. They were setting a lot of standards. You can see online, um, GDS government digital service in the UK they had a list of like 10 or 11 points and if you were modernizing some systems, you had to go to an assessment at their offices in London. And if you didn’t meet all the criteria, they would say you’re not moving to the next phase. You’re not allowed to open your service to the public. Okay. If you couldn’t demonstrate for example, that you were iterating with real user feedback. So we had all those user research sessions and we were able to show them that and they were, , very happy with that. We were using the government design style kits, we were measuring our service, how it was being used. We were using things like continuous integration, which were minimum standards. We were putting our code open, so we ticked a lot of these boxes that were minimum requirements. Okay.
Giovanni Asproni 00:23:30 So in a way, in this case you didn’t have to think too hard to see what to revisit because there were some precise requirements in many respects in this
Nick Tune 00:23:39 Case. Yeah, on a global level there were some requirements about the minimum level, the minimum requirements in each area. And so that make a lot of decisions for you. We also are using this government platform that allowed us to spin up microservices, new front-end applications in a very conventional way with a paved road. So again, that already gave us a lot of the foundations and constraints we needed. So we didn’t have to think a lot there either. The technology and the infrastructure, those things were taken care of and decided for us.
Giovanni Asproni 00:24:10 And on another aspect, so you mentioned this before as well, that in the book list set of activities, tools, things that can be used to think about modernization and do that, but there is a lot of them. So of course there is mention of congress law, then there is event storming, worldly maps, tin topologies, there is behavioral code analysis. I mean you don’t quote it with the name but is you mention, code scene from Adam Thornhill and more as well. So do we need to use them all or how are we supposed to choose among them to proceed with our modernization efforts?
Nick Tune 00:24:48 Well, I’ll answer the question. Maybe JG has some thoughts on this as well, but I’ll give you my response first and then I’ll stop talking for a bit I guess. So if you are modernizing, you have to do a lot of things. You have to make a business case. What is the business trying to gain? How does the business plan to grow in the future? How is our current system preventing or making it too expensive to achieve those business goals? So things like wardley mapping to talk about your strategy. You cannot do strategy but you’ll probably make a lot of bad decisions so that, you can’t really negotiate that. Then you have to map out how your system currently works. You have to think about your current business processes. Think about do we change the business processes or do we keep them the same? You have to look at your existing code base and work out how do we refactor it; how do we start to break it apart? So the book does list a lot of techniques like that. But if you’re modernizing, these are the things that you have to do. Strategy, current state, future state business process, decoupling your architecture, migrating from the current state to the future state. So you don’t have to use all the techniques I recommend, but you have to answer all those questions. You can’t avoid them really.
Giovanni Asproni 00:25:58 And how can people choose among those techniques? Is there, some simple criteria they can use if there is one?
Nick Tune 00:26:06 I mean it depends on what problem you’re solving first. I think we always go to the left, let’s say with the why and then we move right to the how. So if someone says to me, what do we do next? I have to understand where are we in the process? Do we have a clearly defined business strategy and problem we’re solving? Well we need to start there first. Okay, if we have that, then we can spend some time thinking about which are the most important areas of our business to focus on. Then we can start thinking about which parts of the system would most need to change to improve those parts of the business. Then we can start thinking about how do we start breaking up the system, mapping out the current state in detail, making a future plan. And if we have that plan, then we can start thinking how do we execute, how do we actually put work in our backlog and start doing the work?
Giovanni Asproni 00:26:57 Okay. Have you got an example? Again from a real project in doing this, I mean at least showing how you go from, I donít know from the strategy to the rest of the work, maybe mentioning some of the tools just to put them in some kind of place to give people some mental model on how to think about these things.
Nick Tune 00:27:18 I think different clients I’ve worked with have been at different stages. For example, worked with a company does electric vehicle charging infrastructure. They already had a very clear business strategy. They wanted to grow, open up some new, I think they were calling them sites where you can go and actually charge your car where the electric vehicle charging stations are installed, for example. Now they had a very ambitious business plan, expanding it across multiple countries. And they were now wondering, okay, the business goals are clear. How do we get there on a technical and an organizational level? How do we start taking the current systems and having more clearly defined areas, different business domains, and how do we start organizing our team so that they can each work independently in different areas of the company and help us grow as quickly as possible. So the question was in that case, where do we start?
Nick Tune 00:28:13 What’s the right starting point? People I worked at the company, the architects and the CTO and the CPO, they identified some candidate areas where they thought it might make sense to start, but they had three of them and they weren’t sure which is the right domain to start with. If we start here, it will benefit in this way, but if we start over here, we can do things more customer facing. So the question here was all about how do we start. So in this case, me and my colleague Eduardo, we worked in an enabling role. We formed an architecture modernization enabling team and the goal of that team was to think about this modernization journey and to organize some workshops to decide what would be the right starting point, what would be the correct domain to start with? And then the next step would be to have this in-person workshop where we do events storming a map out the domain, identify the sub-domains and the team structure and actually build that roadmap to let’s start modernizing this part of the business. That answer the question? You want me to dig into any now is a bit more detail?
Giovanni Asproni 00:29:12 Yeah, I answered the questions. Yeah. So you said of course the strategy was already clear. Maybe if the strategy hadn’t been clear, I would imagine potentially some workshops potentially also using some wardley mapping to decide which direction.
Nick Tune 00:29:26 Exactly. If the strategy wasn’t clear, we would’ve had to go more in that space. There are some caveats around this. If that parts of your system need to be modernized and you want to demonstrate the foundations and put those in place, well you can start without a clear strategy. So that those things could happen in parallel.
Giovanni Asproni 00:29:46 Yeah.
Giovanni Asproni 00:30:02 And now a question I think this one probably is Jean-Georges, because I see that in your approach you give a significant role to data engineering, at least reading the book, there is an entire chapter dedicated to it. Data engineering data measures. First question, what is the relationship between data and architecture?
Jean-Georges Perrin 00:30:21 So I think you can’t do anything without data. So you can do all the architecture you want, all the nice design, all the modernization you want. If you don’t have data, you are not going to go very far
Giovanni Asproni 00:30:34 In modern systems. I see that now everybody talks about data. Yeah. So well at least in the system, enterprise systems that I see there is always very often at least data engineering team. So probably everybody wants to capitalize from the knowledge. Right. Now when in a modernization effort, what is the typical aspects related to data that maybe in a typical project, in a typical system people want to take care of that maybe we’re not there. I can imagine, I donít know, when I started working data was mostly database queries to satisfy user stuff. But now there is more analyzing interactions trying to get inside. So maybe you can tell us a bit more about that.
Jean-Georges Perrin 00:31:15 Yeah, sure. So I think data has significantly changed and the data engineering practice has not, and this results in creating very centralized team. And I completely relate to what Nick was saying about the two the two CTOs fighting a little bit because in big organization you will very often have a data organization and you will have some enterprise or software organization, I mean enterprise architecture, software organization. And they don’t often get along. And this is also due to these different ways of working. Okay. Technically you can call it socio, the socio aspect of the platform or the socio aspect of working, but it’s really about the ways of working. In my experience, I’ve seen very often centralized data team that were just growing, I wouldn’t say exponentially, but they were growing very fast. But just to cope with what was needed to maintain and the maintenance cost prevented them to actually go to some modernization.
Jean-Georges Perrin 00:32:27 And so every time I’m not trying to throw the stone or throw the ball towards the centralized data team, but a lot of what we’ve seen, and for me the book is also the conclusion, probably not the conclusion, but a good step of where we’ve been going in modernizing since I would say early 2000 to now, okay. And you’ve seen the advent of agile methodologies, you’ve seen the advent of all this scrum, this product thinking, et cetera, which in software and of course then in architecture has been very strong but has not been the case in data. Okay? Data has always started to focus on I’m going to do my job. Okay. So when you’re thinking about, when I’m discussing with a lot of data engineering teams or data engineering organization is they say, yes, we are agile, we are doing sprints, okay.
Jean-Georges Perrin 00:33:22 And basically their sprints are mini waterfalls of two weeks and it’s not working. So when I say it’s not working, it’s not scalable. Okay? So, so all the lessons we’ve learned in software and that mostly Nick put in the book, we are not using that in the world of data enough. Okay? So, and I still think very strongly that data mesh is one of the solutions. Probably one of the ideal you want to go towards. Okay? So if you listen to Gartner or some people they say, oh, data mesh is already dead or, but if you look also at Gartner, the same Gartner, and they say you look at the component of what data mesh is and the four principles that are translated directly into things that are on the rise within the Gartner environment for example, I think that’s, that’s where we are, okay? We want to modernize architecture for all the good reasons that Nick said and, and you as well Giovanni and the thing is right now, but the data needs to follow up. Okay? So there’s no way we can have a state of a architecture or a modernized, whichever level of maturity you want to give it without also modernizing data.
Giovanni Asproni 00:34:33 Have you worked in any projects in any efforts where actually data, modernizing data was the major driver for an architecture modernization effort?
Jean-Georges Perrin 00:34:43 I’ve seen a few, typically two days when companies are going from on-prem to the cloud, okay and large companies, not everybody is fully migrated and some are actually coming back. But the thing is, and you see the, you see the pitfalls as well when you are part of this kind of project is that I’m trying to do a lift and shift, okay? But for data, having a lift and shift is much more complicated. Let’s say I am living on-prem data warehouse like an ExaData or Teradata and I’m going to the cloud and doing a Redshift or BigQuery for example. Because usually you also change the technology of the tools you’re using. That is very complicated for as part of the architecture redesign. Because easy tendency is to say I’m going to have direct pipelines that are mimicking what I have on prem to what I’m going to do on in the cloud.
Jean-Georges Perrin 00:35:34 Okay? And it’s very complicated because first the technologies are different, second the expectations are different, the billing is different, and the performance is different. So I’ve seen a lot of projects where things were optimized for on-prem. Okay? So even using stuff like a SQL server completely on the biggest machines they could have and using SQL server as a data warehouse technology on-prem and then you go to the cloud and then you say, okay, I’m going to do Redshift. But all the optimizations they put in place for as SQL servers, the way the structure, because at this point you are tweaking the architecture, you’re tweaking it to, you still follow the guidelines of the architecture, but the implementation is so close to the engine itself that you are not benefiting from what for example, a Redshift could give you, right? You’re still having the same models that you would have in SQL server.
Giovanni Asproni 00:36:31 If I understand correctly. Let’s see if I’m understanding correctly your point, basically you’re saying when you have a modernization effort that involves data. So for example, shifting the system, putting that into a cloud from on premises, trying to keep pretty much the same shape of the system but in the cloud actually is a problem. And probably a better way to do that would be to revisit the way data is managed and maybe you need to reduce some things differently because if you have stuff like say on the premises SQL server optimized for SQL server, then you move, you said Redshift, it’s like well now we need to do something different with the data otherwise will be suboptimal.
Jean-Georges Perrin 00:37:10 You’re exactly on point. And that’s why I think Dan and I guess that Nick agrees on that as well is that’s why I think like data product thinking and data contract as well help us in the data engineering world to go there. Because what you’re actually giving your customer is disagreement this proposal around data management.
Giovanni Asproni 00:37:35 Okay, so now I’d like to talk about the implementation aspects, yeah? So the first question is, we may be thinking that we may need to modernize the architecture, yeah? Maybe we have a gut feel or something that seems to be not working well, features that maybe are a bit slow to be developed or some aspects like this. But what are some criteria, some kind of crisp criteria if you like, that we can use to decide that an architecture is worth modernizing?
Jean-Georges Perrin 00:38:08 On the data side, it’s mainly, for example, I would say it’s the main driver is the change of philosophy versus on-prem to going to the cloud or new laws that come in effect. Okay, I live in the US but I travel a lot to Europe and I see the impact of what GDPR has done on data and a consequential higher maturity when it comes to governance of data in Europe versus the US, there’s also a difference. Okay, so that seems like it’s a very positive difference towards Europe, but there’s also a lot of varied positive difference towards the US. But the thing is that’s probably not the topic for today. I think that what I’m seeing is that those two are the drivers, right? There’s always, there’s kind of three main drivers when you’re looking at modernizing a project for me is, either you want to save money, you want to make more money or because the regulator pushes you to go in a different way.
Jean-Georges Perrin 00:39:06 Okay? So that’s, I think that’s the main three drivers for me and very often for data it’s a regulation. Okay? So I work in the financial sector in the US I work also in healthcare, regulation on data here is very big and pushes a lot of those aspects of modernization. Okay, you’ve got to build more reports, you’ve got to have this regulatory implementation et cetera. That’s what the kind of the driver are. And in terms of work, the one sequence of that is that you either goes a traditional way and you’ve got this mini data engineering project that are going there or you’ve got a more global picture and you say, okay, well now I’m done with that and I want to do a modern data engineering approach with once more data contract data product or data mesh.
Giovanni Asproni 00:39:53 Okay, so we understand from the data perspective what about other aspects? So well as we said, data is a lot of regulatory things. It could be even saving money or make more money. The other aspects. So, in addition to data, so anything else that you need, modernizing what other criteria can we use there or are the same or are the criteria the same?
Nick Tune 00:40:17 I think it can be various things. Sometimes it can be around costs, sometimes it can be around support costs. So you might have lots of very manual support processes. You might have customer support teams or call centers with hundreds or maybe even a thousand people and you’re like, what if our software didn’t cause so many errors or we could fix problems more automated, we could save millions over the course of a few years. So that might be one around cost savings. I think most often it’s around growth opportunities. Like what are the things that we could do as a company that currently aren’t possible or are too expensive. New products moving into new markets currently working at pay fit, a French company for example, being very successful in payroll now has other big ambitions companies grown. They want to build newer products grow the company so they can build more capabilities, become more profitable as a company.
Nick Tune 00:41:14 So often a lot of these factors are happening at the same time as the company’s growing. The system that was fine before, that worked for one scale for building one product for a certain kind of customer suddenly as you want to scale the company and the organization. Now the current system is maybe a bit too coupled in places it wasn’t a problem before, but it is now. Or as you try and do more things and support costs grow. So yeah, it can become expensive to do things. A sign to look out for is when maybe you got some product manager or some salesperson who says could we build this new API for this partner? It’s a really strategic partner. All they need is a search API that works across three bits of data.
Giovanni Asproni 00:41:57 They need easy. That sounds easy.
Nick Tune 00:41:59 That’s all they need. And you are like, well those three bits of data live in three different legacy systems. We have different teams that own different parts of it. Those systems are currently very unreliable. We deploy them once every three months and you are like, oh my gosh, if I work for any sane company with a good architecture, we can implement that in a day’s worth of work here it’s going to take three or six months. Giovanni we have to say no to things that should be very easy and should be very valuable. So that’s something to look out for definitely, when things are too expensive and we’re saying no to things that could have a decent impact for the business.
Giovanni Asproni 00:42:35 Actually I’ve got now a different question that is, have you ever come across a situation where you actually decide that, it’s not worth modernizing, let’s keep it this way. So people were considering about modernizing the system then had a deeper look and say actually it’s not worth the effort and the cost. Have you got any example of this?
Nick Tune 00:42:57 As a consultant that happens all the time. Yeah, they call you in, they’ve got these big ambitious business goals. They want you to tell them how they can modernize their systems very easily and you tell them, well it’s going to take three years. You’re going to have to put some projects on hold while you do the modernization work. You can still do some feature work, but you have to balance modernization versus product work. And they’re like, we can’t justify to the CEO. And one client I worked for, I was talking to a Chief Finance Officer, and she was saying, why are my developers talking about microservices? Why do I need to sign off this budget to do some modernization work to move to microservices? Yeah. So this happens for a variety of reasons.
Jean-Georges Perrin 00:43:39 I would even add to that, I was probably a little bit more in the enterprise side as well is that instead of modernizing its buy something off the shelf. Okay. And I’ve seen this scenario as well. So oh you start or you’re thinking that you’re going to work on a project which is going to be built a new feature or a new feature set and then at the end of it, here are actually going to do an integration project between your CRM and your loyalty program for example. Okay, so there’s also this where it’s not worse modernizing the existing or just hey let’s get something off the shelf.
Giovanni Asproni 00:44:14 That’s true. Sometimes just buying something new is the best idea. And I think this is part of the strategic work you do at the beginning of a modernization effort. So maybe with wardley mapping that you decide what is called to the business, what you can buy and take some decisions in this respect. Am I correct?
Nick Tune 00:44:34 Yeah, definitely. I was in New Zealand a while ago, earlier this year and on day one I did some events only with this company and they mapped out this current system that needed lots of improvements. They were going to fix every different aspect of it. When we did the wardley mapping, they were like, we could fix all of these things and modernize this legacy system, but if we do that, we’ll have no time to work on all of this new AI stuff, we want to do. Whatever you think about AI,let’s just put that on hold. All this other new stuff we wanted to do. Well we only have a limited amount of people to work on this. And so that pushed them towards, yeah, we could buy something off the shelf here and that would free us up to work on these more interesting AI things that we want to work on.
Giovanni Asproni 00:45:17 Okay. And now another question that I suspect I know the answer but I’m not quite sure. So if you actually come across any systems that were designed and managed in such a way to be evergreen therefore needing no modernization and often, we talk, and I talk as well about evolutionary architecture and this kind of systems that ideally should allow you to create a system that follows the business needs. It may be with a lesser amount of technical data accumulated. So have you come across such a system in any of your projects?
Nick Tune 00:45:58 Yeah, I’ve worked over the last 15 years probably with two or three companies that fit that criterion. And I’ll tell you what was consistent about those companies. They had teams that were autonomous, those teams were doing extreme programming practices like TDD and pair programming. They were very focused on continuously improving their work. They were talking about refactoring all the time. They were always trying to learn new stuff. They had like training caterers during work hours and stuff. People might say, ah, these are all just geeks who are going crazy about craftsmanship and everything and all extreme programming. But those were the companies I’ve seen that didn’t need to do this big modernization work because they built quality into everything they did, and it was an ongoing topic.
Giovanni Asproni 00:46:46 And the fact that it was ongoing was I guess a concern also for the senior leadership to keep this quality high I would imagine. So it was not simply the teams deciding to do that.
Nick Tune 00:46:57 It was a mix of having a good CTO who understands the value of these practices. I think having a good CTO is consistent in all those experiences. A CTO who understands quality and having a CEO who trusts the CTO and people used to say things like, we’re not a tech company, we’re a music company, we’re so focused on tech here. But the CEO could see we had multiple teams. I think at the start there were six or seven teams and that grew over the years, deploying to production every day. When the business can see results like that, yeah that buys you some space to you don’t have to justify anything. When a customer raises a bug and you fix it in an hour deployed to production, well that kind of buys yourself some credibility and a lot of companies, business leaders can see that, okay, they talk a lot about tech, a lot about refactoring things like DDD extreme programming, but they can see clear results from that.
Giovanni Asproni 00:47:54 Yeah, that’s quite interesting.
Jean-Georges Perrin 00:47:56 Nick, if I have a question for you, you mentioned that there were three companies over your last 15 years. What’s the percentage? What’s the three-company represented? The percentage of company you’ve dealt with?
Nick Tune 00:48:08 Ah, it’s probably about 3%. Yeah, very small number and even sometimes it’s not even the whole company, it’s when you’ve got a large company you might have pockets. So I worked with one of the UK’s big supermarkets chains a few years ago. They had some teams who were doing amazing work and other teams that are building up a lot of technical debt. So yeah, in a big company, also like when I worked at Salesforce, some teams are doing great work, continuously improving, having high quality and others were just building bigger and bigger legacy systems every day.
Giovanni Asproni 00:48:43 And now a question for I guess both of you is have you got any recommendations for fitting the modernization work with other priorities of the business? Because I think we mentioned this a few times before, that this is one of the contentious points is like, well if we spend time modernizing, we cannot really spend that time adding new features. But are there any suggestions you have to give people on how to talk about the need of modernization, how to negotiate with the other priorities? Of course I said both of you because we talk about more some of the software aspects but for data as well and data being particularly sensitive and complicated too.
Nick Tune 00:49:30 So I would say a few things are always important or very helpful. I would say the first one is having a consistent message at the C-level. So are the CEO, the CTO and the CPO all giving a consistent message or is the CTO talking about modernization and the Chief Product Officers talking about lots of new features? Well if you’re giving mixed signals at the top of the organization like that, you’re already off to a bad start. People in the middle managers, the directors above them, the people working in individual teams like developers and product managers, they’ll have to decide modernization or new features. We’re getting different messages and most of the time people will just default to building new features because that’s visible. That’s what they’ve always done and that’s what they’ll get rewarded for. So you need to have a very consistent message that modernization work is important in this company and a very clear message of what it’s worth for the company of why not building a feature now is worth 10 or 100 times X more value in one- or two-yearsí time.
Nick Tune 00:50:32 So a clear connection between modernization and business goals, consistent message, and a consistent message from the different leaders at different levels of the company as well. So there’s no doubt, I would say those are the fundamentals. And then when you’re building your roadmaps for the year or for the quarter or for the semester, again that’s another chance where I have to make more fine grain decisions. I think building different possibilities is key. So build three different roadmaps. I would say. What’s your lots of modernization, not much product work, what’s an equal balance and then what’s mostly product and not modernization. So you can talk about the different trade-offs and you can ask different stakeholders to give inputs on which one they value the most.
Jean-Georges Perrin 00:51:20 I would say in data all that applies. But one thing which is difficult in the data world is to measure the RI of data. Okay, so what’s my re return on investment when it comes to data project? One of my recent experiences was in the risk division of a major FinTech and how do you measure that you didn’t get fined; you didn’t get any money stolen or it’s very difficult okay to determine that. But you’ve got to find this KPIs, and you’ve got to stick to them. And as Nick was saying, you’ve got to report that to your CPO, CTO and CEO. Okay you’ve got to report to your leadership all you are doing these KPIs and before you start the project you’ve got to do that. And I think that if you keep that in mind, as Nick was saying for the greenfield is lucky three greenfield project, you can get almost anything. Okay. So then you get the credibility, you are constantly on your KPIs, you’re constantly delivering value to the organization. And then it’s easier to say, okay, well now I want to start this project. But it’s always going back to, it’s starts with a business decision.
Giovanni Asproni 00:52:38 Okay. And now let’s try to end with a bang. So a good question to end with a negative note. How often do architecture modernization programs succeed or fail in your experience?
Nick Tune 00:52:50 I’ve been burned a lot of times by things I didn’t work out. Like I’ve been involved in projects where they say things like, yeah, we promise we’ll let you focus on that this year. And then before you’ve even really got started, it’s like, can we build this one new thing, this big new product feature? It might take a couple of months, but once this is done then we’ll get to this deeper modernization work. And then it just carries on. And you actually don’t do any modernization work.
Giovanni Asproni 00:53:17 How often does this happen? Is it a common thing? Is it something you found in many places? This kind of attitude?
Nick Tune 00:53:25 Yeah, it’s quite frequent I would say. Ones that work the best are ones like the UK government where you have this minimum level. When you have a very strong problem or a crisis like the government had, that’s always a very strong motivator that helps you to modernize. Because there’s a clear need, it’s hard to avoid it. And when you have those standards, those minimum acceptable levels, those global policies, that means you have a need, and you have some standards. So you’re going to modernize and you’re going to do it to a good standard not taking shortcuts because that’s not allowed. So when those recipes are there, yeah, it normally does work out. Maybe not everything goes perfectly of course, but less than half the time, maybe 25% of the time I would say things grow really well. Okay. Over the course of two or three years.
Giovanni Asproni 00:54:11 And so if you would sum up let’s say the most three or four common causes of failure, what would they be in your experience?
Nick Tune 00:54:19 Yeah, the first one is, like I said before, not having a strong enough reason and a compelling reason and sticking to that reason and not just defaulting back to product work. That would be the first one. Then I think it’s around having the expertise in the company to do modernization work. Sometimes, yeah, the top of the company, the CTO might have a big vision, but you look at how the teams are working, they don’t understand why it’s important to decouple different parts of the system. They don’t understand the concepts like DDD. They don’t understand why it’s important to decouple your business logic, your application layer logic and your UI. Like we’ve always just built these things tightly intermingled. What would be the benefit of doing that? So I think the other one’s having the skills to do that. Yeah, so the vision, the skills.
Nick Tune 00:55:09 And then the third one is probably things normally get stuck. You can get stuck in a halfway phase where you start modernizing and don’t finish and you’ve got the new bits of a new system and bits of an old system. So I think really thinking through the migration plan of how you get from A to B does it need to be fully defined upfront, but you need to really think ahead to what can stop us finishing the migration and what can we do to predict and anticipate as many of those things as possible so that we don’t end up in a state where we’re stuck halfway and the system’s more complex than it was before. And I would say one of the examples that I see a lot there is when companies have some kind of platform or some patterns where the new system can easily talk to the old system. Maybe you have an event driven architecture, and you can easily publish an event from a legacy which is consumed by the new system or the new system can publish in events and it can be handled by the legacy. So having those things able to talk to each other easily reduces a lot of the friction there I would say. But it’s not the only thing, but one of the things to think about.
Giovanni Asproni 00:56:16 So it seems to me that the last point maybe is kind of lack of appropriate planning really. It’s like when you say when you talk about not being stopped halfway finding big risks that we have not anticipated. So seems that people don’t take the time to actually plan.
Nick Tune 00:56:36 It’s partially planning, but it’s also around discipline. Once we start this thing, if someone tempts us to build a new product feature, we have to be really disciplined and say we’re halfway through this migration from the old to the new. We currently have a lot of complexity. It might be even more complex. And before we started, because we have a new and old data in different places, this UI shows one price. This UI over here shows a different price. We want to avoid this synchronization issues which can happen when we mid migration. So it can be planning but it can also be, as I was saying, discipline to not diverge from the plan or to not make too many concessions.
Giovanni Asproni 00:57:20 Okay. And how can we increase the chances of success then?
Jean-Georges Perrin 00:57:25 Going back over your series of questions here, I’ve been lucky, I would say enough that I’ve been in projects where modernization was always a success, but it was not always the expected goal we set at the beginning. Okay. But as Nick was saying, you’ve got to be very careful and not to having like two systems that runs in parallel. But my experience, maybe I was lucky enough, is that we always managed to bring incremental value even through modernization. Okay. So, and that’s I think something to keep in mind because yes you can have this big planning and I agree that for some project you don’t have a choice having this major planning. But if you are good at Agile, you don’t always have this, you’ve got a roadmap, but you don’t have a second-by-second planning. Right. So I think that here you can still combine that with incremental added value to your modernization like for any project.
Giovanni Asproni 00:58:25 Yeah. Nick, anything to add to this?
Nick Tune 00:58:29 I agree. I think it’s always going to be an ongoing balancing act. You just need to make sure that it doesn’t balance too much in the way of new product features and you don’t do any modernization work and you’re stuck in this halfway state. I work with people a lot and we often talk about modernization and they’re going to get something out of this, but they don’t want to do it. It might be an engineer or a customer support person and they’re like, yeah because the last one didn’t finish. Now I have to use three systems and not two systems. So not finishing can have big consequences. So, the key thing is to make sure we do keep making progress. Either we don’t do it or we finish it, but we don’t want the worst thing, which is to be stuck halfway and have this Frankenstein system.
Giovanni Asproni 00:59:15 I’ve worked in several of those systems to help fixing them. I’ve experienced with, especially big banks at these things like that one system. And then they said that they needed to modernize them, create a completely new one, and then there had two systems to manage and then they said the second one was not good enough and create the third one. And then they have three systems in production. Okay guys, so now I think we’ll it’s time to wrap up. I think we’ve done a quite a good job introducing architecture modernization. So thank you very much. Was there anything we missed that you’d like to mention?
Nick Tune 00:59:34 Exactly, exactly that.
Jean-Georges Perrin 00:59:54 Don’t forget the data.
Giovanni Asproni 00:59:56 We wonít Thank you, Nick and Jean-Georges for coming to the show. It’s been a great pleasure for me. And this is Giovanni Asproni for Software Engineering Radio. Thank you for listening.
Nick Tune 1:00:00 Thank you.
Jean-Georges Perrin 1:00:09 Thank you, Giovanni.
[End of Audio]
Steve Smith, founder and principal architect at Nimble Pros, joins host Jeff Doolittle for a conversation about software quality. The episode begins with a discussion of why software quality matters for businesses, customers, and developers. Steve explains some patterns and practices that help teams design for quality. They discuss in detail the practices of testing and quality assurance, and the conversation wraps up with suggestions for fostering a culture of quality in teams and organizations. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes NimblePros * Refactoring to Patterns by Joshua Kerievsky * (“On The Criteria to be Used in Decomposing Systems into Modules” by David Parnas * “New is Glue” blog post by Steve Smith * Code Complete: A Practical Handbook of Software Construction, Second Edition by Steve McConnell * OWASP OWASP Foundation, the Open Source Foundation for Application Security * Lean Software Development: An Agile Toolkit* by Mary Poppendick * W. Edwards Deming (Wikipedia)
From IEEE Computer Society “Research on Software Quality Assurance Based on Software Quality Standards and Technology Management” * Software Quality: From Theory to Practice * Increasing Software Quality through Design Reuse * Can We Really Achieve Software Quality? (IEEE Software) * Open Source Software: Communities and Quality (IEEE Software) * Quality Metrics in Software Architecture * “Software Quality Assurance” (Computer* magazine)
Related Episodes* SE Radio 616: Ori Saporta on the Role of the Software Architect * SE Radio 602: Nicolas Carlo on Improving Legacy Code * SE Radio 574: Chad Michel on Software as an Engineering Discipline * SE Radio 461: Michael Ashburne and Maxwell Huffman on Quality Assurance * SE Radio 407: Juval Löwy on Righting Software * SE Radio 357: Adam Barr on Code Quality * SE Radio 280: Gerald Weinberg on Bugs Errors and Software Quality * SE Radio 262: Software Quality with Bill Curtis
TranscriptTranscript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was psychometrically generated. To suggest improvements in the text, please contact content@computer.org and include the episode number.
Jeff Doolittle 00:00:33 Welcome to Software Engineering Radio. I’m your host Jeff Doolittle. I’m excited to invite Steve Smith as our guest on the show today for a conversation about software quality. Steve is founder and principal architect at Nimble Pros. Steve has over 20 years of experience building custom software solutions using Microsoft technologies and speaks internationally to software developers about ASP.net, domain-driven design, design patterns, solid programming principles, and how to improve quality through refactoring. Steve, welcome to the show.
Steve Smith 00:01:04 Hi. Thanks for having me.
Jeff Doolittle 00:01:06 So glad you’re here. I love that your bio mentions quality as something that you’re passionate about, which is exactly what we’re here to talk about today. And so, from a high level, we’re going to talk about how quality relates to design, to testing, to culture and other key aspects of that concept. But I want to start with asking you, why does software quality matter and how did you come to care about it?
Steve Smith 00:01:27 I started caring about software quality because I wanted my software to be correct. I wanted it to work and not have too many bugs. And early on in my career I was building a product and it was an ad server because we had an advertising network of developer websites and I wanted it to work, right? I wanted to serve the ads properly and not crash and not slow down other everybody else’s websites. And so the idea that if there was anything I could do to make it so that it was right the first time and I didn’t have to go rebuild it or revisit it, was very important to me. And we’ll talk about this in a moment I’m sure, but one of the things that I realized very early on is that if you can automate the quality checks of writing automated tests, that’s going to get cheaper and cheaper because of Moore’s law over time. Versus if you have to have manual testing, that’s going to get more and more expensive because developers and even QA personnel tend to be more and more expensive over time. So it just made sense as a business owner for us to focus on that type of building quality in approach.
Jeff Doolittle 00:02:28 Absolutely. So why do you think some people sometimes may be resistant to quality related practices?
Steve Smith 00:02:36 I think mostly it’s the idea that you can go fast and the whole like move fast break things. Thing from the west coast I think has to do with some of that. Like if you move fast and just make a mess, then eventually that’s going to come back to haunt you, right? This whole technical debt metaphor we could talk about where you’ve left this big mess and it’s either going to get in your way or you’re going to have to spend even more time cleaning it up because it’s such a mess than it would have taken to just kind of clean things up as you go. And there’s imagine that instead of building software, you’re like running a kitchen or running a machine shop. Like if you just left a mess everywhere, it would make it much more difficult for you to serve a quality product. And that happens in our industry too.
Jeff Doolittle 00:03:17 Absolutely. So where does quality start in the software development lifecycle in your experience?
Steve Smith 00:03:22 I think it’s important to have a really good idea of what you’re building. Something I like to say is that as software developers we fail in two ways. Either we build the thing wrong or we build the wrong thing. And building the wrong thing is incredibly common and generally more expensive of a mistake than just implementing something incorrectly.
Jeff Doolittle 00:03:41 Absolutely. But as far as where it begins, I mean, are we talking about when you start coding, are we talking about when you start putting issues in the backlog or are you talking about like where does quality actually should it be entering into the minds of people who are building software?
Steve Smith 00:03:55 Yeah, so to make sure that you’re building the right thing, I’m thinking it goes to, even before you enter things in the backlog, it’s this conversation about what is the overall product that we’re trying to build? What is the problem that we’re solving for users? Lead with that, make sure the developers understand that this is why you’re building this, this is the problem it’s solving. Many times developers don’t have that connection. They never talk to an end user or they don’t even have any idea of how this thing is used. And there’s plenty of stories about developers that build things that work great for them, but don’t necessarily work for their users, right? Maybe they’re building a web application and they’ve got a huge desktop monitor and it works great there, but most of their users are on their phone and the developer never tested on a phone. Things like that where you really want to understand how it’s going to be used and the problem it’s going to solve even before you think about how to write the code for it.
Jeff Doolittle 00:04:44 Do you have some examples you can share? Maybe one example where you’ve seen a lack of attention to quality that’s negatively impacted the ability to deliver some systems?
Steve Smith 00:04:53 I see this pattern a lot with clients of my company Nimble Pros because this is one of the things we focus on is helping customers that are in this position where some founders build a system, either they’re self-taught developers, or a lot of times they’ve outsource development to oftentimes offshore teams that are able to quickly build software. And for the first year or two or even three, they’re cranking out code and they’re getting new features and they’re starting to get some customers and they’re starting to grow. And by year four they notice that everything is slowing down and they’re in firefighter mode all the time. And at first they attribute it to, oh we grew too fast, we have too many customers maybe we need to focus more on DevOps or infrastructure or things like that. But even after attending to that in many cases, and I have a few customers like this right now, things just get so slow that they can’t ship new features.
Steve Smith 00:05:40 And the reason is that the developers went super-fast, but the reason why they were fast is because it was copy paste, copy paste, copy paste, oh we need another feature. Copy paste that one we had, oh it needs to be a little different. Well just change this one a little bit and we don’t introduce any commonality or way to do in a single way, right? We don’t follow any of the principles like separation of concerns or the dry principle, which don’t use that religiously, but there are times when it makes sense not to repeat yourself. And so you end up with systems where like, hey we need to change how sales tax works, but we’ve implemented purchasing stuff in literally 10 different places in this website and they’re all like huge, complicated messes that are almost the same but not quite. And so now just that simple thing of changing how sales tax works becomes like a three-month project where it would’ve been an hour in the first year of the systems development. So that’s super common.
Jeff Doolittle 00:06:31 But Steve, someone in a suit will say we never would’ve gotten to year four if we had thought about these things in year one.
Steve Smith 00:06:37 I think that’s myopic, myopic. I’m not sure.
Jeff Doolittle 00:06:40 Yeah, Well I agree, but I’m just saying what somebody will probably say. Right? So how do you respond to that?
Steve Smith 00:06:45 There’s a mantra that if you go slow, it helps you go fast, right? So like moving deliberately instead of rushing around is the better way to have consistent progress. One of the things that tests will do is keep you from going down rabbit holes, trying to chase bugs that you didn’t even know you created in parts of the system that you didn’t think you were affecting. Catching those regressions very quickly. And it doesn’t take long for that to pay for itself, right? And so if you work on building quality early on, it’s like having a ratchet on a strap or as you’re climbing, right? Every so often you’re climbing up a mountain or a rock wall and you tie into that new spot. So if you fall, you only fall down from that spot, you don’t fall all the way to the bottom.
Steve Smith 00:07:26 Right? And so does that take you more time than just free climbing the wall? Yes. But does it make it so you’re much less likely to die as a result? Yes. So these are the things where it’s a risk reward calculation and sure some startup founders might say we don’t need that because we just want to get market share and prove that we have a market and there’s something to that. But if you have developers that have the skill to build software with tests or with quality, I believe, and I’ve seen it, that they can go just as fast or even faster writing high quality software than they could just cranking out some stuff that they consider themselves to be low quality.
Jeff Doolittle 00:08:02 Yeah. And that speaks to culture, which we’ll get to in a little bit I believe. Because when you start talking about the kinds of developers you have and what their capabilities are, that’s obviously going to have an impact on how much you can deliver quality software.
Steve Smith 00:08:14 Yeah, definitely.
Jeff Doolittle 00:08:15 Before we get to that, let’s shift gears a little bit and let’s talk about design, which is something we mentioned before we started recording is designing for quality is something that people have to consider. So maybe speak a little bit to what that means in your experience and then let’s talk a little bit about how principles of good design improve software quality and maybe what some of those principles are in your experience.
Steve Smith 00:08:37 Sure, there’s pull books on principles for quality. One of the ones that I use a lot is separation of concerns. And that can mean different things. Like it’s kind of vague what are concerns, but in many cases it’s technical concerns. Like you want the UI and say persistence to not be coupled to your business logic. In a lot of legacy applications, one of the ways that teams might go faster is just put a whole bunch of logic in store procedures because they’re easy to change and you can even change about runtime and you don’t have to worry about that pesky source control thing in many cases, right? But that eventually can come back to bite you. So, keeping business logic out of the database will allow you to more easily switch up databases. And there’s plenty of folks that’ll be saying, oh that never happens.
Steve Smith 00:09:18 We never changed our production database. Well sure, but you might want to change your database in different environments, right? When I run it on local host, maybe I just want to spin up a cheap SQL light database or something and when I run it on a staging environment, something else in production, something else. And so, having that flexibility makes it so you unlock a lot of different ways that you could run the application in different containers or different scenarios in your build pipeline, et cetera. Different regions. Yeah, yeah. In different regions, separate concerns is huge. And then the other flip side of that if you think about a lot of developers when they think about the structure of a system, you think about these horizontal layers. If you visualize like a user interface layer on top and then it talks to like a business layer of sorts and then some kind of data access layer, right?
Steve Smith 00:10:02 Well then the other side of that is these vertical slices where a feature is a vertical slice through that whole thing. Keeping those as separate concerns also from one another and organizing your code so that pretty much all the things you need for a given feature are organized in a way that they’re easy to find and located near to one another helps as well. The solid principles I think are often a good guide. Things like classes not being too big. So having only one responsibility, the open closed principle so that you can change the behavior of something that I haven’t actually changed the code that leads to a practice that I really like to share with developers, which is when you’re working on big maintainable legacy systems or unmaintainable legacy systems, right? One of the ways that you can make them more maintainable is to only add new classes with new code in them.
Steve Smith 00:10:50 Don’t go in and change thousand line long method and make it 1100 lines by adding another conditional to it. Create a new class that has the new condition in it and instantiate that and call it maybe from that thousand-line long method. But now you’re not making the problem worse right? Now you’re, you’re starting to make it so that things are, are smaller and more easy to follow. And that new class, maybe that one’s unit testable even if that other big method wasn’t. And so open closed principle is about that. It’s about being able to create new implementations of things rather than having to do surgery on stuff that’s already there. And then the dependency inversion principle is huge as a way to keep your code from being too tightly coupled to its infrastructure. Code that’s tightly coupled to infrastructure is often extremely difficult or impossible to unit test. And so you have to resort to integration tests or manual tests which are way slower and way more expensive. So yes, you still want to do some of that for sure, but if you can unit test all your business logic without having to rely on infrastructure, you’ll go a lot faster and you’ll have a lot more confidence that your business logic works correctly.
Jeff Doolittle 00:11:52 Absolutely. I call that separating infrastructure from implementation, which I think is what you’re saying. And then you can touch your business logic directly and get a lot of value out of that. And to your point, you do want to test the infrastructure and do full integration tests, but if that’s all you have, you’re going to have some issues, right? Any other principles of good design that’s, so far, you’ve mentioned separation concerns. Talk about solid principles anything else you’ve seen in your experience that are principles that have improved software quality?
Steve Smith 00:12:18 Don’t repeat yourself, which I mentioned earlier, the dry principle which is very similar to once and only once, which is older, extreme programming principle. But the idea that things that should have only one rule or one setting in your system should only live in one place, should only exist in one place. So that, if you need to change it, you only have to change it in one place. You never have to go change like, oh I made this change to something, now I have to go touch 20 different files. Like that change the fact that you’re having to go do shotgun surgery on your system and change it in 20 places is telling you that hey, you really should have just put this in one place and had those other ones all reference it somehow.
Steve Smith 00:12:55 And that reminds me of new is glue, which is a blog post I wrote a long time ago. But the idea that in your code you’re newing up some dependency, you as a developer every time you do that, say in your head new is glue because you’re gluing your class to that specific implementation of that other class. And so much of the time that’s not really what you want. You want to be loosely coupled to that thing and if you use dependency injection or some other technique right, then you can keep that coupling looser and not glue your code to that other code. So I definitely use that one a lot as well. I will point out that you can’t just dry all the things because every time you do remove duplication, you introduce coupling. You had these 20 different things all had a copy of the same code at that moment.
Steve Smith 00:13:38 They were all not coupled to each other. They could all evolve independently and maybe they should maybe that’s the situation where they should all be separate from one another. And if you make them all the same, you introduce a method that they all call now. Right? Then the challenge might be that a week later one of them needs to change and since you collapsed it all into one method, how are you going to do that? Well we’ll add a flag to the method and say, well if it’s this case do this other thing and now you’re got this tightly coupled method, everything calls, it starts to become this complex mess of if logic like no, take the one that needs to be separate and distinct and don’t have it call the method anymore, right? And just have the special code that it does be in that one place, not commonly with all the other ones.
Jeff Doolittle 00:14:16 Yeah so a couple things have come up here, which I think are even more abstract than some of those design principles, but I think they’re a good starting point. You’ve mentioned coupling is one and I think sort of inherently cohesion has also come out of that as well. And also to do a lot of what you’re describing requires people to consider encapsulation. So let’s talk about those a little bit and how they relate to quality coupling, cohesion and encapsulation. What happens to your software when you don’t consider those things and what impact does that have on quality and when you do consider them, why does it improve quality?
Steve Smith 00:14:45 Sure. So a really good book for coupling and cohesion that’s kind of a classic at this point is Steve McConnell’s Code Complete from back in the nineties. So I would recommend that for folks that haven’t read it, coupling refers to how things call one another or how they reference one another. And you can have loose coupling or tight coupling and your system is going to have coupling, right? It has to if it’s going to do anything useful. And so it’s not a matter of like coupling is bad, it’s like you want to make conscious decisions about where it makes sense for you to have tight coupling to certain things and, loose coupling to others to the extent that you can. You want to have your system be loosely coupled to the infrastructure and the environment in which it finds itself running, right? 20 years ago we weren’t anticipating docker containers as a thing, but now they’re commonplace, right?
Steve Smith 00:15:29 So having that ability to ship around executables in a stable environment using containers is an example of something where having loosely coupled code makes it really easy for you to swap out different infrastructure just as a different docker container but only if your code is written in a way that it could talk to something else, right? And if your code is hard coded to always talk to, let’s say a local SQL database, then it’s going to be really difficult for you to change that up. So using abstractions as a way to make your coupling looser and say I depend on a contract, I depend on an interface and abstraction, I don’t depend on the implementation that can be swapped out at runtime makes your code much more flexible and kind of future proof. Now you could also argue that YAGNI comes into play there.
Steve Smith 00:16:10 Like you don’t want to overly abstract things, but for basic stuff like what’s the UI concerns, what’s the data concerns, having that minimal level of abstraction I have found to be extremely valuable. Now cohesion is kind of related to coupling, but cohesion is basically how related are the things within some module or some class, right? So if we’re talking like object-oriented programming, you’ve got a class, it’s got a bunch of fields and a bunch of methods. If it has three fields that are used by two methods and a couple other fields that are used by a different other couple of methods, then it’s almost like you have two classes inside of one struggling to break apart because they’re not cohesive, right? And so if you can split those up, it’ll usually lead to a better design. I work a lot with C# and .net and for the last 15 years they’ve been mostly doing MVC, Model View Controller patterns for their web frameworks.
Steve Smith 00:16:58 And it’s super common, and I know this is true in other languages that use these patterns as well, for controllers to be super large, super wide, right? Bloated and that’s a cohesion problem, right? Like you’ll go into a controller, it’s got like 10 different action methods, and you look at the constructor for all the dependencies and it’s got like 30 dependencies that are injected. You look at any one action method, it’s using three, four, maybe five of them, but it’s not cohesive at all and you’re ending up having to inject all these things even for action methods that don’t need most of it. So splitting those up into end points is something that I do to try and make things more cohesive, more single responsibility. Those two kinds of go hand in hand. Single responsibility, principle and cohesion. And then what was the third thing?
Steve Smith 00:17:39 Encapsulation. What’s that? Oh, encapsulation is like one of my favorite topics and the idea with encapsulation is simply that you don’t know how the sausage is made on the other side of a call, right? And so its information hiding and the implementation details are not something you know or care about. And by leveraging encapsulation it makes it, so our designs are much better. It’s necessary for any kind of modularity, right? We wouldn’t be able to use plugs into the wall for electricity without encapsulation of everybody can design a cord that’s a certain thickness and has prongs in a certain orientation and if they do they can plug into this interface and get power at a way that works for them. And they don’t have to worry about, well am I talking to solar power? Am I talking to a generator? Am I talking to the grid? Am I talking to a battery? Like, doesn’t matter as long as it’s AC or DC or whatever that needs and, certain specs of that power, it’s happy and it’ll work. Our code operates under these same assumptions. So if you can code to an interface, a specification that says what you need and how you need it and not exactly how it’s done, your code is going to be more modular, which makes it more maintainable.
Jeff Doolittle 00:18:50 In my experience. There are two hard problems in software engineering, their information hiding and dependency management. And I think that’s kind of where we’ve landed here. because a lot of those design patterns have to do with how you manage your dependencies. You mentioned dependency inversion, things like that, like that design pattern and then information hiding. I really appreciate that you connected encapsulation with information hiding because a lot of people I don’t think know that they are connected. And I’ll point our listeners to the 1972 paper by David Parnas called On the Criteria to be Used in Decomposing Systems into Modules. And for 52 years we’ve had the answer to how to hide information properly within systems. But so many people are unaware of how to do it. So I’d really encourage people to spend more time looking into that. But for the purposes of this conversation, Steve, speak a little bit to kind of wrapping those back into how to cohesion, coupling encapsulation relate to quality in case that’s not really clear to listeners at this point.
Steve Smith 00:19:44 Yeah, I think one of the things that helps to demonstrate quality is to know that your code does what it’s supposed to do, right? Now how do that your code does what it’s supposed to? Well you run it and you go through the application, and it looks like it’s supposed to look, right? But that takes a lot of time and if you’re having to do that over and over and over again, like that’s eating up your productivity. So if there were a way to automate that, then you could know and have confidence that your code does what it’s supposed to do and it’s not enough to know that it does what it’s supposed to do once. Right? Every time you make a change you want to still know that it still does what it was supposed to do. So, the short answer is like having some automated suite of tests gives you confidence that your code still does what it’s supposed to do.
Steve Smith 00:20:23 Could the test be wrong? Yes. Could other things go wrong with that? Yeah, it’s not infallible, but in general, having those unit tests gives you this check and in a fast, cheap way to know that things are working the way they were supposed to at the time that you wrote those tests. And so that’s huge. I have also found that there’s a huge overlap between the Venn diagrams of unit testable code and what I consider to be high quality loosely coupled code. They’re almost the same circle, right? And so if you maybe don’t have time to write unit tests for whatever reason or, this particular code is not something that you’re too worried about, you’re just going to knock it out and you don’t have to have a hundred percent test coverage, that’s fine. But if you still write it in a unit testable way, then it’s still going to be high quality code in terms of being easy to test, easy to change, not tightly coupled the infrastructure, et cetera.
Steve Smith 00:21:13 And so later on if it becomes more complex and you find yourself scratching your head about, well why isn’t this working? I thought this was simple, now you could write a couple tests and prove out what it’s doing. I find that writing tests is the best way for me to understand what my code is doing. And there was a conversation I had a few months ago on Twitter about folks that use the debugger all day long versus folks that almost never do I very rarely use the debugger. Usually, I’m debugging a test to figure out like why is this test not doing what I expect? But because I have all these tests, I know what the code does, I don’t have to debug through it to figure it out. Legacy code from a new client that I’ve never seen before. Yes, I’ll use a debugger to kind of step through and see what’s going on. But for code that I’ve been writing, and I’ve got a bunch of tests for, I find I don’t need to jump into the debugger nearly as often.
Jeff Doolittle 00:21:55 So to summarize that, what I think you’re saying in general is testable code tends to have loose coupling, high cohesion and good encapsulation.
Steve Smith 00:22:04 Yeah. So it doesn’t necessarily have to have good encapsulation, but yes.
Jeff Doolittle 00:22:07 Tends to.
Steve Smith 00:22:08 Tends to, yes.
Jeff Doolittle 00:22:09 Tends to. And knowing what the interfaces are between things can make things more testable as well because you’re now depending on abstractions instead of concrete implementations, which hearkens back to the design patterns we were speaking to before.
Steve Smith 00:22:20 That’s right.
Jeff Doolittle 00:22:21 So you talked about legacy systems, and I do want to shift gears and talk a little bit more about testing and quality assurance. But let’s start there. Let’s start with a lot of our listeners are dealing with brownfield systems and maybe they’ve heard of the strangler fig pattern and things like this that Martin Fowler talks about in his website and I’m sure others have spoken to as well. But where do you start with introducing quality practices into an environment where maybe those have been lacking?
Steve Smith 00:22:48 Well I would start with source control. Believe it or not, there are some clients out there that aren’t using source control. Some companies and teams and occasionally they come knocking on our door. So the first thing we do is we get them on GitHub using Gits if possible because that’s our best recommendation for that and have some source control. Like now you’ve got source control. That’s table stakes, that’s great. Next step is you want to make sure that stuff works on someone else’s machine besides yours. And the easiest way to do that is to set up a GitHub action or an Azure DevOps whatever they’re called pipeline or team city or whatever you want to use for your CI server and build the thing on another machine, right? That tells you that, this thing isn’t dependent on some setting and your registry or some, dependency that only you have installed.
Steve Smith 00:23:30 And goes a long way toward making sure you, you don’t have the works on my machine syndrome. That a lot of times you run into once you have that and your initial CI script is just build the code, then you add build the code and run the tests, right? And ideally the most important tests to run are your unit tests because they’re going to be the easiest ones to put in your build pipeline because they don’t have any dependencies on anything. So you don’t have to say, oh well I would put that in the build pipeline, but I need a database and I need a web server and I need this and I need that. Like no, it’s just run your unit tests against your package of your code. That’s it. And that should be super trivial to do in your build server and maybe initially you don’t have any tests, that’s fine.
Steve Smith 00:24:08 Now that you have the infrastructure in place where your tests matter, right? I wouldn’t lead with tests. And the reason is, if one developer decides they’re going to write tests and nobody else has bought in and it doesn’t have anything to do with their build release cycle, then those tests are going to break from time to time and no one’s going to care except for that one developer and they might yell and say, hey, you broke the test. Like nobody cares, it’s not their problem. You wanted to write those tests; you go fix them. Whereas if you put it as part of the continuous integration script that is used as a gate before your code deploys to the next environment, now when tests are broken, everybody cares, right? You got to fix that or else the script isn’t going to publish your code to the next step. And so once you have that in place, now testing becomes important to the whole team and everyone can start to get bought into the value of them.
Jeff Doolittle 00:24:53 Unless they go, and they comment out the test. But that, we’ll–
Steve Smith 00:24:57 Talk about that, that does happen sometimes.
Jeff Doolittle 00:24:58 When we get to culture, we’ll talk about that and that’s unfortunate, but it does happen. So a little bit more though about I’ve got a legacy system, and I don’t have any unit tests and we want to start testing the system. Like what would you do to start validating the at least current behavior of the system? So you could start with confidence introducing some of these changes in patterns and in testing.
Steve Smith 00:25:20 Right. Well there’s this idea of a testing pyramid where you have like manual tests and user interface tests and an integration test and then unit test. And the reason it’s shaped like that is that you generally want to have more of the things at the base of the pyramid, which in this case is unit tests and fewer of the UI and manual tests. It may be in a legacy system that is not very unit testable. And so you may have, they only have like manual testers and that’s it. Maybe they’re using playwright or some other thing to automate some UI tests, right? Take whatever automated tests you can find or quickly write and put those into the build process as soon as you can. And then you’ll almost certainly be able to find some places where you can do unit tests, right? Pure functions that just rely on their inputs and give you some output as a result are always unit testable.
Steve Smith 00:26:03 And there’s usually a way that you can find some places in the code where you can extract something out and turn it into a pure function, right? Maybe it’s that if statement that’s like seven lines long and test a bunch of different random things like take that if statement, put it into a pure function that says, if some good name for what that condition really means and put all that other logic in it. And now you can write a whole bunch of unit tests that say, hey, if I have this and that and the other, it should be true. And if I have that and the other, it should be false, right? Those are your first unit tests, they’re like pick the easy things that you can pull out and then you just kind of grow from there. You want to refactor, and we haven’t talked about refactoring yet, but you want to refactor that legacy system to make it easier over time to test.
Steve Smith 00:26:40 And ideally when you’re refactoring you want to have some tests and initially that might just be manual tests or UI tests. But as you progress you’ll start to have a larger and larger suite of unit tests that are helping you. And the thing to remind yourself or the client or the team is that you didn’t get here in a day, right? Usually you have many developer years of effort went into building this legacy system with no idea about tests or code quality even necessarily, right? And so now we are going to start to turn the ship but it’s a big ship and it’s not going to turn quickly. Right? Or for another metaphor, like if you have neglected your health for 20 years and now, you’re overweight and not as fit as you would like and you decide to go to the gym like a week later, you’re still going to be pretty much high the last 20 years of footy, right? It’s going to take some time to change the direction there and it’s the same for your code base. If your code base is unfit, it’s going to take a while for good habits to move it back into a fit course.
Jeff Doolittle 00:27:38 I will point out for people just getting started too, one of the things I’ll often recommend is, especially now with a lot of the advanced CICD and things that you can do, even with GitHub actions, you can spin up docker containers to do some of those infrastructural pieces that you need in order for some large scale infrastructure tests to run. And so I just encourage people don’t run away from making a legacy system testable, even if it’s integration testing. While you need to have a larger quantity of more focused unit-oriented tests, you should still also be able to test the whole system and there are ways to do that. So definitely want to encourage people to still do that if they want to improve the quality of a legacy system.
Steve Smith 00:28:15 Yep. I agree. Definitely being able to put a database in a container and spin that up as part of the CICD process is great.
Jeff Doolittle 00:28:20 It’s amazing. You can get RabbitMQ running in those if you want to test your maybe using mass transit or something like that for a message bus. Thereíre all kinds of things you can do now with Docker that were a lot more challenging to do even just 10 years ago, definitely 15 years ago.
Steve Smith 00:28:35 Yeah. One thing I’ll point out on that before we move on is separate your tests into different projects if you can or have a way to run different kinds of tests at different times. I usually will separate unit tests and integration tests at a minimum, mostly because of speed. I can run unit tests; I know in any environment whether it’s locally or in a pipeline and they should all run in seconds. Whereas if we are talking about standing up docker containers in a GitHub action or in a pipeline, a lot of times it’s going to have to pull in that docker container and that’s going to take time. Not to mention even just running the test and then resetting the state of that infrastructure. So those integration tests will probably take minutes, not seconds. And so you’re not going to want to run those in the same scenarios necessarily. And if your test suite always takes 12 hours to run, it’s not as useful as a test suite that takes five or 10 minutes to run. And so you want to be able to at least split those out so that you get the fast feedback from the unit test and then in a pipeline somewhere that maybe it takes 10 or 20 or a half an hour, right? You get the full suite of integration and functional tests.
Jeff Doolittle 00:29:35 Absolutely. And multiple ways to do that. Right. You mentioned different projects, you can also with attributes you can just like segment and say these are integrations.
Steve Smith 00:29:43 Some way to be able to run them separately.
Jeff Doolittle 00:29:45 That’s right. That’s right. But again, and doing both, but that ability to have the quick feedback is absolutely super helpful for teams and I think for legacy teams who start to have that experience too, it can become addictive, in a good way. Like in a healthy positive way, right?
Steve Smith 00:29:58 So a good feedback loop you can with certain tools, like I typically use Visual Studio, but there’s other tools you can do it from the command line in the .net ecosystem where you can just have the test run continuously, right? So there’s live unit testing as a feature in, in the IDE, but even at the command line you could say .net watch test and it will just, every time you change a file it reruns all the tests. So, even if you’re using VS code on a Mac and don’t pay Microsoft anything, like you’ve got this feature where you can be seeing your unit tests running continuously as you save one line of code.
Jeff Doolittle 00:30:28 That’s right. Well I use VS code on a Mac, but it doesn’t prevent me from giving Microsoft money for other reasons. But that’s a whole another topic of conversation. So let’s switch gears a little bit to dive a little bit deeper into testing and how it relates to quality assurance. And to kick that off, first question, are there any misconceptions that people have about testing?
Steve Smith 00:30:45 I think there’s maybe the, just the misconception that it’s really hard or if you don’t have it, it’s hard to get started. Like if you’re the developer on the team that wants to try it, that it is this big uphill journey to try and get buy-in from everybody to add a class that runs some tests. Like it’s not a big deal and you can start it on just your machine and see how it’s useful to you don’t even check it in, right. Just keep it locally and then when you at some point you’ve got a bunch of them, and you can show everybody else how great they are then you can kind of reduce the fear or the concern about how big they are. because for folks who have never done it may seem like this scary thing, right?
Steve Smith 00:31:21 Just because it’s not in their comfort zone. So being willing to just step in and try it I think is huge. The other thing that I find is a good way to get teams to start using tests that aren’t used to it and kind of change that culture is for bug fixing. Right? So if you have a rule that says bugs are not closed out as fixed unless there’s a test showing that that bug no longer exists, then if that’s the only time you ever write tests, your code is going to start to get much better quickly. Because guess what? All the places in your code that are most error prone are going to be the ones that have the most tests in a very short while. And that’s going to force you to refactor that code to be looking at that code, trying to improve it and of course adding tests to it to make sure that the next change you make doesn’t break and introduce a regression that you already fixed last month because now you’ve got a bug fix test in place.
Jeff Doolittle 00:32:08 Yeah. That’s the aha moment for me when I first started testing years ago was when we found and we started doing exactly what you said it was, okay, if a bug is found, the first thing you have to do is actually you have to have a test that fails. That proves the bug exists. Once you have that, then you have to change the code to get the test to go from red to green. Yep. And the real aha moment was when one of us on our team did that and something else that had been green turned red and we went uh, and we caught it. Yeah. And it was fantastic because now we weren’t playing whack-a-mole and having a customer tell us, hey you fixed that but you broke this. Which is the worst. It’s a morale killer.
Steve Smith 00:32:45 All your tests just paid for themselves in that moment.
Jeff Doolittle 00:32:47 They did. And this was years ago, and it was when we were just getting started. But it was fantastic just to have that the whole team went ah, like okay. It’s like yes, this is now I get it.
Steve Smith 00:32:54 This is why people talk about this.
Jeff Doolittle 00:32:57 This is why we do this. Well and it’s funny too because it’s how the real-world works. I mean you don’t build an automobile and just crash test it, right?
Steve Smith 00:33:03 Yeah.
Jeff Doolittle 00:33:04 You tested fuel pumps; every component was tested.
Steve Smith 00:33:05 Yeah.
Jeff Doolittle 00:33:07 And you tested materials and you like going all the way back up the supply chain. You’re testing every aspect of the supply chain so that when you put the car together, and I think this is something that you’ve probably realized too, is crash testing the car is not quality assurance. That’s quality control. Sure. Yeah. Well, testing your UI when you’ve already built the product is not quality assurance. That’s quality control. Right. And quality control is important, but it only tells you that you missed some serious problems you need to go back and fix. But it doesn’t fix any problems.
Steve Smith 00:33:34 Right. That best it to detect them.
Jeff Doolittle 00:33:36 Yeah. And that’s another misconception I think people have. How about this one? What are your thoughts on code coverage? Like, we’re going for a hundred percent on everything. Like is that
Steve Smith 00:33:45 For a lot of legacy systems, I like to just see code coverage going up. And that’s what the team maybe gets some additional confidence around. And for really big systems, right? It’s going to start out at like 0.01% because you added like one test, right? And then over time it starts to grow. I am not concerned about a hundred percent code coverage. I want to test the parts of the code that are important if they aren’t working. And almost always that means writing tests for things that have conditional logic in them. So a key metric that I use is psychomatic complexity measures, but only on the, on the method level. If you try to apply it at class or higher level, it doesn’t make any sense. But at the method level, if you can keep psychomatic complexity down like under 10 and for folks that don’t know that, there’s a good definition of Wikipedia, but it essentially, it’s like how many different ways can logic flow through this method?
Steve Smith 00:34:34 And so if you have an if statement that says it’s either this or it’s that, then you have two ways, right? It’s going to hit one side or the other of that if statement. And many times we’ll find in legacy code the psychomatic complexity of some of the, the most important parts of the system in the hundreds for a method. And that’s just insane, right? Because you really want to have a test for every one of those cases. So you would need like hundreds of tests for that method to fully exercise it and you could get to a hundred percent code coverage on that method way before you covered all the different combinations of paths that might lead through it. So keeping that low pays big dividends. So that, that’s pretty much where I try, and focus is not so much on a particular percentage. More is usually better, but only if it’s interesting code that you care if it fails or, or that it could fail, right? I don’t test properties — in .net, C# code, we have properties as a built-in feature; they work. The language team proved that they worked. So I don’t have to write a test for that’s already been tested. That’s not necessary.
Jeff Doolittle 00:35:30 No, that’s interesting you correlated that too with conditional logic because that makes a lot of sense. That’s where you’re going to find those edge cases or things like that and that’s where it might make sense to say we’re going to aim for a hundred percent coverage on this conditional thing. Maybe before we start refactoring it and trying to fix it. Because we want to have confidence as ref refactor that we’re at least not regressing and making things worse than they were when we found them, for example.
Steve Smith 00:35:54 Even things that aren’t properties that just have only one code path through it. Like you, you extracted out a method that does four things and it’s just some helper method that has no if statements in it like it does those four things like there’s no other way it could possibly go. So you don’t necessarily have to test that method. You probably test the method that calls it but you don’t necessarily have to test that separate method.
Jeff Doolittle 00:36:16 Yeah. That actually goes back to another design principle we didn’t mention before, but command query separation from, I think it’s from Bertrand Russell. The idea that a method should either change state or report on state but not do both at the same time. And that’s another one of those principles that people can consider when they’re trying to make their systems more testable, for example. Because if I know this method’s going to change state, then I’m testing this state change and if it’s only going to report on state, then I’m just testing that it’s in the appropriateÖ
Steve Smith 00:36:43 Result to expect or whatever.
Jeff Doolittle 00:36:44 Yeah, exactly. Exactly. So that can help as well. Any other misconceptions? Maybe people have, we’ve covered a few, but a lot–
Steve Smith 00:36:49 Of folks get hung up on mocking and some folks think that the only reason that you would ever have an interface in your, in your code or an abstraction is because it allows you to mock things for your test. And sometimes that’s useful, but that’s not the primary benefit or reason. I think too many folks kind of go down the rabbit hole with mocking and I look at their test and like one test method is like 50 lines long and the first 40 are setting up all the mocks. Like, that’s indicative that you have a problem with your code that you’re trying to test. And it’s like way too coupled to a whole bunch of dependencies and things. So if you can refactor the code so it doesn’t need that. And ideally try and use as many pure functions as possible. So because those are easy to test, you’re going to have a much easier time with testing. So don’t be afraid to mock a couple things here and there. If it makes it easier to make a test for something, but if you find that you’re spending an inordinate amount of time trying to deal with and set up mocks, that’s a smell that’s telling you your design could be improved.
Jeff Doolittle 00:37:41 Yeah. You mentioned before like a controller that might have 13 dependencies injected into it or something like that. And then if you are trying to test that control and you have to mock out all 13 of those things, or to your other point, if you’re only testing one method on it, but it only needs two of those 13 things and you only mock those two something’s telling you that maybe you should refine your design as opposed to just continuing to go down this path of complicated mock setups and things of that nature.
Steve Smith 00:38:09 Right. Another common thing I see, especially for folks new to testing is they don’t treat the test code like real code in terms of trying to refactor it and keep it clean and maintainable. So really common one is just the new keyword again I talk about new is glue. Like if you have the new keyword newing up the system under test in every single test for a certain class and later on this big very important class has 50 different unit tests and every single one of them instantiates it and then you’re like, oh, we need this dependency, add it to the constructor, great. Now you’ve got 50 tests you have to go fix because every one of them says, oh, I don’t have a constructor that has that thing. Don’t do that. There should be like one place in your test suite where you instantiate the system under test and then all the other tests use that. And just by doing that one simple thing, now when you make changes to the system under test, it’s less painful, it’s less friction. You’re not going to be resentful of having to make a change because oh, now I have to go fix all the tests. Right? Like no, make your job easier. Make it so you only have to fix that one place where you instantiate that class and not every place that you have a test for.
Jeff Doolittle 00:39:09 Yeah. We had Chad Michelle on the show a couple months ago and he wrote a book called Lean Software Systems Engineering for Developers. It’s a mouthful, but one of the concepts from the book, I really appreciate how they put it, they call it designed for change. And I think that’s exactly what we’re all trying to do and we’re trying to avoid that pain as we should. Sometimes changes are painful, but we can make them less painful. And when we designed for change then it just makes everybody’s lives better.
Steve Smith 00:39:33 Right. Yeah.
Jeff Doolittle 00:39:35 So let’s talk about testing best practices. So what does a robust testing strategy look like in your experience for a software development team?
Steve Smith 00:39:44 One of the things, speaking of teams and I know we’ll get to culture here in a little bit, but something I often find as a problem in teams is that they have a separate QA team from the developers. And almost always I find it’s better if we’re able to integrate those and have QA on the team with the developers, building the test as part of the iteration or sprint and working side by side with developers on automating tests and other things. There’s that first off, if you’ve got a separate QA team, that’s only a hindrance in my experience, assuming that you’ve got folks that are invested in quality and in writing tests on the team, then the way I would approach it for legacy code is to start with some tests that are probably high level and do like playwright tests or UI tests that prove the most important things work.
Steve Smith 00:40:30 Maybe these are like smoke tests that you run right before you go to production. Can the user log in? Can they add items to their cart? Can they check out with a fake credit card or whatever. Because those might be the most important things that the application does. And so once you’ve got some of the minimal stuff in place to give you some confidence that the code works, then you work down from there. And like I said, I’m a fan of writing unit tests for the business logic where the most important complexity lives. And so start to write tests for that. If you can’t write unit tests, write some integration tests for that, but eventually you want to get the code into a state where you’ve refactored it to where the business logic decisions live independent of the infrastructure.
Steve Smith 00:41:07 And now that unlocks the ability for you to unit test those which pays huge dividends. When business logic changes, which it often does on these legacy systems, it’s like, we want to ship a new feature or this regulation changed, or we need to add another payment provider. We need to change how sales tax works because we just started. We have a customer in Brazil now and they have a whole different set of laws like that stuff’s going to happen. And if everything is just hard coded and coupled together and directly into a database or whatever, those are really hard to do. And the first one or two might not be too bad, you’ll just add some more if logic in there. But after 10 or 12 locations and strategies and different approaches, it becomes a big spaghetti code mess and suddenly all your progress direct grinds to a halt.
Jeff Doolittle 00:41:48 What about other kinds of testing, like performance testing and security testing? How do those relate to quality in your experience?
Steve Smith 00:41:54 I think those are important, but it’s a different skillset. I think performance testing. I’ve done talks and courses on performance testing and measuring performance and scalability with load tests and things. Not all companies have the resources for that and a lot of times it’s more of a, if the customer’s telling you this page is slow, that’s when we need to worry about that. And in that case before you go doing performance tuning, it’s just like when you are going to fix a bug, you should have a test for it. You should have a test that demonstrates that the performance isn’t satisfactory so that when you tune it, you can rerun that test and say, look, I fixed it. Right? It’s a bug that it’s not fast enough. So treat it like one and write a performance test for that and then you’ll know when you’re done.
Steve Smith 00:42:35 Because otherwise it’s really hard to say when you’re done performance tuning and developers can spend an infinite amount of time trying to make something a little bit faster when really you get the biggest bang from some low hanging fruit like adding caching or adding an index and you don’t have to go and like try and tweak how every method is called and whether or not it’s on the heap or the stack. Like most of that doesn’t matter when you’re talking over the network to a database or a distributed system. Security is definitely important and there’s third party tools you can use to like scan your code for known security issues. I would encourage every developer to keep an eye on the OWASP website, which kind of lists like every two or three years they list a top 10 of security problems.
Steve Smith 00:43:13 Definitely keep an eye on that and understand how to look for those. One of the biggest ones remains SQL injection. So make sure that your site is not taking in user input and using it to build queries against your database. That’s still one of the biggest risks out there, so at least be sure you’re not introducing those into your system. But then there’s also a place for third party security audits from time to time, where folks that that’s all they do can come in and take a look at your code for a week or two and give you a laundry list of things that you could be fixing. And that’s probably more effective for most organizations than trying to have all of their developers be up to speed on every security exploit all the time. Because I don’t think that’s tenable.
Jeff Doolittle 00:43:49 Yeah. And we don’t have time to get into in this episode, but I think it does somewhat relate to quality. We talk about something like threat modeling and actually considering the threat vectors for your system and what your strategies will be for mitigating or eliminating those threats. Which again that I think relates to quality because if your system can be hacked and taken over, I think you’ve got some serious problems there.
Steve Smith 00:44:11 Sure. Things that are quality related to that too are, the more modular your system is, the more places you have where you can insert additional functionality. For instance maybe initially you don’t have any way to know what an attacker did if they get into your system because you don’t have any logging, right? Well you can easily add a bunch of logging in, like decorators or chain of responsibility pattern or, or behaviors Instead of having to go touch every single service and every single controller and every method and be like, hey, enter this method. Hey exited this method. Like there’s ways when you write your code using good patterns that you can get that type of behavior across the board. Or do a security check as some middleware across the board. Without having to go do surgery on every part of your application.
Jeff Doolittle 00:44:55 Absolutely. In fact, I forgot to mention it before, but I’ll mention it now. One of the first books I learned on refactoring things to make them more testable, and that’s not the title of the book, but the title of the book was Refactoring to Patterns by Joshua Kerievsky. And I’ll put a link in the show notes, but for people who are wondering how I take that nasty if L switch case statement that’s got a psychometric complexity of a thousand and start cleaning it up. Books like that I think are a good place to get started. Giving you some creative ideas like you mentioned chain of responsibility pattern, again, we’ll put a link in the show notes, but just giving people creative ideas to think about, oh, maybe there’s other ways to reduce the complexity in this code and make things more understandable and also more testable, which improves the quality of the system overall. Let’s talk about building a quality culture. So I know you do a lot of consulting and you help companies to improve their development practices. So what in your experience does it take to help build a culture of quality in a software company?
Steve Smith 00:45:48 I mean, that’s a big topic. There’s, there’s whole books on that. There’s a great book that I would recommend that the technical leadership in those companies read, which is Accelerate, which has a bunch of scientifically proven things that you can do that lead to better impacts and outcomes for your software process. You’ve probably talked to people on this show about that book in the past, so I won’t get into it too much, but that would be a good place to start is the practices that are outlined in that book and the buy-in that it’s not just voodoo magic and some consultant coming in because they get a paycheck saying you should do this. No, this is scientifically proven practices at this point. And so getting that buy-in from leadership is usually an important first step because it’s difficult to do change in an organization from like the individual developer individual contributor up the stack.
Steve Smith 00:46:35 But if the technical leadership buys into this, then that can help. Now the next step is how do you get those individual contributors on board? And that can be a challenge, right? A lot of folks will be eager to learn new things, eager to write better code, eager to work on a system that’s more modular and isn’t the big, tangled spaghetti code mess? Other developers maybe they’re later in their career and they’ve been working at the company for decades and they’re like I don’t really see a need to change. I’ve been doing this for 20 years and it’s always worked for me. And that can be more of a challenge. So ideally you get everybody on board and if you can’t, then sometimes you reorg a little bit and you have like developers that aren’t as interested in learning these new techniques are put on teams or put on code that they can be successful in without having to if that’s possible.
Steve Smith 00:47:17 Sometimes it’s just a matter of changing your team and maybe you make sure that the next few developers you hire all have the same mindset that you’re looking for. And sometimes unfortunately you do have to let other developers go that don’t. But that should be a last resort. And ideally you can bring everybody along and those developers that have been there for a long time also have a ton of understanding of how that legacy system works. So you definitely don’t want to lose them just because in the first week they don’t jump up and down to do unit tests. So I think those are like two ends of the spectrum, right? The management leadership side, the individual contributor side. If you can get the team to be self-empowered to the point where they can decide how they’re going to achieve some of these things, that can help a lot, right?
Steve Smith 00:47:56 So it’s not just dictated from on high the CTO says we will now have code coverage of a hundred percent period, or you’re fired. Like that doesn’t change the culture and it doesn’t necessarily work great because it doesn’t take long for developers to figure out that they can write one unit test that iterates through all the classes in the system and hits all their properties and then returns through like, hey, you just got almost all the code coverage with that one test. Like, did it do anything useful? No, but your game in the system and developers are usually pretty good at that. So it’s more important that you show the results that you’re going for than that you have some arbitrary metric that may be difficult to hit.
Jeff Doolittle 00:48:30 Absolutely. Let’s pay people by lines of code. Yeah. The adage is, and if it can be measured, it will be gamed and to your point, right? Developers are really good at that. Yep. This does make me think of a concept, I don’t think it’s in his book, but Yuval Loi, who’s a trainer of software architects, he says that you should have zero tolerance for defects. And that doesn’t mean you necessarily have zero defects because sometimes defects up through, but you use zero tolerance. If a defect is found, stop the presses, we’re fixing it, we’re going to eradicate that defect,
Steve Smith 00:48:59 Right? Yep. And that’s a lean principle stop the line.
Jeff Doolittle 00:49:02 Stop the line.
Steve Smith 00:49:02 Jeffrey Palermo a friend of mine, I don’t know if this was his original quote, but he said something that resonated with me, which is that if you have a process that produces defects, then you have a defective process.
Jeff Doolittle 00:49:12 Yeah, I like that.
Steve Smith 00:49:13 I like that. That’s very related.
Jeff Doolittle 00:49:14 Yeah. Well, and let’s talk about pull the cord because may maybe not everybody’s familiar with what you’re talking about.
Steve Smith 00:49:20 Sure. So there, there’s a great book by Mary Poppendick called Lean Software Development. It has some principles, but one of the key practices that Lean follows in manufacturing setting is that if there’s a defect, you stop the line, meaning stop the assembly line, everybody stops work. And you don’t just fix that one defect, you fix the thing that allowed that defect to happen. So that defect never happens again. And in software that mean you write a unit test that says that bug is fixed and it won’t happen again. Or you change the build pipeline so that you actually run the unit test or whatever it might be that would make it so that that failure that you’ve just discovered, you don’t just fix it, you fix the things that led to it being possible and then now your process is slightly better for the next time.
Steve Smith 00:50:00 And if you do that consistently, you’ll go faster because you won’t have to keep fighting fires. Most folks that are dealing with legacy systems have management that’s trying to go faster and the Dev team and DevOps team are just trying to put out the fires as fast as they can and they don’t have time to even think about system quality because they’re too busy just dealing with all the bugs and critical issues that are happening all around them. And so you want to build that quality in so that you never get to that state where it’s constant firefighting.
Jeff Doolittle 00:50:25 I’ll point listeners too, if you’re interested to dig deeper into this. Edward Deming, who’s the father of total quality management was responsible for the Japanese transformation of Toyota in the 1950s. Basically took over the world. A lot of this Lean and these kinds of principles comes from what they called the Andon cord, which is a white cord that anyone on the factory line could pull, even the janitor. And if they found there was no defect, this is the fascinating thing, if they found there wasn’t a defect, they still rewarded the person for pulling the cord. Because what they cared about, and I think this is really pertinent to our industry these days, is all of these different methodologies and things we have, which we’re not going to get into now because we’re talking about quality. But it really, in my experience, Steve, and I wonder if this gels with yours, it boils down to continuous process improvement. Whatever methodology you have or whatever practices you have, if you’re not doing CPI, I’d question whether what you’re doing is really helping you or not. What are your thoughts on that?
Steve Smith 00:51:17 Yeah, I would definitely agree. There’s various agile maturity models and things, and a lot of folks don’t like that term maturity in there. But if you look at those, you can see where organizationally and the processes you follow, there’s things that are steppingstones to getting better and better. Like I was saying some teams don’t even have source control, right? And if you don’t have source control, there’s a whole lot of activities that you can’t even start to think about doing until you get that in place, right? And then I was big early on in our discussion about continuous integration or CI most people just say CICD now is like this buzzword that I hear. But very few teams are actually doing the CD part, which is continuous delivery or continuous deployment.
Steve Smith 00:51:57 And to get to continuous delivery deployment requires a whole additional set of capabilities in your team and in your, in your DevOps to be able to support. Like generally you’re going to have to have support for feature flags. You’re going to have to be good at trunk-based development. And that’s not something necessarily teams understand or use or aware of on the first day. Right? And so this idea that you’re continuously improving your process, some of that is going to be novel and unique to you and your team and your org. And some of it is going to be, these are well understood steppingstones in the industry that we know that we can get to. And again, I’ll point people at the Accelerate book, but being able to get to being at the point where you can do continuous delivery where every time someone checks something in, if it goes through all the gates and passes all the quality checks, it’s live like that is kind of like the epitome of where you can get with your software process.
Jeff Doolittle 00:52:46 Absolutely. And I think that’s the idea of the continuous, it’s like wherever you’re at right now, you’re continually improving your process. And then of course there’s metrics and tracking and things like that that all matter. Do you have any specific example of a team or someone you were, you don’t have to say who of course, but where the improvements in quality had such a market impact that it was just like amazing.
Steve Smith 00:53:08 Sure. This is kind of working at it from the other end. So, and I like to tell this story for folks. One of the things that I think helps a lot is shipping more often, right? We just talked about CD, continuous delivery. I think that’s crucial, but even if you can’t get to that, at least doing it more frequently can almost certainly help. There’s a principle or a quote that I’m not sure where it’s from. That’s if it hurts, do it more often, right? If your process of shipping software right now is painful, it will get less painful if you do it more often. So I had a client a few years ago, they would ship software whenever the product manager felt like it was worth shipping. Right? If it had enough features in it that users would benefit from it, then well it’s fine, we’ll schedule a release.
Steve Smith 00:53:46 And so this worked out to be about every six or eight weeks and every time they did this, their software was used seven days a week during business hours. So they would have to deploy at three o’clock in the morning on a Tuesday and make sure that hopefully it worked, almost never did. Right? So there’d be several attempts to deploy between 3:00 AM and 5:00 AM and usually by 8:00 AM they could get the thing working enough and they might still have a few little minor things they’d fix like the next day on Wednesday they might get at 6:00 AM and do a couple more little tweaks. And so I was trying to convince them that you should really be deploying more often, right? Well the developer team, all of whom had to get up once every couple of months at three o’clock in the morning and their families who didn’t really appreciate that either, they didn’t really want to hear from me that, hey, we should do this more often.
Steve Smith 00:54:31 But what I started them to do is for about six months they would record every time they deployed and when that happened and whether or not it was successful, right? And it was successful if you didn’t have to roll it back and you didn’t have to immediately fix some bug that you discovered in production, right? And then relate that to how long had it been since the last deployment. Right? And very quickly you look at the data and it says, if it’s been more than an hour since the last deployment it’s never successful. Right? Or maybe a day, right? More, if it’s been more than a day, it’s never successful. But if it’s been less than a day, it’s almost always successful. And so what we got them to do is start shipping again on Thursday.
Steve Smith 00:55:08 Right? Not much has happened, right? It’s still not the same code that it was. Okay, now ship again on Tuesday. Right? And so they started shipping every Tuesday and Thursday and they found that it wasn’t that hard, it didn’t take that long. If something was broken, they knew exactly what it was because they just did it. And now they’re shipping over a hundred times a year. They don’t necessarily feel like they need to get beyond that, like that’s working for them. But it’s made a huge difference in the quality and the speed with which they’re able to move because they aren’t spending so much time trying to figure this out. And now they deploy it lunchtime, right? It’s not a big deal. So no one’s getting up at three o’clock in the morning and it’s been a huge quality of life improvement for the development teams as well.
Jeff Doolittle 00:55:45 Yeah. I remember that transition in one of my companies years ago as well where everybody was afraid to deploy on Fridays, right? And so we switched the narrative and we said we’re always going to deploy on Friday no matter what. And it only took a few months and next thing, there were never any weekend interruptions anymore. Right. And nobody was afraid to deploy on Friday anymore because of all the things you just described. Yeah. When you have those quality practices, those gates, those tests, those everything in place and suddenly you’re like, oh yeah, this is no big deal. We do this all the time. And it’s transformative.
Steve Smith 00:56:14 If you do it more often, it’ll force you to improve it. If you only, do it once in a blue moon, it’s not worth it to fix it. Because you only do it once in a blue moon. But if you’re doing it a couple every week or a couple times a week, like, wow, we better get better at this, we better be more efficient.
Jeff Doolittle 00:56:26 That’s right. And when you’ve only changed three things instead of 300, it’s more likely you’re going to be able to figure out what went wrong and fix it quickly instead of combing through and finding a needle in a haystack. And I think as we wrap things up, that kind of speaks back to culture as well. What kind of company do you want to work for? Do you want to work with one that’s afraid to make changes? And anytime they do everything breaks and you’re staying up late at night and that creates stress. And that leads to all kinds of problems. At the extreme end, it literally leads to ends of relationships and ends of lives. And so quality matters.
Steve Smith 00:56:58 Quality matters. And working on a code base where everything is modular, there’s tests for things, you’re able to check stuff in and all the tests pass and the code just goes through like there’s no stress, right? Or there’s minimal stress. Things don’t fail that often, itís a night and day difference versus legacy code, no tests, lots of manual testing, lots and lots of cross your fingers and pray whenever you do a deployment. It’s way more stressful in that environment than in the one that I would prefer to work in.
Jeff Doolittle 00:57:26 Absolutely. So as we wrap things up, if people want to find out more about what you’re up to or maybe even ask you some more questions or get your help in improving their quality practices and their company, where should they go?
Steve Smith 00:57:36 Sure. So you can find me online as Ardalis, just about everywhere. That’s spelled A-R-D-A-L-I-S. And so because my name is Steve Smith, it’s really hard to get a username that has any combination of that with consistency. So I’ve been Ardalis online for over 20 some years. You can also reach out to me through my company, Nimble Pros. That’s like Nimble Professionals. And we’re happy to talk to you about your questions, about how to get better as a team or how to write better software or assess the software that you have and see what are those low hanging fruit that we could tweak that’ll get you most of the of the games that you’re looking for.
Jeff Doolittle 00:58:09 Cool. Well Steve, thank you so much for joining me on the show.
Steve Smith 00:58:11 Thank you. It was great to be here.
Jeff Doolittle 00:58:12 This is Jeff Doolittle for Software Engineering Radio. Thanks for listening.
[End of Audio]
Sriram Panyam, CTO at DagKnows, discusses SaaS Control Planes with SE Radio host Brijesh Ammanath. The discussion starts off with the basics, examining what control planes are and why they’re important. Sriram then discusses reasons for building a control plane and the challenges in designing one. They explore design and architectural considerations when building a SaaS control plane, as well as the key differences between a control plane and a data plane.
This episode is sponsored by QA Wolf.
Show Notes* Microsoft Azure Guide to Control Planes * Blog: buildmage.com * LinkedIn: @SriramPanyam
Related Episodes* SE Radio 519: Kumar Ramaiyer on Building a SaaS * SE Radio 499: Uma Chingunde on Building a PaaS
TranscriptTranscript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact content@computer.org and include the episode number.
Brijesh Ammanath 00:00:51 Welcome to Software Engineering Radio. I’m your host, Brijesh Ammanath. I’m here today with Sriram Panyam to talk about SaaS control planes. Sriram is the CTI diagnose previously, Sriram has grown and supported multiple high performing and deeply technical engineering teams at Google Cloud, LinkedIn, and several startups both in the US and in Australia. Sri, welcome to Software Engineering Radio. Is there anything I missed in your intro that you’d like to add?
Sriram Panyam 00:01:19 Hey, thanks for having me here. No, you were spot on. I’m looking forward to chatting and sharing and learning.
Brijesh Ammanath 00:01:25 Let’s start with a brief definition of SaaS and its growing market importance.
Sriram Panyam 00:01:31 Yeah. So if you think about your favorite applications, especially in the last 20 years, you had the rise of this whole web 2.0 movement. Actually, let’s go back even before that. You had your traditional enterprise applications. Companies would create something, they would deliver it to users. Users would use it usually with long, long development and deployment cycles. It came with its own costs and nuances. And after circa 2005 onwards, there was a rise of the whole lip 2.0 movement. Where applications would be developed in a more agile way, there would be more consumer focused. And obviously, web being the main delivery mechanism meant that companies could iterate faster, collect feedback faster, and delight their users in a much more, iterate faster fashion. Now, I don’t work for Slack. I’m in no way affiliated with Slack, but I find Slack is a very good example of this.
Sriram Panyam 00:02:32 Your typical chatting applications, WhatsApp, Facebook Messenger, they’re your typical consumer applications. You have one instance as far as the user can see. There’s one giant global instance. You would send messages, you would read messages, you would two other things in those applications. Now, enterprises felt there was a need for those applications within a more closed or bounded domain. How about just messaging within enterprises? How about just messaging maybe within a collection of enterprise or collection of teams? So if you look at Slack, Slack is a classic enterprise SaaS offering or a B2B offering, which is really popular. And it forms a good example of how you differentiate SaaS and non-SaaS offerings. Now, in a SaaS offering, it is really a business model. If you think about what it means to be SaaS, I think there are many definitions, but the key principle is it’s a business model and it’s a delivery model that really is driven by what the business needs.
Sriram Panyam 00:03:40 Technology is common or is used in in most applications. But how is important? One key thing is actually when you want to, I mean a lot of successful companies that offer SaaS products, they believe in the idea that they have to adapt to what the market needs, what the customers need, and what the competition is doing. So a lot of SaaS companies are looking at trying at new pricing models, newer market segments, looking at new customer needs. Now, there’s also the need for onboarding being frictionless. Now, yes, onboarding onto the older or traditional consumer applications was frictionless. You had your Auth, you had your signup sign or login that’s tied to a customer. But here, really your customer is the enterprise. While you may not have freebie and visibility to the end enterprises individual customers, you want to make sure that enterprises themselves can onboard onto your application with the most frictionless way possible.
Sriram Panyam 00:04:44 So this has to be important. You can’t just say, Hey, look, we’ll set up a few boxes with Slack running in a bunch of nodes in your data center manually each time. Can you imagine how long that would take? Can you imagine how long it would take to roll out fixes deploy new, new features? So all this has to be frictionless. And you also have, especially last 10 or so years, regulatory and compliance has been a huge, huge influence in how enterprises want to adopt your offering. In fact, there are so many regulatory environment requirements like sovereign clouds and data residency that demand that their application data compute all reside in a single geography. For example, again, I picked Slack as an example. Slack is owned by Salesforce, which is an American company. Yes, it is global, but it’s headquartered in America.
Sriram Panyam 00:05:42 A government organization in Germany might have strict demands that all instances of Slack are running physically in three or four locations in Germany. So you need to ensure that happens. And again, a lot of the innovation doesn’t just come from the user interface. Those are premium things. There are customer features that do get rolled out, but these kind of compliance enterprise business needs being taken care of is a primary motivation for the innovation. And also the usage scale varies. I think WhatsApp customary competitive offering to Slack, again, not in the same thing, I think does, has about a billion daily active users each sending a thousand, 10,000 messages. I mean, maybe that’s messages a day and they have to be globally available. Like I would have a WhatsApp instance. I would log into WhatsApp, for example, chatting with my family all the way in India or Australia.
Sriram Panyam 00:06:39 And they all have to be available at the same time with something that’s more enterprise like Slack or Slack’s. Enterprise offering those particular global demands could be softened. I might require that my employees are all based in a single geography. So as long as they communicate, I’m good. So these are some of the things that differentiate SaaS versus your traditional consumer offerings and how you build the teams around this. Those are influenced how you build your stack around this that has influenced how you look at metrics, how you look at your product, road mapping, how you look at, I wouldn’t even say culture, like your team culture, all that’s influenced. So that’s why SaaS offerings themselves, SaaS as a business model is growing quite fast. And will be doing so for the next foreseeable future. I think, and these stats keep changing all the time. An interesting stat I found was that in US alone, the SaaS market is around half a trillion annually. And globally, there are between 25 and 50K SaaS companies that are offering various centers services to various enterprises.
Brijesh Ammanath 00:07:47 Interesting. Let’s move into the topic of the session, which is SaaS control planes. Can you give a definition of what a control plane is and why it’s important?
Sriram Panyam 00:07:58 Right. We started with Slack as a motivating example here. And you can think of this for almost any application that an enterprise need that needs. So what is a control plane? If you look back to networking, the terminology arose from the networking era. You had your data centers, there’s data centers would have switches. Switches would connect to N number of routers. And routers would offer a bunch of networks. The idea was you wanted some kind of connectivity from one part of the world. That’s the physical connectivity going through some kind of logical networking to another part of the world. Now, at the start, these are all pretty much physically placed, physically created. My career started off as a network designer in Australia’s largest telecom called Telstra.
Sriram Panyam 00:08:54 And my job was to design how to structure customer racks within a data center for their needs. And a lot of that involved and planning was a huge part of that. You would kind of ask them what the applications were for what was the typical usage pattern of the application, what kind of ingress, egress in terms of bandwidth needs they would need. And you would decide, okay, look they’ll need X number of switches, Y number of routers. This is kind of given this kind of isolation between their own topologies. They might need so and so number of networks. Now, obviously, and this was I think early 2000. As the Web 2.0 movement took on and scale was growing, orders as a magnitude, and I exaggerate on a weekly basis.
Sriram Panyam 00:09:42 Doing this physically or manually was just not possible. Take for example, Google, and this is just me doing back of the envelope numbers. If you had to handle the traffic that Google itself serves, what happens inside Google is actually larger than what happens in all of the internet outside. I mean, if you think of that or put it in the way, Google’s internal traffic, among the services amongst thousands and hundreds of thousand services is greater than the amount of traffic that the rest of the internet sees outside. And that’s a staggering fact. So you can’t provision these networks manually. You have to have some way where these networks can be provisioned declaratively. So this whole idea of a highly connected cross switching fabric came up. And again, as a summary, what this gave you was the illusion of every network being connected, sorry, every node in any network in the world, being connected to any other node almost directly.
Sriram Panyam 00:10:46 It wasn’t directly, obviously. It would be through a bunch of hops, but you would change this network topology using software, and that’s where this whole software defined networking came. And the thing that would change these routing rules, not necessarily on the fly on a second-by-second basis, but on a reasonable timeframe, that stack or that part of the stack was a control plane. So, yeah. So how does all this networking stuff apply to SaaS? I mean, we’re talking about something that’s eight layers above the networking stack. So what does the networking stack have to do with control planes and SaaS. I mean, networking Slack is layer one, two, maybe three. The application is four, five layers above that. Now, the idea is the same.
Sriram Panyam 00:11:31 If you look at again, our favorite example Slack. I think Slack has something like 15 million daily active users as of 2023, 2024. Again, my numbers are rounded up. Now Slack also has about, I think half a million, enterprises on it. 500,000 enterprises roughly. Even if you say that, look, most traffic Slack is going to come from top 1% of enterprises. Now, let’s say 500K, 1% is what 5,000 enterprises are contributing to this 550 million daily active users. Again, these are just my back of the envelope numbers that I’m messaging. So we’re looking at 5,000 enterprises contributing to 50 million daily active users. And even if you say, look a typical active user, if you define an active user as someone sending, let’s say, a thousand messages a day, we’re looking at 50 billion messages being sent a day.
Sriram Panyam 00:12:38 And that comes to about, I think, half a million messages per second. And again, using some very, hand baby math, if you assume that for every message you send it is being read by 20 users, in all these channels you already have for half a million messages being created, about 10 million reads of those messages, that’s staggering per second, by the way. And that’s a staggering number to serve this, you’re looking at anywhere between around 10,000 compute nodes with about 10 terabytes of memory, give or take. Now, more interesting here is that you can say, look, it’s only 10,000 nodes. Let’s just bring up a giant instance of Slack and be done with it. Now imagine 10,000 nodes serving 500,000 enterprises globally. That’s your classic shared model where every enterprise is being served out of the same stack.
Sriram Panyam 00:13:38 Where is the stack running? Is the stack running globally? Is the stack running in some data center in North America? Is it running in some random configuration? Now, we talked about how enterprises have these requirements on how they want their applications to be isolated. And then isolation is the big, big motivation for what we are talking about. If it was a single application cluster that you deploy, create and deploy once, we don’t need a control plane. What customers want is to be able to say, look, I want to stack, imagine if you’re Uber. Uber says, I want to stack, my usage is predicted to be this. I want to make sure that my availability is so and so, which means that if I’m sharing a cluster with 499,000 other users, then it’s pretty much all or nothing availability mode.
Sriram Panyam 00:14:33 If that cluster goes down, every customer’s affected. As we can see, that forms the motivation of why you want isolation. Now, the going the other extreme, if you say that, look, every customer gets their own separate cluster. So these 10,000 nodes are serving you know 5,000 customers. So two nodes for customer, rough hand review math. Then the challenge is, how do you deploy these? How do you deploy these clusters when they’re needed? Again, going back to the old networking model of a new customer comes in, they want a dedicated network. Go and design new switches and routers was great on day one, but now it’s just very cumbersome. So this is where the control plane comes in. The control plane is a piece of software or is part of the stack and shows that anything that Slack is not directly responsible for handling a new customer, it takes care of it.
Sriram Panyam 00:15:30 So what are, what are some of those things? Uber comes in, they want to use Slack. How do you onboard them? Is there a console for them to onboard quickly without having to submit a request and wait few weeks before the Slack team goes and provisions those machines and infrastructure manually. How do you handle any regional requirements? If Uber says, look, I really want to have everything in this region or these regions for, so and so availability, are we expecting them to go and manage their own custom clusters on which was installed? This could be Kubernetes or anything, but we don’t want that. Billing, we talked about 50 billion messages a day. Those that’s not even distribution of messages. If you’re charging somebody for number of messages, you want to actually measure what that’s like.
Sriram Panyam 00:16:24 Or you might just charge for a footprint. And so on. Now, Slack might even say, look, we’ll actually help you manage your user’s identity and accounts and access, ? So there’s some overlap in does that as to whether that belongs to the control plan or the data plan. By the way, the data plane is the application being provisioned or managed or deployed. I think in some places it’s also called the application plan. It is effectively the service that the end user sees. Now, what about things like, do you want to have any other specific tenant provisioning details that you want to abstract away? So this is the control plane. It is like any other service, but it helps build the different stacks and deploy the different stacks and provision different stacks and tenants for the end enterprise customer. That is the key, I suppose, definition, like one key definition to rally around. It has more nuances like how it manages data. How do you get to that ideal state? Where do you start from and so on. But you can think of the control plane as the service or the plane that manages the lifecycle and availability of the data plan.
Brijesh Ammanath 00:17:41 So just to summarize, you started over giving a brief history and how data centers, which is in routers, the complexity was managed using software, and that kind of led to the creation of a controlled plane, which is primarily there to manage provisioning, configuration, user management, charging regional deployments, and so on for the data planes or the applications. Is that a good summary?
Sriram Panyam 00:18:08 Yeah. So the idea of control planes came from the networking world. How you manage those tenant specific non end user specific concerns is what the control plane’s about.
Brijesh Ammanath 00:18:19 Can you tell me a story of how control plane helped manage complexity?
Sriram Panyam 00:18:25 I think I started off on some parts of that in the previous question. So think about what are the, what you would need to deploy Slack for, its customers, and I can talk some of the internal examples too. The reason I use Slack is because it’s a very relatable example that people just get. Well, first of all, let’s look at some of the core concerns that a control plane should really take care of. There are many, but I like think of them as metrics. How do you help shine usage metrics from the underlying service both to the administrators of that service, let’s say Slack, as well as to the developers of the service. So the control plane needs to be able to identify that, look at this instance is being used in these ways, and here are all the rich metrics data that can be captured to shine light on how different tenants are using the system.
Sriram Panyam 00:19:22 Now, you as a service developer can use that metric data to improve various parts of your, under your actual data plan offering. The other one is, how are you establishing the lifecycle of tenants, not just creation. You want to have what are called the crude operators on tenants that create, retrieve, or get update and delete tenants. When you onboard a new tenant like Uber or Apple onto Slack, what do you set up for them before they can start using Slack? That might take into account all their compliance rules. In fact an organization might actually have multiple tenants. For example, someone like Apple might say, again, this is not based on any particular examples, but just general observations around different SaaS deployments. So Apple might say, look, for my AI team, I will need this entire Slack instance for these set of users who are primarily in North America.
Sriram Panyam 00:20:28 That’s one tenant within Apple. Or they might say, one tenant is here, a second tenant could be in Europe only for the legal area. Now, US Slack might think of Apple one customer or one account, but you might decide that they themselves, like allowing multiple tenants to be there for that one customer account is paramount for you. So now your control plane needs the notion of what is a tenant? What is an account? What is an installation? What is a deployment? Now that you’ve created these tenants, they might say, look, I have different kinds of onboarding. I would like to onboard my own user, let’s say3@apple.com or Brijesh@ apple.com. Using my internal employee IDs. Now, how can I tie up the authentication of those users? Let’s say it’s based on OAuth or TFA and so on before they log into Slack.
Sriram Panyam 00:21:19 Now, Slack as a service might give you those features for enabling different kinds of authentication, but you still have to provision different data stores so that you store that information in compliance with what our Apple needs. And that could mean Apple gets their own dedicated database of user accounts. Whereas somebody who’s a smaller startup with 10 customers might be okay with not having those strict isolation requirements. So when you onboard them, you might say, look, I’ll have 10 instances or 10 different tenants running on the same internal, like my own Kubernetes cluster where I’m deploying Slack. So this kind of managing of onboarding and resources for those on onboarded tenants is, is key. Now, an admin user interface can be two different things here. One is as the overall Slack the company offering. You might have an interface to monitor and observe the different tenant installations.
Sriram Panyam 00:22:16 It could also be an admin interface for the tenant administrator. So somebody at Apple or somebody at your, let’s say diagnosed might be the administrator for their respective accounts. So things like logging and looking at operational behaviors and be able to manage that environment. If they want to upscale, what does that mean? And upscaling could mean, hey, look, I expect that I’m going to have, instead of 10 users, I’m going to have a thousand users. So I’m saving that. Now Slack, you go and take care of provisioning without me caring about those details. So now Slack, the control plane will say, look, now that I know this user, let’s say this user is going from a small, a very small instance of 10 users to a large instance of thousand users. Maybe they got funding, they got acquired, they and so on.
Sriram Panyam 00:23:04 Now, I need to make sure that I move that instance from a shared host to its own, for example, Kubernetes Cluster and the Slack control plane is responsible for doing all that without the end user noticing that this is happening. So now it has to manage this kind of updates, the update part lifecycle. And the other important thing that we talked about is identity, like identity authentication. How do you make it so that the end user does not have to manage these accounts manually, but they can use your offered features as part of the control plane to have a seamless onboarding with an onboarding. And what I mean by that is, there’s the first enterprise onboarding like Apple, Uber level, and then the individual customer, individual employee or user on onboarding. Last but not least, I think billing is a key thing.
Sriram Panyam 00:23:57 Ultimately you are doing a, I mean, you’re selling, I mean, you’re in business because you want to turn a profit. Or you want to have certain growth or financial goals that you want to meet. And without loss of generality, let’s say you want to make money, and ultimately the large part of billing is knowing how you are charging your customers on some metric. It could be based on subscriptions; it could be based on usage. And you want this building to be fair and transparent. If you go back to that V 0.0 0.1 where we said, hey, what we have 10,000 nodes running Slack. Every Slack Enterprise customer is in part of that shade cluster. How do you know which customer had how much usage that you can build them fairly for? So building being robust and available and not being consistent and available is important. So these are the core features that control plane should be responsible for as soon as possible. Now, you can do this in different ways. You can do this through a solid approach, a shared approach, a completely isolated approach, both on the data level and service level, and they have different implications. And we can talk more about that.
Brijesh Ammanath 00:25:15 You talked about data planes. Just wanted to understand, have you come across any instance where the control plane and data plane were not separated out? And how did that evolve over time? Did it need to be separated out as the application matured?
Sriram Panyam 00:25:31 No, this is a great question. Most SaaS offerings start off as a single combined control plane, data plane offering. And what I mean by that is, let’s go back to Slack. Slack on its day one would have, and again, this is not definitely, any offering like this would’ve looked like a giant database where you might have a few tables in this database, like a user table, a chat table, a messages table, and each of these tables would have a dedicated column called tenant ID. Where you might say, for this tenant or this enterprise user, get me all chats, where the tenant ID is this. Now, what happens here is that you have single table and it’s up to the service itself to write the rules or to layer out their business logic to route across different tenants.
Sriram Panyam 00:26:28 And when you’re a new startup, this makes sense because you want to focus more on your business logic. You really don’t want to invest in a separate control plane team to handle these different customers. And part of that is also the business motivation. Because you would start off with smaller customers who are okay to be in this model. If a startup on day one acquired a large customer, then this would be the focus. Then you have your next step where instead of putting everything in a single database, single schema. You might say, look, I have my chats table, I have my messages table, I have my user’s table. Let me create a different database or a different schema for each tenant. So you might say, instead of having a messages table, I’ll have Uber underscore messages or messages Uber as my table.
Sriram Panyam 00:27:21 Or I might even have a database called Uber Database, which will have these three different tables in there. So at the code level, you might say, look as soon as they get a request, I will look at which tenant that user belongs to. Let’s say, use something like OAuth to identify what that domain is and so on. And you might say, every action from now on will go to this database. So my code is lightened at the moment, because I don’t have to choose between database on every operation I make. It has to happen at the starting point. Again, this is great because you have, you’re still sharing resources. You don’t have to worry about provisioning concerns. The only provisioning concern here is, can I create those three different tables in that customer specific database in my DB cluster.
Sriram Panyam 00:28:11 And this will go on for a while. This is fine. The downside is that, again it is shared. So if that database cluster goes down, all the customers go down. Now as you evolve, as you have customers with higher isolation requirements, you’ll start offering, you’ll start looking at, okay, how can I ensure that each customer gets their own tenant, which means that within that tenant, within that service stack or service stack deployment. The code looks at that entire stack as a single tenant. It is not aware of multiple tenants, because why would you. When you have a single stack and is isolated and is dedicated to one customer, it’s that all it needs to focus on. Now, here’s where you start thinking about how do I ensure that a control plane concern is needed?
Sriram Panyam 00:28:54 Because as the number of customers grow, you don’t want to manage these stacks manually. You don’t want to operate them manually. You don’t want to manage them manually one by one. You want to do it in automated fashion. So this kind is a typical evolution from everything in a single namespace or a single shared environment for all customers to, something in between where we have a hybrid approach of some customers could be routed based on schema, and some customers could get their own dedicated clusters, while it’s manageable all the way to a fully solid approach where every customer is either been packed into a shared cluster based on their tier, or get their own dedicated cluster based on their tier and their requirements, obviously their revenue potential too. So, yeah, this is kind of a typical evolution from day one SaaS with built in control plane, all the way to a dedicated control plane team or organization that supports the different products that company might offer.
Brijesh Ammanath 00:29:52 Thanks. We’ll now move to the next section, which is more around designing the SaaS control plane. Can we start off by, walking through a how data movement happens in a typical SaaS setup? And what are the interjections where the control plane helps that data movement?
Sriram Panyam 00:30:12 Let’s see. We caught a few things before in terms of isolation. Yeah. So let’s look at first of all how we want to think about storage and data for your, both the control plane services as well as the data plane needs in terms of storage and data. We spoke about different partitioning models. On day one, you have everything in a single database, single data store, or single data cluster. Or data namespace. And then the software is responsible for deciding which table or even which row to pick based on the tenant ID. And as you evolve to the next level of partitioning, the software has a top-level routing of which database or which namespace to pick. And then after that, you can think about a dedicated database connection that is only for a single database or a single schema being handled by the underlying code.
Sriram Panyam 00:31:04 So in a way, it’s not really tenant aware fully, but it used the different database instances. And then going the full extreme, we are talking about every customer getting their own data cluster or data namespace or database. Now they have like each of these, each of these storage partitioning schemes. Or routing schemes. They have their own approach to on how they can manage data migrations. If you look at the fully independent isolated model, the control plane can help migrate data on a pertinent basis. Because it is either moving an entire database or it’s moving an entire database cluster from one location to another. In the middle case where we said, I will assign multiple, like a unique namespace for every customer, replicating that or moving that out is a relatively easier proposition. Imagine having to filter a single database for tenants by tenant ID when you have to.
Sriram Panyam 00:32:05 That means that you are incurring a load on a single database. Now doing this in a silo, like in a silo approach. Means that you can do a continuous backup of your data or your database for that tenant and simply restart or load from that backup in the event of a handover or failure or transition from leader to follower. So the thing is, whichever strategy you pick, the control plane has to have a certain set of rules on what kind of automation’s running to ensure that this replication, bringing back up, restarting procedures taken care of. And data replication is part of this, disaster recovery is part of this. So this also affects how you have your RPO and audio targets and obviously all that’s impacted by the cost that the customer is willing to incur.
Sriram Panyam 00:33:03 The other aspect of data migration, data movement is security consideration. Obviously, when you have all the data in a single tenant or single cluster in the day one scenario, you need extra, extra security processes. Both at the business logic level, at the access level, in all parts of your stack to ensure that you don’t have data being leaked across tenants. It gets easier as you go up the isolation strategy stack. In the case of multiple databases in the same, or multiple namespaces in the same database, it’s a bit easier. In the case of multiple clusters or dedicated clusters or dedicated tenants, it’s a lot easier. It’s a lot more, easy to ensure that kind of security guarantee. The other part of data management is also billing and how you ensure the kind of ROI I suppose.
Sriram Panyam 00:33:59 When you have a single tenant, sorry. When you have a single cluster where all tenants are hosted, you are saying that the worst-case scenario or the best-case scenario or best kind of instances will be given to everybody. Whereas here, you have an opportunity to give much more fine grain access on giving the kind of instances for the customers. Customers who are willing to pay more, can enjoy better instances or better clusters. Customers who are okay with lower levels of isolation and lower SLOs, they can stay on the shared tiers until needed. So, yeah, the control plane gets more and more robust and gets more and more complicated. Because it has to manage this data movement across tiers, across security boundaries, across isolation boundaries, across regional constraints, and has to do so in a more changing environment. This demand won’t change on a regular basis, but when it does, it has to do it with minimal downtime, with minimal manual intervention and with as quick of a turnaround as possible.
Brijesh Ammanath 00:35:10 Al. Can you talk about some interesting architectural decision points and common patterns used in designing a control plane?
Sriram Panyam 00:35:20 So one thing I can share, we talked about the example of a very large company wanting multiple tenants for their own architecture. Now, if you look at this, the three models we spoke about so far, we said, look on Day 1, a SaaS offering has everything bundled in Day 5 or somewhere in between. It starts to split out the data or the data or some parts of these services into their own namespace. And then you have completely dedicated offerings for each customer. If you were to go the extra step, you can think of this as a control plane of control plane architectures. Now, imagine a very large company wanting their own isolated tenants on their own premises. Now these premises could be actual data centers, or they could be custom cloud accounts. Either customer accounts on AWS or organizations on Azure and so on.
Sriram Panyam 00:36:20 If you look at some of the large-scale data processing platforms, for example, data flow. It would provision an entire working stack or a large part of the provision working stack on the customer’s account. And that means bringing up the compute instances, the storage nodes, the GPU instances and so on the customer’s service account and running the jobs on there. So there is the control plane that clearly orchestrates their instance, and then within that you have a control plane, which is responsible for orchestrating things locally. So this architecture where you have your initial control plane that deploys under the control plane on the customer premise is pretty interesting because youíre really talking about another level of isolation and under the level of control the customer can benefit from. This obviously is pretty, it adds to complexities.
Sriram Panyam 00:37:17 Because in the true SaaS model, you’re provisioning customers offering in an environment that you’re familiar with. The moment you have to transcend that and go to a different environment, it obviously adds more scope for failures, for more challenges in terms of availability, more challenges in terms of being able to observe and monitor, and debug what’s happening on the tenant side. This idea of having control plane off control planes is actually a very interesting design choice. Now, obviously you wouldn’t do that from Day 1, it’s reserved for the ultra-sensitive customers who have those strict isolation requirements even beyond what you want to provide on your own.
Brijesh Ammanath 00:38:04 Can you tell me about any instance or any stories where something has gone wrong and how was it detected and then resolved?
Sriram Panyam 00:38:14 So at diagnosis, a large part of our footprint is around provisioning our software or our offering directly on the customer premises. So we do follow a control plane off control plane models, but at a much smaller scale. Now, the big challenge here is depending on the customer, they might have security regulations and security requirements where they may not be able to share observability data and metrics back to us. At diagnose, we offer tools for running automations for the customers in a much more frictionless way. So when we offer a shared or even a managed offering of that diagnose, it’s easy to debug them because we know what’s going wrong. When customers observe any failures, we can trace through our typical observability stack. Now, when things are going wrong on their premises, it gets challenging.
Sriram Panyam 00:39:19 So what we have done is we’ve actually enabled instrumentation. I mean, like we enabled observability stacks on those offerings as well. But because of challenges in having them export that to us, we made it so that we can only get the observability data from them when and how they choose to send it. So the downside of this is that when failures happen, they will be the first to be alerted. This requires them to have their own observability teams, or at least a small observability team to be on standby when failures happen and we train them so that they can triage these incidents and escalate to us or reach out to us after a certain tier. Now what we’ve done is we’ve made it simple for them to share these metrics to us on a more dial level basis.
Sriram Panyam 00:40:17 So, I mean, they can choose how much they want to share to us, but some customers are more particular about logs because they may hold sensitive information. Some customers are okay with sending everything. So we found that just by sending us traces and metrics, we are able to help them more secure way faster. Customers are okay sending everything even better, obviously, when they share less or they share less, even though they have the choice to do so, they have a higher time to resolution. But that’s as expected from this architecture. So the key here is when we’ve added instrumentation both in the control plane and in the data plane. Or in the application plane so that this instrumentation can be filtered on both sides, both on the customer side as well as on our side.
Sriram Panyam 00:41:06 So they have some guarantee that they aren’t leaking too many things to us, or they aren’t leaking things to us that they wouldn’t want to. And obviously as customers see that, customers that want are okay with this, they can dial this all the way to the, and have a much faster resolution and detection because we are now privy to the patterns of usage and errors on their side. So the control plane, having this variability in how it provisions and what it provisions on the customer stack and being able to upgrade that again with the full control of the customer is a very important choice that helps us.
Brijesh Ammanath 00:41:42 Do you have, or do you remember any observation or any data shared by the customer which surprised you? What were the findings?
Sriram Panyam 00:41:51 Well, I can’t share it. There’s always surprises. There’s are always surprises that turn out to be not surprising once you get to the bottom of it. Yeah, because we’ve had many customers that would obviously see a failure depending on how much they’re exporting to us. We would have visibility into what’s causing it. Again, to keep it at a very general level. We had, I can show you this. One of our customers was using one of the control plane data stores for their own data plane logging. It wasn’t so much a bug as much as a design choice, I guess. And this obviously affected their billing. Because when we build them, the billing was based on usage and not necessarily things like storage metrics. Now, obviously when storage was ballooning because of this work around or flaw, we obviously found a way to mitigate that at that point in time. But also help us learn how we can address the issue of building upfront and what kind of metering has to be in place to catch all the metrics so that, again, so we can provide a fair price to our customers. Again, this is a very simple, this is a very specific example of plane storage leading onto our control plane which we’re able to identify by observing how they’re using it.
Brijesh Ammanath 00:43:13 Are the architectural approaches different for control planes and multi-tenant solutions?
Sriram Panyam 00:43:19 The architectural approaches is different for control planes in multi-tenant solutions? In a way, you are creating a control plane to make multi-tenancy easy. Now we talked about different kinds of multi-tenancy from Day1 to Day 5 to Day a 100. Even that at logical level, the single cluster or single physical environment with all your customers, all your tenants in there, if you think about it, is multi-tenant. Now, the isolation is what has changed. As the offering grows, as the shape of the offering grows, as the scale grows, your control plane is evolving on where it is deploying this logical entity. Now, when it’s deploying yet another table or yet another tenant ID in a single database that your single stack can use, versus yet another physical cluster to be used by a tenant all the way to a dedicated control plane on the customer’s premise, your control plane is going to change.
Sriram Panyam 00:44:25 In fact, your control plane storage itself is going to evolve. You might start putting more and more things in the control plane storage. So that there are different availability guarantees. In fact, you want your control plane to be highly consistent. If you think about the CRUD operations on a control plane, your CRUD operations on a control plane will map to the CRUD operations on the lifecycle of your tenant. Going back to Slack, there are 50 billion slack messages a day. But there are only, what, 500,000 Slack enterprise accounts, even if Slack was growing, let’s say a 100% year on year, you might add 500,000 more Slack accounts or slack enterprises accounts next year. But that is still a tiny, tiny, tiny drop compared to how many messages are being sent by Slack.
Sriram Panyam 00:45:21 So it’s okay for your Slack control plane to have a higher latency, but it needs to have higher availability. So that obviously affects the choice in how you design and what kind of storage you’d use. And when you write to the storage what kind of transactionality you might want to impose at the expense of latencies. So yes, your design choices do change. Your control plane actually does change. But you have to remember, the control plane itself is much lower in footprint than your data plane, and it has to be. You want to ensure that you’re powering a scale that is odd more than what the control plane itself would see. In fact, you want your control plane to be built in such a way that even if your control plane goes down, your data plane continues to operate.
Sriram Panyam 00:46:11 Yes, you might not be able to create a new tenant but your existing tenants are still operating. You might not be able to delete a tenant, okay? That’s fine. You might not be able to change the shape of a tenant temporarily while the control plane is being brought up again. But your data plan has to be operating at a much higher level of availability because that’s what the end user is going to see. So ultimately your control plane has to enable multi-tenancy. That journey from Day 1 where everything is in one place to Day X where you have control planes or some hierarchy of that, that’s an interesting journey.
Brijesh Ammanath 00:46:54 What are the disaster recovery considerations that we need to consider when designing the control plane?
Sriram Panyam 00:47:01 We touched briefly on this, on the data movement migration aspects of this. If you think about a control plane as any other service, after all, it is a service. It’s a service that’s managing the lifecycle of other services. A control plane is going to have its own disaster recovery mechanisms because it’s going to have its own storage and data that it has to ensure. For example, a control plane storage might keep track of what is the application positioning or placement in different regions for a particular tenant. Apple, for example, has five tenants have N number of clusters in 25 different regions, maybe spread out across the three major clouds. So recording all this is a key responsibility amongst many others of the control plane. And we spoke about how it needs to have high consistency and high availability at the expense of latency.
Sriram Panyam 00:48:01 It can trade off latency for availability and consistency. So just like any other service, you might choose how you do disaster recovery by picking one or more secondary regions where you’re doing either real time or some RPORTO based replication. You might be okay if, for example, a company says, a tenant says, I’m okay with not being able to reshape in my Slack instances for three hours. And that kind of forms your soft RTO. Or a recovery time objective. So it has very similar, I mean, the ideas you would pick for disaster recovery would be similar to any other service. Now, if the application, if the data plane has its own disaster recovery requirements. For example, if the data plane or if Apple, for example, says, I want my instances or all my messages to be backed out to be replicated in three different regions in three different continents.
Sriram Panyam 00:49:04 Now you can leave it all to the service to handle, or you could provide certain plugin or pluggable some areas of pluggability in your data plane that can communicate with the control plane to make this happen. So, how the different regions for DR on the data plane are set up could also be part of your control plane concern. So TLDR control plane is a service. It’ll have its own disaster recovery mechanism, but it can also help the data plane with some of those concerns on placement on RTOIPO on setting up the different environments for the failovers and so on. So DR has a lot of similarities, has a lot of differences on what it means for control plane, but if you think of it as a yet another service, it makes the design choices more familiar.
Brijesh Ammanath 00:49:54 Thinking along similar lines, what about security considerations for the control plane.
Sriram Panyam 00:50:01 Security considerations for the control plane. Again, we can talk about the similarities if you were to think of it as yet other service. But one thing to understand is many people when they think about isolation, they fall back to authentication and authorization. This is not a wrong thing when you are in Day 1 and everything is in a single physical environment, because we talked about how the service layer is now doing the routing at the table level. By looking at a wear clause on the tenant. But again, there is very little isolation here beyond some piece of code knowing which entries to fetch in a table. But as you go up that scale of everything shared to everything, being in a hierarchy and control planes or control planes. We are talking about how the control plane enables plugging in of custom and diverse access management controls.
Sriram Panyam 00:51:06 Do you want access management to be tied purely based on OAuth? Where you would log in through your Google account, and if you have a Sri@Apple and Bridges@google.com, is that enough? Versus I don’t even want Sri@Apple to be anywhere near the physical, anywhere near a certain blast radius vicinity of Bridges@google.com. So again, you can leave all this other data plane, you can say, hey, data plane you manage which authentication domains to connect to. But the fact that the data plane is even letting you choose between authentication domains could in itself be a major security reflect, at least a security concern as far as the many compliance requirements could ensure. So you might want to say that this stack or this setup or this deployment has to be completely unaware of any other deployment anywhere else.
Sriram Panyam 00:52:06 Which means this deployment is access management hooks into Azure versus that deployment’s access management hooks into AWS’s IM facilities has to be managed, and the control plane is what can do that. And we can extend this example to the control planes vs control planes where you might say that control plane subset X only has access to help you provision on Azure. Control plane subset Y only lets you provision your deployments on GCP and so on. So again, you can expand the scope of the control plane, but it becomes a feature of the control plane now, like a feature of any other service. To give you the fine-grained isolation of the various access and authorization primitives depending on what the regulations and customer needs are. TLDR, it’s a feature, but the devil’s the details.
Brijesh Ammanath 00:53:03 What’s the role of Kubernetes in the design of control planes?
Sriram Panyam 00:53:08 So Kubernetes lets you, not as an expert, but Kubernetes lets you create clusters at scale. With ease. It’s a very simplistic definition. Now, your clusters could be regional, your clusters could be zonal, your clusters could be in different isolation boundaries that you are willing to pay for. The main idea is that it takes away the hassle of elasticity. It takes away the hassle of moving your workloads within a cluster. It takes away the hassle of being able to do all the provisioning that was much more harder and finicky before. It also comes with a lot of challenges. Itís obviously a very battle-hardened piece of infrastructure that has a whole bunch of skillsets that you need. It’s obviously complicated, but all that complexity you have, you’re able to enjoy the elasticity that you don’t have to manage yourself.
Sriram Panyam 00:54:10 Before this, you had to, I mean, even with VMs. You had to go and manage it. You had to observe it, you had to build up your auto scaling groups, you had to take care of a lot of the provisioning and deployment and rollout facilities that Kubernetes gives you out of the box. So if you think about how I would use Kubernetes to deploy either control plane or a stack or a deployment. If you go back to the day one where everything was in a single service, your Kubernetes cluster would actually first of all be an overkill. Youíre using Kubernetes to provision instead of resources, very related resources in a very tight boundary.
Sriram Panyam 00:54:59 Whereas now with managed KS offerings like EKS and GKE and AKS on Azure, sorry on AWS GCPN and Azure respectively, you can create clusters on demand. You can provision your entire stack on them on demand. So the control planeís role now would be to provision these clusters with certain limits, certain resource requirements and constraints as a customer sees fit. These clusters could also be running on the enterprise customer’s on premises. So Kubernetes makes all this easy because it’s a very unified way of having resources and compute at scale with elasticity. So it makes the Cu&D aspects much easier in your control plane that create update and delete aspects. There’s obviously a lot more to what goes on a deployment than just resources in a cluster, but it’s a great way to start off with the resource that you might need without having to incur provisioning delays and manual provisioning complexity.
Brijesh Ammanath 00:56:06 Yep. Got it. Let’s talk about some of the future directions in this space. What emerging technology do you see in this control plane space?
Sriram Panyam 00:56:16 So we spoke about control plane of control plane architecture. The idea really is how do you move the control plane responsibility or control plane benefits, or even its administration closer to the customer?
Brijesh Ammanath 00:56:30 Can you tell us about any success stories that stand out in your mind about using control planes?
Sriram Panyam 00:56:37 Yeah. So Dataflow is a really great example. Dataflow is Google’s data ingestion platform. It’s actually built on top of an internal platform called Flu. And Flu traces back its roots to the original map, use ideas. And Dataflow and Flu are both unified batch and streaming data processing platforms. Now, Dataflow itself is a highly scalable, highly available data processing platform. It processes, I believe something in the order of tens of X & Y of data across thousands of jobs a day. And again, doing very high-level numbers, its own footprint is in the order of tens of thousands of nodes across many jobs that it runs. It’s memory footprints goes to, it is not a petabytes. And this is powered by a very efficient, very scalable control plane that ensures that customer’s jobs actually run on customer’s accounts.
Sriram Panyam 00:57:46 In a highly available and scalable manner, even though it’s a managed offering and not necessarily an open-source offering. Its control plane has been built on years and years of research into high scale engineering. And if you look at other examples, I mean, even a diagnose, we don’t operate at Dataflow scale, our control plane is currently at a more hybrid approach. We are scaling towards offering control planes for our customers on their premises, which allow us to dial how much metrics we can get from the customers to help them at their own behest. And we are obviously growing and learning and applying better ideas as we improve. So again, I guess time will tell on how big and scalable it grows.
Brijesh Ammanath 00:58:38 I think that was quite insightful, Sri. As we wrap up, was there anything that we missed that you would like to mention?
Sriram Panyam 00:58:45 Yeah, there’s a lot of influence and impact on building SaaS products, on how one would structure engineering teams. Now, building a consumer platform or consumer offering, while it’s very involved and complicated. I think there are certain similarities and differences. In both, technology is fast paced, things are moving obviously with AI. There’s a lot one can do in terms of building services fast. Some of the differences could be more consumer environment. You have more deeper placement of skills. You would find that engineering teams are often specialized around certain areas for us, mainly for product engineering teams. Whereas in SaaS offerings, you might need teams that are, they have more expertise in certain domains. You might want to have teams that are very focused on cloud computing or Cloud engineering, security compliance.
Sriram Panyam 00:59:45 And these come together pulling the functional expertise in building SaaS offerings. There are challenges because doing experimentation is a bit more unified for a product, for consumer product. Because you’re looking at how you would take feedback from customer experience in a fairly homogenous way, whereas how your different customers, your enterprise customers use your product. There’s a bit more variation in SaaS offerings. Again, if you look at SaaS offerings, there’s more emphasis on enterprise features like management consoles, billing features, how you do isolation, compliance requirements. Those are a bit more pronounced in SaaS offerings, which may be hidden away from engineering teams, or they are more localized in expertise in purely product engineering teams. And also this is changing these days. The user experience requirements also change a fair bit. And again your SaaS offerings, depending on the kind of product may be more engineering led especially if the SaaS offering is a lot more engineering focused as opposed to dedicated product management needs on a more consumer product. Yeah. And there’s a lot more. But these are the main ones that come to mind.
Brijesh Ammanath 01:01:08 Thank you Sri for coming on the show. It’s been a real pleasure. This is Brijesh Ammanath, for Software Engineering Radio. Thank you for listening.
[End of Audio]
Sriram Panyam, CTO at DagKnows, discusses SaaS Control Planes with SE Radio host Brijesh Ammanath. The discussion starts off with the basics, examining what control planes are and why they're important. Sriram then discusses reasons for building a control plane and the challenges in designing one. They explore design and architectural considerations when building a SaaS control plane, as well as the key differences between a control plane and a data plane.
This episode is sponsored by QA Wolf.
Stevie Caldwell, Senior Engineering Technical Lead at Fairwinds, joins host Priyanka Raghavan to discuss zero-trust network reference architecture. The episode begins with high-level definitions of zero-trust architecture, zero-trust reference architecture, and the pillars of Zero Trust. Stevie describes four open-source implementations of the Zero Trust Reference Architecture: Emissary Ingress, Cert Manager, LinkerD, and the Policy Engine Polaris. Each component is explored to help clarify their roles in the Zero Trust journey. The episode concludes with a look at the future direction of Zero Trust Network Architecture.
This episode is sponsored by QA Wolf.
Show Notes* LinkedIn: @steviecaldwell * CTR_KUBERNETES_HARDENING_GUIDANCE_1.2 (PDF) * A Zero Trust Reference Architecture.pdf * Fairwinds blog: Three Steps to Streamlining Kubernetes Multi-cluster Management * NSA Hardening Guide: Locking Down Network Access with Fairwinds Insights * CNCF On-Demand Webinar: Zero-Trust in Practice with istio and kyverno
SE Radio Episodes* 385: Evan Gilman and Doug Barth on Zero-Trust Networks * 600: William Morgan on Kubernetes Sidecars and Service Mesh * 361: Daniel Berg on istio Service Mesh * 451: Luke Kysow on Service Mesh * 446: Nigel Poulton on Kubernetes Fundamentals * 590: Andy Suderman on Standing Up Kubernetes
Stevie Caldwell, Senior Engineering Technical Lead at Fairwinds, joins host Priyanka Raghavan to discuss zero-trust network reference architecture. The episode begins with high-level definitions of zero-trust architecture, zero-trust reference architecture, and the pillars of Zero Trust. Stevie describes four open-source implementations of the Zero Trust Reference Architecture: Emissary Ingress, Cert Manager, LinkerD, and the Policy Engine Polaris. Each component is explored to help clarify their roles in the Zero Trust journey. The episode concludes with a look at the future direction of Zero Trust Network Architecture.
This episode is sponsored by QA Wolf.
Jim Bugwadia, CEO of Nirmata and a committer to the Kyverno projects, joins host Robert Blumen for a discussion of policy-as-code and the open source Kyverno project. The discussion covers the nature of policies; policies and security; policies and compliance to standards; security scans that generate reports compared to tools that allow or deny operations at run time; Kyverno as a kubernetes service; the Kyverno helm charts; the components of Kyverno; bootstrapping a kubernetes cluster with Kyverno; installing policies; implementing policies; customizing policies; packaging and installing policies; kubernetes dynamic admission controllers; the Kyverno admission controller; securing Kyverno itself; observability of Kyverno; types of reports and messages available to cluster users.
This episode is sponsored by QA Wolf.
Itamar Friedman, the CEO and co-founder of CodiumAI, speaks with host Gregory M. Kapfhammer about how to use generative AI techniques to support automated software testing. Their discussion centers around the design and use of Cover-Agent, an open-source implementation of the automated test augmentation tool described in the Foundations of Software Engineering (FSE) paper entitled “Automated Unit Test Improvement using Large Language Models at Meta“ by Alshahwan et al. The episode explores how large-language models (LLMs) can aid testers by automatically generating test cases that increase the code coverage of an existing testing suite. They also investigate other automated testing topics, including how Cover-Agent compares to different LLM-based tools and the strengths and weaknesses of using LLM-based approaches in software testing.
Goran Petrovic, a Staff Software Engineer at Google, speaks with host Gregory M. Kapfhammer about how to perform mutation testing on large software systems. They explore the design and implementation of the mutation testing infrastructure at Google, discussing the strategies for ensuring that it enhances both developer productivity and software quality. They also investigate the findings from experiments that quantify how mutation testing enables software engineers at Google to write better tests that can detect defects and increase confidence in software correctness. Brought to you by IEEE Computer Society and IEEE Software magazine.
Abhay Paroha, an engineering leader with more than 15 years’ experience in leading product dev teams, joins SE Radio’s Kanchan Shringi to talk about cloud migration for oil and gas production operations. They discuss Abhay’s experiences in building a cloud foundation layer that includes a canonical data model for storing bi-temporal data. They further delve into his teams’ learnings from using Kubernetes for microservices, the transition from Java to Scala, and use of Akka streaming, along with tips for ensuring reliable operations. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show NotesRelated Episodes 623*: Michael J. Freedman on TimescaleDB
Patents* Converting uni-temporal data to cloud based multi-temporal data * Customized canonical data standardization, ingestion, and storage
Contact Info* LinkedIn: @abhay-dutt-paroha-79766316/
Luis Rodríguez, CTO of Xygeni.io, joins host Robert Blumen for a discussion of the recently thwarted attempt to insert a backdoor in the SSH (Secure Shell) daemon. OpenSSH is a popular implementation of the protocol used in major Linux distributions for authentication over a network. Luis describes how a backdoor in a supporting library was recently discovered and removed before the package was published to stable releases of the Linux distros. The conversation explores the mechanism of the attack through modifying a function table in the runtime; how the attack was inserted during the build; how the attack was carefully staged in a series of modifications to the lz compression library; the nature of “Jia Tan,” the entity who committed the changes to the open source project; social engineering that the entity used to gain the trust of the open source community; what forensics indicates about the location of the entity; hypotheses about whether criminal or state actors backed the entity; how the attack was detected; implications for other open source projects; why traditional methods for detecting exploits would not have helped find this; and lessons learned by the community. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show NotesRelated Episodes* SE Radio 606: Charlie Jones on Third-Party Software Supply Chain Risks * SE Radio 541: Jordan Harband and Donald Fischer on Securing the Supply Chain * SE Radio 587: M. Scott Ford on Managing Dependency Freshness
Other References* Luis Rodríguez on the ssh backdoor XZ Backdoor: “That was a close one” * FAQ by @thesamesam on the xz backdoor: xz-utils backdoor situation (CVE-2024-3094) * Gynvael on the bash-stage obfuscation: xz/liblzma: Bash-stage Obfuscation Explained * Xygeni | Secure your Software Development and Delivery | Xygeni Security home page * Luis Rodríguez on the Ledger Attack : The Ledger Attack: draining hardware cryptowallets * Luis Rodríguez on the 3CX supply chian attack: 3CX Supply Chain Attack: Lessons Learned * Luis Rodríguez Berzosa LinkedIn profile: @luis-rodríguez-xygeni
Emily Bache, founder of the Samman Technical Coaching Society and author of several books about technical agile coaching, talks with SE Radio host Sam Taggart about katas and the importance of practice. They discuss how practicing in a safe environment helps developers to learn new skills and build new habits. They also talk about how Samman coaching combines this sort of deliberate practice with applying the lessons learned in practice to the production code base. They also touch briefly on the advantages of working in an ensemble fashion.
Show NotesRelated links* YouTube: @EmilyBache-tech-coach * Github: emilybache * sammancoaching.org * leanpub.com/u/emilybache * Twitter: @emilybache
Related Episodes* Episode 555: On Freund on Upskilling * Episode 529: Jeff Perry on Career Management for Software Engineers
Hans Dockter, the creator of the Gradle build tool and founder of Gradle Inc, the company behind the developer productivity platform Develocity, joins SE Radio host Giovanni Asproni to talk about developer productivity. They start with some definitions and an explanation of the importance of developer productivity, its relationship with cognitive load, and the big impact that development tools have on it. Hans describes how to implement developer productivity metrics in an organization, as well as warns about some pitfalls. The episode closes with some discussion on Hans's views on the future of this discipline, as well as some near-term developments and expectations. Brought to you by IEEE Computer Society and IEEE Software magazine.
Chuck Weindorf, a retired IT director and chief engineer with nearly 40 years' experience in software engineering, joins host Jeff Doolittle for a conversation about the concepts in Chuck's book, Leaders & Software Engineers. Through personal anecdotes and insights gleaned from his extensive career, Chuck underscores quality assurance's critical role in building trust with users and fostering a proactive culture of defect resolution within development teams. He highlights how ethical considerations underpin trust and integrity within the software engineering profession.
Chuck and Jeff examine the significance of thorough documentation and the vital role of effective communication in overcoming silos within organizations, and ensuring that projects meet their intended objectives while maintaining high standards of quality and reliability. They discuss how to cultivate a positive, innovative culture within engineering teams. Chuck shares strategies for addressing challenges and opportunities presented by change, advocating for adaptability and continuous learning as essential qualities for both new and experienced engineers navigating the evolving technological landscape. He offers advice for those transitioning into leadership roles, emphasizing the importance of developing soft skills and the ability to empathize with and inspire team members. Finally, the episode explores the potential impact of emerging technologies, such as low-code platforms and artificial intelligence.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Ipek Ozkaya, Principal Researcher and Technical Director of the Engineering Intelligent Software Systems group at the Software Engineering Institute, Carnegie Mellon, discusses generative AI for Software Architecture with SE Radio host Priyanka Raghavan. The episode delves into fundamental definitions of software architecture and explores use cases in which gen AI can enhance architecture activities. The conversation spans from straightforward to challenging scenarios and highlights examples of relevant tooling. The episode concludes with insights on verifying the correctness of output for software architecture prompts and future trends in this domain. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show NotesRelated Episodes 447: Michael Perry on Immutable Architecture * 525: Randy Shoup on Evolving Architecture and Organization at Ebay * 308: Gregor Hohpe on IT Architecture and IT Transformation * 331:* Kevin Goldsmith on Architecture and Organizational Design
References* + Linkedin Profile @IpekOzkaya + Software Architecture in the Age of Generative AI: Opportunities Challenges and the Road Ahead + https://arxiv.org/pdf/2403.01709 + https://publikationen.bibliothek.kit.edu/1000165891 + https://www.computer.org/csdl/magazine/so/2023/05/10273784/1R6sNhsUTVS + https://www.informit.com/store/managing-technical-debt-reducing-friction-in-software-9780135645932 + https://dl.acm.org/doi/10.1145/3582083 + https://arxiv.org/abs/2303.07839
Ipek Ozkaya, Principal Researcher and Technical Director of the Engineering Intelligent Software Systems group at the Software Engineering Institute, Carnegie Mellon, discusses generative AI for Software Architecture with SE Radio host Priyanka Raghavan. The episode delves into fundamental definitions of software architecture and explores use cases in which gen AI can enhance architecture activities. The conversation spans from straightforward to challenging scenarios and highlights examples of relevant tooling. The episode concludes with insights on verifying the correctness of output for software architecture prompts and future trends in this domain. Brought to you by IEEE Computer Society and IEEE Software magazine.
Jonathan Schneider, the co-founder of Moderne and the creator of OpenRewrite, talks with SE Radio’s Gregory Kapfhammer about automated software maintenance. In addition to exploring the design and implementation of OpenRewrite, Schneider explains how the tool can automatically support software maintenance tasks such as framework migration and security fixes for programs implemented in languages like Java. The episode also explores how OpenRewrite uses the lossless semantic tree to support automated refactoring though the use of recipes. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show NotesRelated Episodes* SE Radio 59: Static Code Analysis with Jonathan Aldrich * SE Radio 602: Nicolas Carlo on Improving Legacy Code<!-- * SE Radio 465: Kevlin Henney and Trisha Gee on 97 Things Every Java Programmer Should Know
-->
Jonathan Schneider, the cofounder of Moderne and the creator of OpenRewrite, talks with SE Radio's Gregory Kapfhammer about automated software maintenance. In addition to exploring the design and implementation of OpenRewrite, Schneider explains how the tool can automatically support software maintenance tasks such as framework migration and security fixes for programs implemented in languages like Java. The episode also explores how OpenRewrite uses the lossless semantic tree to support automated refactoring though the use of recipes. Brought to you by IEEE Computer Society and IEEE Software magazine.
Marcelo Trylesinski, a senior software engineer at Pydantic and a maintainer of open-source Python tools including Starlette and Uvicorn, joins host Gregory M. Kapfhammer to talk about FastAPI. Their conversation focuses on the design and implementation of FastAPI and how programmers can use it to create web-based APIs. They also explore how to create and deploy a FastAPI implemented in the Python programming language. Brought to you by IEEE Computer Society and IEEE Software magazine.
Marcelo Trylesinski, a senior software engineer at Pydantic and a maintainer of open-source Python tools including Starlette and Uvicorn, joins host Gregory M. Kapfhammer to talk about FastAPI. Their conversation focuses on the design and implementation of FastAPI and how programmers can use it to create web-based APIs. They also explore how to create and deploy a FastAPI implemented in the Python programming language. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes* FastAPI website * GitHub repository for FastAPI * Examples of FastAPI projects * Guest’s web site: About The FastAPI Expert
Related Episodes* SE Radio 537: Adam Warski on Scala and Tapir * SE Radio 387: Abhinav Asthana on Designing and Testing APIs * SE Radio 376: Justin Richer On API Security with OAuth 2 * SE Radio 143: API Design with Jim des Rivieres * SE Radio 431: Ken Youens-Clark on Learning Python * SE Radio 490: Tim McNamara on Rust 2021 Edition * SE Radio 562: Bastian Gruber on Rust Web Development * SE Radio 542: Brendan Callum on Contract-Driven APIs * SE Radio 516: Brian Okken on Testing in Python with pytest * SE Radio 383: Neil Madden On Securing Your API
Michael J. Freedman, the Robert E. Kahn Professor in the Computer Science Department at Princeton University, as well as the co-founder and CTO of Timescale, spoke with SE Radio host Gavin Henry about TimescaleDB. They revisit what time series data means in 2024, the history of TimescaleDB, how it integrates with PostgreSQL, and they take the listeners through a complete setup. Freedman discusses the types of data well-suited for a timeseries database, the types of sectors that have these requirements, why PostgreSQL is the best, Pg callbacks, Pg hooks, C programming, Rust, their open source contributions and projects, data volumes, column-data, indexes, backups, why it is common to have one table for your timeseries data, when not to use timescaledb, IoT data formats, Pg indexes, how Pg works without timescaledb, sharding, and how to manage your upgrades if not using Timescale Cloud. Brought to you by IEEE Computer Society and IEEE Software magazine.
Wolf Vollprecht, the CEO and founder of Prefix.dev, speaks with host Gregory M. Kapfhammer about how to implement Python tools, such as package managers, in the Rust programming language. They discuss the challenges associated with building Python infrastructure tooling in Python and explore how using the Rust programming language addresses these concerns. They also explore the implementation details of Rust-based tooling for the Python ecosystem, focusing on the cross-platform Pixi package management tool, which enables developers to easily and efficiently install libraries and applications in a reproducible fashion. Brought to you by IEEE Computer Society and IEEE Software magazine.
Xe Iaso of Fly.io discusses their hosting platform with host Jeremy Jung. They cover building globally distributed applications with Anycast, using Wireguard to encrypt inter-service communication, writing custom code to handle load balancing and scaling with fly-proxy, why serving EU customers has unique requirements, letting users use docker images without the docker runtime by converting them to firecracker and cloud hypervisor microVMs, the differences between regular VMs and microVMs, challenges of acquiring and serving GPUs to customers. when to use Kubernetes, and dealing with abuse on the platform. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes* Xe’s blog * How I Fly * Firecracker * Cloud Hypervisor * WireGuard * Playing Traffic Cop with Fly-Replay * What are these “GPUs” really? * Docker without Docker * Fly Kubernetes does more now * Globally Distributed Object Storage with Tigris * Delegating tasks to Fly Machines * Deploy Your Own (Not) Midjourney Bot on Fly GPUs
SE Radio Episodes* 531 – Xe Iaso on Tailscale * 345 – Tyler McMullen on Content Delivery Networks (CDNs) * 499 – Uma Chingunde on Building a PaaS
Xe Iaso of Fly.io discusses their hosting platform with host Jeremy Jung. They cover building globally distributed applications with Anycast, using Wireguard to encrypt inter-service communication, writing custom code to handle load balancing and scaling with fly-proxy, why serving EU customers has unique requirements, letting users use docker images without the docker runtime by converting them to firecracker and cloud hypervisor microVMs, the differences between regular VMs and microVMs, challenges of acquiring and serving GPUs to customers. when to use Kubernetes, and dealing with abuse on the platform. Brought to you by IEEE Computer Society and IEEE Software magazine.
Shannon Selbert, co-founder of Soren and developer of Oban, and Parker Selbert, creator of the Oban background job framework, chief architect at dscout, and co-founder of Soren, speak with SE Radio host Gavin Henry about robust job processing in Elixir. They explore the reliability, consistency, and observability in relation to job processing, to understand how Oban, Elixir, and PostgreSQL deliver them.
The Selberts describe why Oban was created, its history, which parts of the Elixir ecosystem they use, and why this would not be possible without PostgreSQL and Elixir. They discuss the lessons learned in the 5 years since the first release, as well as use cases, job throughput, the hardest problem to solve so far, workers, queues, CRON, distributed architectures, retry algorithms, just-once methodologies, the reliability the beam brings, consistency across nodes, how PostgreSQL is vital, telemetry data, best use cases for Oban, and the most common issues that new users face. Brought to you by IEEE Computer Society and IEEE Software magazine.
Infrastructure engineer and Kubernetes ingress-Nginx maintainer James Strong joins host Robert Blumen to discuss the Kubernetes networking layer. The discussion draws on content from Strong’s book on the topic and covers a lot of ground, including: the Kubernetes network's use of different IP ranges than the host network; overlay network with its own IP ranges compared to using expanded portions of the host network ranges; adding routes with kernel extension points; programming kernel extension points with IP tables compared to eBPF; how routes are updated as the host network gains or loses nodes, the use of the Linux network namespace to isolate each pod; routing between pods on the same host; routing between pods across the host network; the container-network interface (CNI); the CNI ecosystem; differences between CNIs; choosing a CNI when running on a public cloud service; the Kubernetes service abstraction with a cluster-wide IP address; monitoring and telemetry of the Kubernetes network; and troubleshooting the Kubernetes network.
Brought to you by IEEE Software magazine and IEEE Computer Society.
Andreas Møller, founder of Toddle, a no-code tool for building scalable performant web applications, speaks with SE Radio's Brijesh Ammanath about no-code platforms. They discuss the role of developers in a no-code ecosystem and explore scalability and performance considerations, as well as enterprise adoption of no-code tools. Andreas also expands on why he built Toddle.dev and its unique features. Brought to you by IEEE Computer Society and IEEE Software.
Frances Buontempo, author of the new book Learn C++ by Example, discusses the C++ programming language, a widely used general-purpose programming language. Host Philip Winston speaks with Buontempo about where C++ fits into the landscape of existing programming languages and how recent C++ standards have changed things. They talk about specific language features such as lambdas, templates, concurrency, ranges, concepts along with tips for learning and using C++.
Show NotesRelated Episodes* Episode 159: C++0X with Scott Meyers (2010) * Episode 91: Kevlin Henney on C++ (2008)
Other References* Book: Learn C++ by Example * Book: Genetic Algorithms and Machine Learning for Programmers * Anthony William’s book C++ Concurrency in Action * Ivan Cukic’s book Functional Programming in C++
Frances Buontempo
- LinkedIn – @francesbuontempo
- Mmastodon – @fbuontempo
- Twitter – @fbuontempo
C++
- https://isocpp.org/
- https://isocpp.org/get-started
- https://isocpp.org/std/meetings-and-participation
ACCU
- https://accu.org/menu-overviews/membership/
- https://accu.org/journals/nonmembers/overload_cover_members/
C++ Ranges
- https://accu.org/conf-docs/PDFs_2009/AndreiAlexandrescu_iterators-must-go.pdf
- https://archive.org/details/AndreiAlexandrescuKeynoteBoostcon2009
Ori Saporta, co-founder and Systems Architect at vFunction, joins host Jeff Doolittle for a conversation about the role of the software architect. The episode begins with Ori’s thoughts on what is typically missed or overlooked regarding this role. The conversation then explores aspects of both hard and soft skills required of software architects. Other topics include the relationship of the software architect to other roles, to design and process, and to quality. The show concludes by addressing the importance of dependency management by software architects. Brought to you by IEEE Software magazine and IEEE Computer Society.
Kent Beck, Chief Scientist at Mechanical Orchard, and inventor of Extreme Programming and Test-Driven Development, joins host Giovanni Asproni for a conversation on software design based on his latest book “Tidy First?”. The episode starts with exploring the reasons for writing the book, and introducing the concepts of tidying, cohesion, and coupling. It continues with a conversation about software design, and the impact of tidyings. Then Kent and Giovanni discuss how to balance design and code quality decisions with cost, value delivered, and other important aspects. The episode ends with some considerations on the impact of Artificial Intelligence on the software developer’s job. Brought to you by IEEE Software and IEEE Computer Society.
Show NotesRelated Episodes* SE Radio 574: Chad Michel on Software as an Engineering Discipline * SE Radio 554: Adam Tornhill on Behavioral Code Analysis * SE Radio 520: John Ousterhout on A Philosophy of Software Design * SE Radio 462: Felienne on the Programmer’s Brain * SE Radio 430: Marco Faella on Seriously Good Software * SE Radio 333: Marian Petre and André van der Hoek on Software Design * SE Radio 278: Peter Hilton on Naming * SE Radio 262: Software Quality with Bill Curtis * SE Radio 236: Rebecca Parsons on Evolutionary Architecture * SE Radio 55: Refactoring Pt. 2 * SE Radio 46: Refactoring Pt. 1
Links And References* Book: Tidy First? * Book: Refactoring: Improving the Design of Existing Code * Book: Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Ed Yourdon, and Larry Constantine, 1979 Prentice Hall (out of print) * Book: A Philosophy of Software Design, John Ousterhout * Constantine’s Equivalence * The Product Development Triathlon * 3x Explore, Expand, Extract • Kent Beck • YOW! 2018 * Canon TDD * Kent Beck’s Substack blog * David Parnas Paper: A Rational Design Process: How And Why To Fake It * Jeff Bezos Type 1 and Type 2 Decisions (Original Document) * Research: quantifying GitHub Copilot’s impact on developer productivity and happiness * New GitHub Copilot Research Finds ‘Downward Pressure on Code Quality’
Wouter Groeneveld, author of The Creative Programmer and PhD researcher at KU Leuven, discusses his research related to programming education with host Jeremy Jung. Topics include evaluating projects, constraints, social debt in teams, common fallacies in critical thinking, maintaining flow state, documenting and retaining knowledge, and creating environments that encourage creativity. Brought to you by IEEE Software and IEEE Computer Society.
Show Notes* Wouter Groeneveld’s blog * The Creative Programmer * Creative Programing Problem Solving Test (CPPST)
Related SE Radio Episodes* SE Radio 462: Felienne on the Programmers Brain
Shachar Binyamin, CEO and co-founder of Inigo, joins host Priyanka Raghavan to discuss GraphQL security. They begin with a look at the state of adoption of GraphQL and why it's so popular. From there, they consider why GraphQL security is important as they take a deep dive into a range of known security issues that have been exploited in GraphQL, including authentication, authorization, and denial of service attacks with references from the OWASP Top 10 API Security Risks. They discuss some mitigation strategies and methodologies for solving GraphQL security problems, and the show ends with discussion of Inigo and Shachar's top three recommendations for building safe GraphQL applications. Brought to you by IEEE Software and IEEE Computer Society.
Eyal Solomon, CEO and co-founder of Lunar.dev, joins SE Radio’s Kanchan Shringi for a discussion on tooling for API consumption management. The episode starts by examining why API consumption management is an increasingly important topic, and how existing tooling on the provider side can be inadequate for client-side issues. Eyal talks in detail about issues that are unique to API consumers, before taking a deep dive into the evolution of middleware built by teams and companies to address these issues and the gaps. Finally they consider how Lunar.dev seeks to solve these issues, as well as Eyal's vision of lunar.dev as a open source platform. This episode is sponsored by WorkOS.
Ines Montani, co-founder and CEO of Explosion, speaks with host Jeremy Jung about solving problems using natural language processing (NLP). They cover generative vs predictive tasks, creating a pipeline and breaking down problems, labeling examples for training, fine-tuning models, using LLMs to label data and build prototypes, and the spaCy NLP library.
Phillip Carter, Principal Product Manager at Honeycomb and open source software developer, talks with host Giovanni Asproni about observability for large language models (LLMs). The episode explores similarities and differences for observability with LLMs versus more conventional systems. Key topics include: how observability helps in testing parts of LLMs that aren't amenable to automated unit or integration testing; using observability to develop and refine the functionality provided by the LLM (observability-driven development); using observability to debug LLMs; and the importance of incremental development and delivery for LLMs and how observability facilitates both. Phillip also offers suggestions on how to get started with implementing observability for LLMs, as well as an overview of some of the technology's current limitations. This episode is sponsored by WorkOS.
Rishi Singh, founder and CEO at Sapient.ai, speaks with SE radio’s Kanchan Shringi about using generative AI to help developers automate test code generation. They start by identifying key problems that developers are looking for in an automated test-generation solution. The discussion explores the capabilities and limitations of today’s large language models in achieving that goal, and then delves into how Sapient.ai has built wrappers around LLMs in an effort to improve the quality of the generated tests. Rishi also suggests how to validate the generated tests and outlines his vision of the future for this rapidly evolving area. Brought to you by IEEE Computer Society and IEEE Software magazine. This episode is sponsored by WorkOS.
Hyrum Wright, Senior Staff Engineer at Google, discusses the book he co-edited, “Software Engineering at Google,” with host Gregory M. Kapfhammer. Wright describes the professional and technical best practices adopted by the software engineers at Google. The wide-ranging conversation investigates an array of topics, including measuring engineering productivity and writing effective test cases. This episode is sponsored by the Algorand Foundation.
Lane Wagner of Boot.dev speaks with host Philip Winston about Go, the programming language that's popular for web, cloud, devops, networking, and other types of development. In addition to discussing existing features such as structs, interfaces, concurrency, and error handling, Lane and Philip take a deep look at generics, a recent addition to the language. They also explore the developer experience with Go.
John Frandsen, Chief Product officer for Elebase, joins host Jeff Doolittle for an exploration of geospatial technologies. The conversation begins with a discussion of the history of mapping and global information systems (GIS) technologies. John describes the underlying technologies used in location-aware applications and the ways that developers can incorporate maps in their own applications. The conversation also highlights recent changes and innovations in the space, as well as the challenges and opportunities of incorporating your own data into existing base map providers. This episode is sponsored by WorkOS.
Charlie Jones, Director of Product Management at ReversingLabs and subject matter expert in supply chain security, joins host Priyanka Raghavan to discuss tackling third-party software risks. They begin by defining different types of third-party software risks and then take a deep dive into case studies where third-party components and software have had cascading effects on downstream systems. They consider some frameworks for secure software development that can be used to evaluate third-party software and components – both as a publisher or as a consumer – and end by discussing laws and regulations with final advise from Charlie on how enterprises can tackle third-party software risks. Brought to you by IEEE Computer Society and IEEE Software magazine. This episode is sponsored by WorkOS.
Yingjun Wu, founder of RisingWave Labs and previously a software engineer at Amazon Web Services and researcher at IBM Almaden Research Center, speaks with SE Radio host Brijesh Ammanath about streaming databases. After considering the benefits and unique challenges, they delve into the architecture and design patterns of streaming databases, as well as the evolution and security considerations. Yingjun also talks about the future of streaming databases, including the potential impact that Amazon S3 Express One Zone will have on the streaming landscape, and how the unified batch and streaming might evolve in the database world. Brought to you by IEEE Computer Society and IEEE Software magazine.
Karl Wiegers, Principal Consultant with Process Impact and author of 14 books, and Candase Hokanson, Business Architect and PMI-Agile Certified Practitioner at ArgonDigital, speak with SE Radio host Gavin Henry about software requirements essentials. They explore five different parts of requirements engineering and how you can apply them to any ongoing project. Wiegers and Hokanson describe why requirements constantly change, how you can test that you're meeting them, and why the tools you have at hand are suitable to start straight away. They discuss the need for requirements in every software project and provide recommendations on how to gather, analyze, validate, and manage those requirements. Candase and Karl offer in-depth perspectives on a range of topics, including how to elicit requirements, speak with users, get to the source of the business or user goal, and create requirement sets, models, prototypes, and baselines. Finally, they look at specifications you can use, and how to validate, test, and verify them. Brought to you by IEEE Computer Society and IEEE Software magazine.
Nicolas Carlo talks with host Sam Taggart about Nicolas’s recent book, Legacy Code First Aid Kit. They start by defining legacy code and the general issues that developers face when dealing with it. Nicolas describes some of the tools in his book and provides examples of where he has found them useful. The episode also touches briefly on the role of AI and some other tools Nicolas has discovered since writing the book. This episode sponsored by WorkOS.
Han Yuan, an accomplished Chief Product and Technology Officer, joins host Priyanka Raghavan to discuss reorganizations. The conversation starts with a broad discussion of reorganizations and reasons that companies choose to undertake them. They then consider organizational behavior and topics such as Conway's law and the theory of constraints. Han offers some advice on key steps to take when planning for a reorg, including how software teams could organize themselves based on technology, frameworks, or user journeys. The episode ends with some discussion of metrics and lessons learned. Brought to you by IEEE Computer Society and IEEE Software magazine.
William Morgan, founder of the Linkerd service mesh and CEO of Bouyant, joins SE Radio’s Robert Blumen for a discussion of sidecars, service mesh, and a forthcoming enhancement to kubernetes to support sidecars natively. The conversation explores the origin of sidecars, sidecars and service mesh, and migrating service mesh to kubernetes. They take a deep dive into some aspects of running service mesh on kubernetes, the difficulties in running a sidecar container in a pod, and Kubernetes Enhancement Proposal (KEP) 753, which is intended to provide better native support for sidecar containers. William also gives some thoughts on the continuing relevance of service mesh.
Jason C. McDonald, author of the book Dead Simple Python, speaks with host Samuel Taggart about leveraging quantified tasks to improve estimation, particularly across projects. They discuss the origin of the concept and its relationship with story points, and Jason offers examples to show how quantified tasks can capture nuances in software tasks that are often lost with story points. He also points to the ability to compare them across projects as a major advantage of quantified tasks. Among other topics, they consider also how to use quantified tasks to analyze the stability of a codebase. Brought to you by IEEE Computer Society and IEEE Software magazine.
Jonathan Crossland, software architect, author, and business owner, joins host Jeff Doolittle for a conversation about the AMMERSE framework of design principles. They start by discussing the agile manifesto as a statement of values, and Jonathan shares his perspective based on his experience as a software developer and business owner. They then explore the three layers of the AMMERSE framework and how they help business and engineering leaders to align their values, thereby improving their ability to collaborate and reach common goals. Brought to you by IEEE Computer Society and IEEE Software magazine.
Coral Calero Muñoz and Felix Garcia, professors at the University of Castilla-La Mancha, speak with host Giovanni Asproni about green and sustainable software—an approach to software development aimed at creating software systems that consume less energy and produce less CO2 during their entire lifetimes with minimal impact on their functionality and other qualities. The episode starts by describing why green software matters, particularly in the context of global warming, and introducing the key concepts. Continues discussing the current status of the field, in both academia and industry, and finishes with hints and tips that can be readily applied by development teams to make their systems greener. Brought to you by IEEE Computer Society and IEEE Software magazine.
Maxim Fateev, the CEO of Temporal, speaks with SE Radio's Philip Winston about how Temporal implements durable execution. They explore concepts including workflows, activities, timers, event histories, signals, and queries. Maxim also compares deployment using self-hosted clusters or the Temporal Cloud.
Llewelyn Falco, creator approval tests, talks with SE Radio host Sam Taggart about testing code in general and the various types of testing that developers perform. Llewelyn elaborates on how approval tests can help test code at a higher level than traditional unit tests. They also discuss using approval tests to help get legacy code under test. This episode sponsored by Data Annotation.
Sean Moriarity, creator of the Axon deep learning framework, co-creator of the Nx library, and author of Machine Learning in Elixir and Genetic Algorithms in Elixir, published by the Pragmatic Bookshelf, speaks with SE Radio host Gavin Henry about what deep learning (neural networks) means today. Using a practical example with deep learning for fraud detection, they explore what Axon is and why it was created. Moriarity describes why the Beam is ideal for machine learning, and why he dislikes the term “neural network.” They discuss the need for deep learning, its history, how it offers a good fit for many of today’s complex problems, where it shines and when not to use it. Moriarity goes into depth on a range of topics, including how to get datasets in shape, supervised and unsupervised learning, feed-forward neural networks, Nx.serving, decision trees, gradient descent, linear regression, logistic regression, support vector machines, and random forests. The episode considers what a model looks like, what training is, labeling, classification, regression tasks, hardware resources needed, EXGBoost, Jax, PyIgnite, and Explorer. Finally, they look at what’s involved in the ongoing lifecycle or operational side of Axon once a workflow is put into production, so you can safely back it all up and feed in new data. Brought to you by IEEE Computer Society and IEEE Software magazine. This episode sponsored by Miro.
Eric Olden talks with host Giovanni Asproni about identity orchestration, a software approach for managing distributed identity and access management (IAM) and integrating multiple identity systems or providers (IDPs) to make them look like a single system from a user perspective. The episode starts with a refresher in identity and access management, then introduces identity orchestration and some of the challenges it helps to address, such as integrating disparate identity management systems after company mergers or acquisitions; managing identities in situations where some of the IAM systems are unreachable; and implementing more secure identity management in legacy applications. Brought to you by IEEE Computer Society and IEEE Software magazine.
Jaxon Repp of HarperDB speaks with Brijesh Ammanath about distributed data infrastructure, including what it is and why it's important. They discuss the key factors that make distributed data infrastructure attractive, as well as challenges to implementing it. The episode explores the architecture and design principles, the key security considerations, and the transition factors for distributed data Infrastructure. Brought to you by IEEE Computer Society and IEEE Software.
Yeckezkel Rabinovich, CTO of Groundcover, speaks with host Philip Winston about observability and eBPF as it applies to Kubernetes. Rabinovich was previously the chief architect at the healthcare security company CyberMDX and spent eight years in the cyber security division of the Israeli Prime Minister’s Office. This episode explores the three pillars of observability, extending the Linux Kernel with eBPF, the basics of Kubernetes, and how Groundcover uses eBPF as the basis for its observability platform.
Andy Suderman, CTO of Fairwinds, joins host Robert Blumen to talk about standing up a kubernetes cluster. Their discussion covers build-your-own versus managed clusters provided by cloud services, and how to determine the number of kubernetes clusters an organization needs. Andy describes best practices for automating cluster provisioning, and offers recommendations about customizations and opinionation of cloud service providers, choice of container registry, and whether you should run complementary services such as CI and monitoring on the same cluster. The episode also examines the day 0/day 1/day 2 lifecycle, cluster auto-scaling at the cloud service level, integrating stateful services and other cloud services into your cluster, and kubernetes secrets and alternatives. Finally, they consider the container-network interface (CNI), ingress and load balancers, and provisioning external DNS and TLS certificates for cluster services.
Zac Hatfield-Dodds, the Assurance Team Lead at Anthropic, speaks with host Gregory M. Kapfhammer about property-based testing techniques and how to use them in an open-source tool called Hypothesis. They discuss how to define properties for a Python function and implement a test case in Hypothesis. They also explore some of the advanced features in Hypothesis that can automatically generate a test case and perform fuzzing campaigns.
José Valim, creator of the Elixir programming language, Chief Adoption Officer at Dashbit, and author of three programming books, speaks with SE Radio host Gavin Henry about what Elixir is today, what Livebook is, the five spearheads of the new machine learning ecosystem for Elixir, and how they all fit together. Valim describes why he created Elixir, what “the beam” is, and how he pitches it to new users. This episode examines things you can do with Livebook and how it is well-aligned with machine learning, as well as why immutability is important and how it works. They take a detailed look at a range of topics, including tensors with Nx, traditional machine learning with Scholar, data munging with Explorer, deep learning and neural networks with Axon, Bumblebee and Huggingface, and model creation basics. Brought to you by IEEE Computer Society and IEEE Software magazine.
M. Scott Ford, the CTO of Corgibytes and host of the Legacy Code Rocks podcast, discusses managing dependency freshness. SE Radio’s Sam Taggart speaks with him about why dependency freshness is important to ensure that your code has all the latest bug fixes, how exactly to measure dependency freshness, and some of the insights that teams can gain from monitoring freshness over time. Brought to you by IEEE Computer Society and IEEE Software Magazine.
Nikhil Shetty, an expert in networking and distributed systems, speaks with SE radio's Kanchan Shringi about virtual private cloud (VPC) and related technologies. They explore how VPC relates to public cloud, private cloud, and virtual private networks (VPNs). The discussion delves into why VPC is fundamental to building on the cloud, as well as configuring a VPC, subnets, and the address space that can be assigned to the VPC. During this episode they look into route tables, network address translation, as well as security groups, network access control lists, and DNS. Finally, Nikhil helps compare VPC offerings from Amazon Web Services (AWS) and Oracle Cloud Infrastructure (OCI).
Adam Frank, SVP of Product and Marketing at Armory.io, speaks with SE Radio’s Kanchan Shringi about continuous integration, continuous delivery, and continuous deployment – and how they differ. Frank suggests that organizations begin by identifying how the CI/CD process aligns best with their unique goals, noting that such goals might be different for B2C versus B2B SAAS (software as a service). They also discuss how the process can differ for monoliths compared to microservices-based products. Finally, they talk about continuous deployment as a service and some unique aspects of Armory’s approach.
Charles Weir—developer, security researcher, and Research Fellow at Security Lancaster—joins host Giovanni Asproni to discuss an approach that development teams can use to create secure systems without wasting effort on unnecessary security work. The episode starts with a broad description of the approach, which is based on Weir's research and on a free Developer Security Essentials workshop he created. Charles presents some examples from real-world projects, his view on AI's impact on security, and information about the workshop and where to find the materials. During the conversation, they consider several related topics including the concept of "good enough" security; security as a product decision; risk assessment, classification, and prioritization; and how to approach security in startups, greenfield, and legacy systems.
Lukas Fittl of pganalyze discusses the performance of Postgres, one of the world’s most popular database systems. SE Radio host Philip Winston speaks with Fittl about database indexing, queries, maintenance, scaling, and stored procedures. They also discuss some features of pganalyze, such as the index and vacuum advisors.
Dr. Daniel Zingaro and Dr. Leo Porter, co-authors of the book Learn AI-Assisted Python Programming, speak with host Jeremy Jung about teaching programming with the aid of large language models (LLMs). They discuss writing a book to use in Leo's introductory CS class and explore how GitHub Copilot de-emphasizes syntax errors, reduces the need to memorize APIs, and why they want students to write manual test cases. They also discuss possible ethical concerns of relying on commercial tools, their impact on coursework, and why they aren't worried about students cheating with LLMs.
Zach Lloyd, CEO of Warp.dev, discusses how to implement and effectively use command-line terminals. Host Gregory Kapfhammer speaks with Lloyd about how command-line terminals work and how the Warp terminal uses the GPU and AI to enhance a software developer’s productivity. They also discuss the trade-offs associated with using the Rust programming language to implement a command-line terminal. Brought to you by IEEE Computer Society and IEEE Software magazine.
Josh Doody, author of Mastering Business Email, speaks with host Brijesh Ammanath about how software engineers can master business communication. They begin with an exploration of various communication modes, including Slack, virtual meetings, emails, and presentations. Josh shares several strategies to improve communication skills and cross-cultural communication, but if there's one key take away from this episode, it might be: “use positive language for any medium of communication; be kind and use positive words.” Brought to you by IEEE Software magazine and IEEE Computer Society.
Josh Doody, author of Mastering Business Email, speaks with host Brijesh Ammanath about how software engineers can master business communication. They begin with an exploration of various communication modes, including Slack, virtual meetings, emails, and presentations. Josh shares several strategies to improve communication skills and cross-cultural communication, but if there's one key take away from this episode, it might be: “use positive language for any medium of communication; be kind and use positive words.” Brought to you by IEEE Software magazine and IEEE Computer Society.
Arun Gupta, Vice President and General Manager of Open Ecosystem Initiatives at Intel Corporation, discusses open-source strategy and community with SE Radio host Kanchan Shringi. They explore the business case and business model for why and how big tech participates in the open-source ecosystem. Arun describes ways to foster a culture of engagement with open source within companies such as Intel, Amazon, and Apple. They then consider how the principles can be applied to closed-source software within the company. Finally, they discuss some of the benefits that Intel has gained from more than 20 years of open source contributions and look at the company’s plan for the year ahead. SE Radio is rought to you by IEEE Software magazine and IEEE Computer Society.
In this episode, Ori Mankali, senior VP of engineering at cloud security startup Akeyless, speaks with SE Radio’s Nikhil Krishna about secrets management and the innovative use of distributed fragment cryptography (DFC). In the context of enterprise IT, 'secrets’ are crucial for authentication in providing access to internal applications and services. Ori describes the unique challenges of managing these sensitive data, particularly given the complexities of doing so on a large scale in substantial organizations. They discuss the necessity for a secure system for managing secrets, highlighting key features such as access policies, audit capabilities, and visualization tools. Ori introduces the concept of distributed fragment cryptography, which boosts security by ensuring that the entire secret is never known to any single entity. The episode explores encryption and decryption and the importance of key rotation, as they consider the challenges and potential solutions in secrets management.
Casey Muratori caused some strong reactions with a blog post and an associated video in which he went through an example from the “Clean Code” book by Robert Martin to demonstrate the negative impact that clean code practices can have on performance. In this episode, he joins SE Radio’s Giovanni Asproni to talk about the potential trade-offs between performance and the qualities that make for maintainable code, these qualities being the main focus of Clean Code. Brought to you by IEEE Computer Society and IEEE Software magazine.
Jens Neuse, founder of Wundergraph, joins SE Radio host Jeff Doolittle for a conversation about back ends for front ends, or BFF. Jens begins by explaining how a heavy integration burden is often placed on front-end development teams. When multiple APIs must be integrated, it can be challenging for client development in web, mobile, and desktop environments. Explaining how APIs should be treated as dependencies, just like packages, the episode explores BFF patterns and use cases, as well as the future potential emergence of a “git for APIs” standard. This episode is sponsored by ClickSend.
Nir Valtman, co-Founder and CEO at Arnica, discusses pipelineless security with SE Radio host Priyanka Raghavan. They start by defining pipelines and then consider how to add security. Nir lays out the key challenges in getting good code coverage with the pipeline-based approach, and then describes how to implement a pipelineless approach and the advantages it offers. Priyanka quizzes him on the concept of "zero new hardcoded secrets," as well as some ways to protect GitHub repositories, and Nir shares examples of how a pipelineless approach could help in these scenarios. They then discuss false positives and handling developer fatigue in dealing with alerts. The show ends with some discussion around the product that Arnica offers and how it implements the pipelineless methodology.
Chad Michel, Senior Software Architect at Don’t Panic Labs and co-author of Lean Software Systems Engineering for Developers, joins host Jeff Doolittle for a conversation about treating software development as an engineering discipline. They begin by discussing the need for engineering rigor in the software industry. Chad points out that many developers lack awareness of good engineering practice and are often unaware of resources such as the Software Engineering Body of Knowledge (SWEBOK). Among the many topics explored in this episode are design methodologies such as volatility-based decomposition and the work of David Parnas, as well as important topics such as quality, how to address complexity, designing for change, and the role of the chief engineer. This episode is sponsored by ClickSend. SE Radio listeners can get a $50 credit by following the link.
In this episode, Varun Singh, Chief Products and Technology Officer at Daily.co, speaks with host Nikhil Krishna about the 30-year evolution of web protocols. In particular, they explore the impact of protocol ossification, which has supported the Internet’s success but also limits the flexibility of evolving protocol suites such as TCP/IP and UDP by constraining future development. Varun points out how the end-to-end principle emphasizes full flexibility for end hosts, but the TCP implementation in the OS kernel as well as in “middle boxes” such as ISPs contributes to the constraints of ossification by blocking certain types of traffic. Further, the development of new protocols is challenging due to the the need for backward compatibility with existing protocols. They discuss Google’s efforts – and the challenges it has faced – in working to move the HTTP protocol forward. The role of standards bodies such as the IETF and collaboration between industry stakeholders is crucial for the evolution of internet protocols, requiring a balance between maintaining backward compatibility and introducing new protocols such as QUIC and HTTP/3 to address existing constraints and improve internet performance and security. indeed, QUIC includes features that seek to actively avoid ossification and encourage evolution.
Gregory Kapfhammer, associate professor at Allegheny College, discusses the common problem of ‘flaky tests’ with SE Radio’s Nikhil Krishna. Flaky tests are test cases that unreliably pass or fail even when no changes are made to the source code under test or to the test suite itself, which means that developers can’t tell whether the failures indicate bugs that needs to be resolved. Flaky tests can hinder continuous integration and continuous development by undermining trust in the CI/CD environment. This episode examines sources of flaky tests, including physical factors such as CPU or memory changes, as well as program-related factors such as performance issues. Gregory also describes some common areas that are prone to flaky tests and ways to detect them. They discuss tooling to detect and automatically mark flaky tests, as well as how to tackle these issues to make tests more reliable and even ways to write code so that it's less susceptible to flaky tests.
Jeroen Mulder, author of Multi-Cloud Strategy for Cloud Architects, joins host Robert Blumen for a discussion of public cloud, private cloud, and multi-cloud computing architectures and trends. They start by considering what defines cloud computing and what differentiates the major cloud providers, including whether they are more alike or different in the services they offer. Jeroen discusses governance, regulatory compliance, and data locality as drivers of where enterprises want to run their workload. They explore use cases for multi-cloud, and discuss architectural challenges in migrating to kubernetes, as well as issues with networking, security, and identity management with multi-cloud architectures. Finally, they discuss running public cloud compute on on-prem resources with Anthos, Outback, and related technologies.
Stanisław Barzowski of XTX Markets and a committer on the jsonnet project joins SE Radio's Robert Blumen for a conversation about the jsonnet programming language. A superset of JSON, jsonnet adds programming language capabilities, particularly to address the need to handle large but mostly repetitive JSON configurations. They discuss the project’s history, use cases for Grafana and Kubernetes config, interoperability with YAML, and consider details including the command line, constrained capabilities of the language, and objects and inheritance. They examine the toolchain: compiler, formatter, and linter, as well as test frameworks and testing, package management, and the language’s performance. Barzowski describes four implementations -- go, C++, Rust, and Scala -- as well as popular libraries and the standard library.
Vladyslav Ukis, author of the book Establishing SRE Foundations: A Step-by-Step Guide to Introducing Site Reliability Engineering in Software Delivery Organizations, discusses how to roll out SRE in an enterprise. SE Radio host Brijesh Ammanath speaks with Vlad about the origins of SRE and how it complements ITIL (Information Technology Infrastructure Library). They examine how firms can establish foundations for rolling out SRE, as well as how to overcome challenges they might face in adopting. Vlad also recommends steps that organizations can take to sustain and advance their SRE transformation beyond the foundations.
Simon Bennetts, a distinguished engineer at Jit, discusses one of the flagship projects of OWASP: the Zed Attack Proxy (ZAP) open source security testing tool. As ZAP’s primary maintainer, Simon traces the tool's origins and shares some anecdotes with SE Radio host Priyanka Raghavan on why there was a need for it. They take a deep dive into ZAP’s features and its ability to integrate with CI/CD, as well as shift security left. Bennetts also considers what it takes to build a successful open source project before spending time on ZAP’s ability to script to provide richer results. Finally, the conversation ends with some questions on ZAP’s future in this AI-powered world of bots.
Dave Cross, owner of Magnum Solutions and author of GitHub Actions Essentials (Clapham Technical Press), speaks with SE Radio host Gavin Henry about GitHub actions, the value they provide, and the best practices for using them in your projects. Cross describes the vast range of things that developers can do with GitHub Actions, including some use cases you might never have thought about. They start with some general discussion of CI/CD and then consider the three main types of events that drive GitHub actions before digging in to details about fine-grained action events, Action Marketplace, contexts, yaml, docker base images, self-hosted runners, and more. They further explore identity management, permissions, dependency management, saving money, and how to keep your secrets secret.
Ashley Peacock, author of the book Creating Software with Modern Diagramming Techniques, speaks with SE Radio host Akshay Manchale about diagrams in software engineering. They discuss the power of diagramming and some reasons we don’t fully use it as often as we should. Ashley contrasts historical use of UML diagrams versus modern diagrams, which don't have hard rules about representations. The episode examines different types of diagrams through an example application and how it could be built with modern tools such as Streamy to simplify the building, versioning, and maintenance of diagrams.
Luca Galante, head of product at Humanitec, joins host Jeff Doolittle for a conversation about platform engineering. They begin by defining platform engineering and its relationship to, and distinction from, DevOps. Tracing platform engineering's history, Luca describes how internal developer platforms are fundamental, and then explores the goals of addressing complexity and reducing the cognitive load on developers by creating golden paths.
Paul Hammant, independent consultant, joins host Giovanni Asproni to speak about trunk-based development—a version control management practice in which developers merge small, frequent updates to a core “trunk” or main branch. The episode explores the technique in some detail, including its pros and cons and some examples from real projects, and offers suggestions on how to get started. The conversation touches on a set of related topics, including code reviews, feature flags, continuous integration, and testing.
In this episode, David Cramer, co-founder and CTO of Sentry, joins host Jeremy Jung for a conversation about error tracking. The discussion starts with treating performance problems as errors, why you might not need logs, and how most applications share the same problems. From there they consider other topics including capturing information by hooking into runtimes and frameworks, issues with the quality of Open Telemetry data, how front-end applications are constantly changing and why that makes them hard to instrument. Finally, they discuss how Sentry's architecture has evolved, and why they switched from a permissive license to the Business Source License.
Bastian Gruber, author of the book Rust Web Development, speaks with host Philip Winston about creating server-based web applications with Rust. They explore Rust language features, tooling, and web frameworks such as Warp and Tokyio. From there, they examine the steps to build a simple web server and a RESTful API, as well as modules, logging and tracing, and other aspects of web development with Rust.
Dan Demers of Cinchy.com joins host Jeff Doolittle for a conversation about data collaboration and dataware. Dataware platforms leverage an operational data fabric to liberate data from apps and other silos and connect it together in real-time data networks. They explore a range of key topics, including zero-copy integration, encapsulation and information hiding, handling changes to data models over time, and latency and access issues. The discussion also explores dataware management and security concerns, as well as the concept of 'data plasticity' as an analogy to neuroplasticity, which is where the nervous system can respond to stimuli such as injuries by reorganizing its structure, functions, or connections.
Sugu Sougoumarane discusses the challenges of horizontally scaling MySQL databases through the Vitess distribution engine and Planetscale, a service built on top of Vitess. The journey began with the growing pains of scale at YouTube around the time of Google’s acquisition of the video service. This episode explores ideas about topology management, sharding, Paxos, connection pooling, and how Vitess handles large transactions while abstracting complexity from the application Layer.
Ross John Anderson, Professor of Security Engineering at University of Cambridge, discusses software obsolescence with host Priyanka Raghavan. They examine risks associated with software going obsolete and consider several examples of software obsolescence, including how it can affect cars. Prof. Anderson discusses policy and research in the area of obsolescence and suggests some ways to mitigate the risks, with special emphasis on software bills of materials. He describes future directions, including software policy and laws in the EU, and offers advice for software maintainers to hedge against risks of obsolescence.
Michael Fazio, Engineering Manager (Android) at Albert and author of Kotlin and Android Development featuring Jetpack from the Pragmatic Programmers, speaks with SE Radio's Gavin Henry about how the Android ecosystem looks today, and why it's an excellent time to write native Android apps. They explore a wide range of topics about modern Android development, including when to go native, how to keep a lot of decisions in your back-end API, Kotlin co-routines, Jetpack and Jetpack Compose, the MVVM design pattern, and threads, as well as activities, fragments, Dagger, room, navigation, Flutter, and improvements in simulators. They also examine details such as IDEs, API selection, how to choose a list of support devices, Java vs Kotlin, handset manufacturers, XML layouts, and why Jetpack is a safe bet for all your future Android development.
Timothy Beamish of BenchSci discusses React and Next.js, two of today's most popular front-end frameworks. Host Philip Winston speaks with Beamish about components, routing, JSX, client-side and server-side rendering, single-page applications, automatic code-splitting, image optimization, and more. Beamish also details his experience moving a real-world application to Next.js.
Software engineer Alex Boten, author of Cloud Native Observability with Open Telemetry, joins SE Radio host Robert Blumen for a conversation about software telemetry and the OpenTelemetry project. After a brief review of the topic and the OpenTelemetry project's origins rooted in the need for interoperability between telemetry sources and back ends, they discuss the open telemetry server and its features, including transforms, filtering, sampling, and rate limiting. They consider a range of topics, starting with alternative topologies with and without the telemetry server, server pipelines, and scaling out the server, as well as a detailed look at extension points and extensions; authentication; adoption; and migration.
On Freund, founder of Wilco and former VP of Engineering at WeWork, speaks with SE Radio’s Brijesh Ammanath about “upskilling” – ways for developers to level up. On has years of experience in helping developers master the skills needed to advance in their careers. This episode explores the importance of upskilling in a constantly evolving tech landscape. They focus particularly on how and why senior and expert developers should keep learning, upskilling, and reskilling throughout their careers. Freund offers suggestions on how to face some common challenges, especially for remote or distributed workers, and how engineering managers can help enable upskilling for their teams.
Adam Tornhill, founder and CTO of CodeScene, joins host Giovanni Asproni to speak about behavioral code analysis. Behavioral code analysis is a set of practical techniques aimed at identifying patterns in how a development organization interacts with the codebase they're building. It can be used to prioritize technical debt to maximize return on investment; to identify communication and team-coordination bottlenecks in code; to drive refactorings guided by data from how the system evolves; and to detect code quality problems before they become maintenance issues. The episode starts with a broad description of the techniques, providing some examples from real projects, and ends with suggestions on how to get started with applying them. During the conversation, Adam and Giovanni touch on a set of related topics, including the applicability of the techniques to legacy, green-, and brown-field projects; ethical and privacy implications; and the importance of context when judging code quality.
Luca Casonato joins SE Radio's Jeremy Jung for a conversation about Deno and Deno Deploy. They start with a look at JavaScript runtimes and their relation to Google’s open source JavaScript and WebAssembly engine V8, and why Deno was created. They discuss the WinterCG W3C group for server-side JavaScript, why it's difficult to ship new features in Node, and the benefits of web standards. From there they consider the benefits of creating an all-inclusive toolset like Rust and Go rather than relying on separate solutions, Deno's node compatibility layer, use cases for WebAssembly, benefits and implementation of Deno Deploy, reasons to deploy on the edge, and what's coming next.
Matt Frisbie, author of Creating Browser Extensions, speaks with host Kanchan Shringi about browser extensions, including key areas where they've been successful. Based on Matt’s experience as a developer working for Google, Doordash, and a startup he founded, they examine tools for building extensions, as well as APIs they have access to. The conversation presents detailed issues such as cross-browser compatibilities to keep in mind when developing extensions and mechanisms in the browser to prevent security vulnerabilities, and finally examines how emerging platforms can help developers take advantage of exciting new possibilities with web extensions.
Vidal Graupera, an Engineering Manager at LinkedIn, speaks with SE Radio’s Brijesh Ammanath about the importance of managers' one-on-one meetings with direct reports. They start by considering how a 1:1 meeting differs from other meetings...
J.R. Storment and Mike Fuller discuss cloud financial operations (FinOps) with host Akshay Manchale. They consider the importance of a financial operations strategy for cloud-based infrastructure. J.R. and Mike discuss the differences between operating your own data center and running in the cloud, as well as the problems that doing so creates in understanding and forecasting cloud spend. Mike details the Cloud FinOps lifecycle by first attributing organizational cloud spend through showbacks and chargebacks to individual teams and products. JR describes the two levers available for optimization once an organization understands where they're spending their cloud budget. They discuss complexities that arise from virtualized infrastructure and techniques to attribute cloud usage to the correct owners, and close with some recommendations for engineering leaders who are getting started on cloud FinOps strategy.
William Falcon of Lighting AI discusses how to optimize deep learning models using the Lightning platform, optimization is a necessary step towards creating a production application. Philip Winston spoke with Falcon about PyTorch, PyTorch Lightning...
Alex Hidalgo, principal reliability advocate at Nobl9 and author of Implementing Service Level Objectives, joins SE Radio's Robert Blumen for a discussion of service-level objectives (SLOs) and error budgets. The conversation covers the meaning...
Nicholas Manson, a SaaS Architect with more than 2 decades of experience building cloud applications, speaks with host Kanchan Shringi about identity and access management requirements for cloud applications. They begin by examining what a digital...
Nikhil Krishna speaks with Dietrich Ayala about IPFS in depth. They cover what it is, how it works in detail and how one could leverage IPFS and libp2p in one's own application or to host one's content. The discussion goes into the IPFS ecosystem...
We talk with John deVadoss about the philosophies underlying the development of .NET and Azure software. We discuss the "Fiefdoms and Emissaries" concept of building loosely coupled systems, talk about strengths and drawbacks and how to build services...
Ganesh Datta, CTO and cofounder of Cortex, joins SE Radio's Priyanka Raghavan to discuss site reliability engineering (SRE) vs DevOps. They examine the similarities and differences and how to use the two approaches together to build better software...
Jon Smart, author of the book Sooner Safer Happier: Patterns and Antipatterns for Business Agility, discusses patterns and anti-patterns for the success of enterprise software projects. Host Brijesh Ammanath speaks with him about the various common...
Brendan Callum, engineering manager for the Pinterest developer platform team, discusses the "spec first" approach to API development and how it's different from "API first." Brendan speaks with host Kanchan Shringi about the challenges and advantages...
Open source developers Jordan Harband and Donald Fischer join host Robert Blumen for a conversation about securing the software supply chain, especially open source. They start by reviewing supply chain security concepts, particularly as related to open..
Joe Nash of Twillio's TwilioQuest discusses the role of developer relations/advocate, which is a role at tech companies in-between developers, marketing, sales, and HR. Host Felienne speaks with Nash about the skills people need if they want to become...
Adam Dymitruk, CEO and founder of Adaptech Group, joins host Jeff Doolittle for an exploration of the event modeling approach to discovering requirements and designing software systems. Adam explains how the structured approach eliminates the specifics of implementation details and technology decisions, enabling clearer communication for all stakeholders while keeping conversations focused on the business opportunity. Using concrete examples of event modeling in practice, they examine event modeling in the context of other related approaches and methodologies, including event sourcing, event storming, CQRS, and domain-driven design.
Roberto Di Cosmo, Computer Science professor at University Paris Diderot and founder of the Software Heritage initiative, discusses how to protect against sudden loss from the collapse of a "free" source code repository provider, how to protect...
Roberto Di Cosmo, Computer Science professor at University Paris Diderot and founder of the Software Heritage initiative, discusses how to protect against sudden loss from the collapse of a "free" source code repository provider, how to protect our software creativity heritage and the challenge of the long term archiving of software.
Ryan Magee, postdoctoral scholar research associate at LIGO Laboratory – Caltech, joins host Jeff Doolittle for a conversation about how software is used by scientists in physics research. The episode begins with a discussion of gravitational waves...
Ryan Magee, postdoctoral scholar research associate at LIGO Laboratory – Caltech, joins host Jeff Doolittle for a conversation about how software is used by scientists in physics research. The episode begins with a discussion of gravitational waves...
Ryan Magee, postdoctoral scholar research associate at LIGO Laboratory – Caltech, joins host Jeff Doolittle for a conversation about how software is used by scientists in physics research. The episode begins with a discussion of gravitational waves...
Dan Lorenc, CEO of Chainguard, a software supply chain security company, joins SE Radio editor Robert Blumen to talk about software supply chain attacks. They start with a review of software supply chain basics; how outputs become inputs of someone...
Dan Lorenc, CEO of Chainguard, a software supply chain security company, joins SE Radio editor Robert Blumen to talk about software supply chain attacks. They start with a review of software supply chain basics; how outputs become inputs of someone...
Dan Lorenc, CEO of Chainguard, a software supply chain security company, joins SE Radio editor Robert Blumen to talk about software supply chain attacks. They start with a review of software supply chain basics; how outputs become inputs of someone...
Andy Dang, Head of Engineering at WhyLabs discusses observability and data ops for AI/ML applications and how that differs from traditional observability. SE Radio host Akshay Manchale speaks with Andy about running an AI/ML model in production and how...
Andy Dang, Head of Engineering at WhyLabs discusses observability and data ops for AI/ML applications and how that differs from traditional observability. SE Radio host Akshay Manchale speaks with Andy about running an AI/ML model in production and how...
Andy Dang, Head of Engineering at WhyLabs discusses observability and data ops for AI/ML applications and how that differs from traditional observability. SE Radio host Akshay Manchale speaks with Andy about running an AI/ML model in production and how...
Eddie Aftandilian, Principal researcher at GitHub discusses GitHub copilot and how it can improve developer productivity with host Priyanka Raghavan. The discussion explores various subtopics such as the history of copilot, how it can improve developer...
Eddie Aftandilian, Principal researcher at GitHub discusses GitHub copilot and how it can improve developer productivity with host Priyanka Raghavan. The discussion explores various subtopics such as the history of copilot, how it can improve developer...
Eddie Aftandilian, Principal researcher at GitHub discusses GitHub copilot and how it can improve developer productivity with host Priyanka Raghavan. The discussion explores various subtopics such as the history of copilot, how it can improve developer...
Peter Wyatt, CTO at PDF Association and project co-Leader of ISO 32000 (the core PDF standard), Duff Johnson CEO at PDF Association and ISO Project co-Leader and US TAG chair for both ISO 32000, discuss the 30 years' history of PDF, how to make a PDF...
Xe Iaso of Tailscale discusses how a VPN can be a useful tool when building software. SE Radio host Jeremy Jung spoke with Iaso about what VPNs are, onboarding, access control, authentication in the network vs individual services, peer-to-peer vs...
Tanmai Gopal, CEO of Hasura.io, joined SE Radio host Jeff Doolittle for a conversation about GraphQL. They discussed the history and rationale behind the original conception of GraphQL, as well as some of the use cases it is best suited for...
Jeff Perry, career coach with experience in multiple engineering and technology fields discusses how software engineers can be intentional and proactive in evaluating and pursuing career options, with host Kanchan Shringi.
Jonathan Shariat, coauthor of the book Tragic Design, discusses harmful software design. SE Radio host Jeremy Jung speaks with Shariat about how poor design can kill in the medical industry, accidentally causing harm with features meant to bring joy...
Adrian Kennard and Kevin Hones, Founders of FireBrick routers and firewalls, discuss how to design, build, test and support a hardware router and network operating system from scratch, while sharing the lessons learned. You'll also learn that in certain..
Brian Campbell, Distinguished Engineer at Ping Identity discusses cryptographic defences against stolen tokens for the OAUTH2 protocol with host Priyanka Raghavan. The discussion explores various subtopics such as the history of Proof of possession...
Randy Shoup of eBay discusses the evolution of eBay's tech stack. SE Radio host Jeremy Jung speaks with Shoup about eBay's origins as a single C++ class with an Oracle database, a five-year migration to multiple Java services, sharing a database...
In this episode, Abi Noda, founder of Pull Panda and DX, discusses developer experience with SE Radio host Brijesh Ammanath. They examine the basic concept of DX and its importance before diving into a wide variety of issues, including methodologies...
Jessi Ashdown and Uri Gilad, authors of the book "Data Governance: The Definitive Guide," discuss what data governance entails, why it's important, and how it can be implemented. Host Akshay Manchale speaks with them about why data governance...
Noah Gift, author of "Practical MLOps", discusses MLOps, which are tools are techniques used to operationalize machine learning applications. Host Akshay Manchale spoke to Noah about the foundational aspects such as basic automation through DevOps, data...
Phillip Mayhew of GameDriver discusses test automation for games and game-like applications. Host Philip Winston spoke with Mayhew about the increasing role of test automation in modern game development, the impact on the QA role, how to run tests...
John Ousterhout, professor of computer science at Stanford University, joined SE Radio host Jeff Doolittle for a conversation about his book, A Philosophy of Software Design. They discussed the history and ongoing challenges of software system design, especially the nature of complexity and the difficulties handling it. The conversation also explored various design concepts from the book, such as modularity, layering, abstraction, information hiding, maintainability, and readability.
Kumar Ramaiyer, CTO, Planning Business Unit at Workday, discusses the Infrastructure services needed for and the design of Building and lifecycle of supporting a SaaS application.
Karl Wiegers, Principal Consultant with Process Impact and author of 13 books, discusses specific software development practices that can help you make sure that you don't repeat the same problems he sees time and time again with every customer...
In this episode, SE Radio host Felienne spoke with Jordan Adler about code generation, a technique to generate code from specifications like UML or from other programming languages such as Typescript. They also discuss code transformation, which can be us
In this episode, we explore the popular pytest python testing tool with author Brian Okken, author of Python Testing with pytest. We start by discussing why pytest is so popular in the Python community: its focus on simplicity, readability, and developer ease-of-use; what makes pytest unique; the setup and teardown of tests using fixtures, parameterization, and the plugin ecosystem; mocking; why we should design for testing, and how to reduce the need for mocking; how to set up a project for testability; test-driven development, and designing your tests so that they support refactoring. Finally, we consider some complementary tools that can improve the python testing experience.
This week, senior software engineer, instructor, and blogger Swizec Teller spoke with SE Radio's Brijesh Ammanath about the "senior mindset." Becoming a senior engineer is about more than just years of experience but rather about cultivating a different..
Vandana Verma, Security Leader at Snyk and vice-chairperson of the OWASP Global Board of directors, discusses the "OWASP top 10" with host Priyanka Raghavan. The discussion explores various subtopics such as the history behind OWASP, the OWASP top 10 security risks, example of common vulnerabilities and ends with information on top projects in OWASP and how can contribute to it.
Gill Hoffer, co-founder and CTO at Salto, talks with SE Radio host Kanchan Shringi about a new persona -- the Business Engineer -- created by the rise of SaaS and adoption of best-of-breed business applications for back office systems. They examine...
Gill Hoffer, co-founder and CTO at Salto, talks with SE Radio host Kanchan Shringi about a new persona -- the Business Engineer -- created by the rise of SaaS and adoption of best-of-breed business applications for back office systems. They examine...
Tim Post of echoreply.io discusses Rubber Duck Debugging, a way to wrap your head about problems and solutions. Host Felienne spoke with Post about Rubber Duck debugging, and how it can help you to find answers to complex problems.
Ant Wilson of Supabase discusses building an open source alternative to Firebase with PostgreSQL. SE Radio host Jeremy Jung spoke with Wilson about how Supabase compares to Firebase, building an API layer with postgREST, authentication using GoTrue...
In this episode, Deepthi Sigireddi of the Cloud Native Computing Foundation (CNCF) spoke with SE Radio host Nikhil Krishna about how Vitess scales MySQL. They discuss the design and architecture of the product; how Vitess impacts modern data problems;...
Matt Butcher and Matt Farina, authors of the book Learning Helm join SE Radio host Robert Blumen to discuss Helm, the package manager for kubernetes. Beginning with a review of kubernetes and Helm, this episode explores the history of helm;...
Jérôme Laban, CTO of Uno Platform, joined host Jeff Doolittle for a conversation about Cross-platform User Interfaces. The conversation addressed the unique challenges and possibilities related to applications designed to run on multiple platforms...
Kevin Hu, co-founder and CEO at Metaplane discusses "Data Observability" with host Priyanka Raghavan. The discussion touches upon Data observability roots, components, differences with software observability and tooling.
Rob Hirschfeld CEO of RackN discusses Bare Metal as a Service. Host Brijesh Ammanath spoke with Hirschfeld about all things bare metal. Hirschfeld starts with the basics before doing a deep dive into bare metal configuring, provisioning, common failures..
Daniel Stenberg, founder and lead developer of cURL and libcurl, and winner of the Polhem Prize, discusses the history of the project, key events in the project timeline, war stories, favorite command line options and various experiences from 25 years of developing an Open Source project.
Daniel Stenberg, founder and lead developer of cURL and libcurl, and winner of the Polhem Prize, discusses the history of the project, key events in the project timeline, war stories, favorite command line options and various experiences from 25 years of developing an Open Source project.
Frank McSherry, Chief Scientist at Materialize talks to Host Akshay Manchale about Materialize which is a SQL database that maintains incremental views over streaming data. Frank talks about how Materialize can complement analytical systems...
Diarmuid McDonnell , a Lecturer in Social Sciences, University of the West of Scotland talks with host Kanchan Shringi about his experience as a social scientist on the need for computational approaches for data collection and analysis as well as the...
Omer Katz, a software consultant and core contributor to the Celery discusses the Celery task processing framework with host Nikhil Krishna. We discuss in depth, the Celery task processing framework, it's architecture and the underlying messaging...
Nikhil Krishna speaks to Bob DuCharme an experienced technical writer and author about how to write and maintain technical documentation for software products. In the episode different mediums to distribute documentation and tools to maintain documentation are discussed.
Sergey Gorbunov of Axelar discusses blockchain interoperability, a technology that enables decentralized applications to work across multiple blockchain ecosystems. Host Philip Winston spoke with Gorbunov about programmable blockchains, distributed vs. centralized changes, the Ethereum virtual machine, Axelar's Cross-Chain Gateway Protocol and Cross-Chain Transfer Protocol, security issues, delegated proof of stake...
Uma Chingunde of Render compares building a PaaS with her previous experience running the Stripe Compute team. Host Jeremy Jung spoke with Chingunde about the role of a PaaS, building on public cloud providers, build vs buy, choosing features, user experience, managing databases, Series A vs later stage startups, and why internal infrastructure teams should run themselves like product teams.
James Socol of Policygenius discusses continuous integration and continuous delivery, ways to test and deploy software quickly and easily. SE Radio host Felienne spoke with Socol about why CI and CD matter for the development process, what tools to use...
Richard L. Sites discusses his new book Understanding Software Dynamics, which offers expert methods and advanced tools for understanding complex, time-constrained software dynamics in order to improve reliability and performance. Philip Winston spoke with Sites about the five fundamental computing resources CPU, Memory, Disk, Network, and Locks, as well as methods for observing and reasoning when investigating performance problems using the open-source utility KUtrace.
This week, Postgres server developer Bruce Momjian joins host Robert Blumen for a discussion of multi-version concurrency control (MVCC) in the Postgres database. They begin with a discussion of the isolation requirement in database transactions (I in ACID); how isolation can be achieved with locking; limitations of locking; how locking limits concurrency and creates variability in query runtimes; multi-version concurrency control as a means to achieve isolation; how Postgres manages multiple versions of a row; snapshots; copy-on-write and snapshots; visibility; database transaction IDs; how tx ids, snapshots and versions interact; the need for locking when there are multiple writers; how MVCC was added to Postgres; and how to clean up unused space left over from aged-out versions.
Vaughn Vernon, author of the book “Strategic Monoliths and Microservices” discusses his book with host Akshay Manchale about strategies for purposeful architecture from the perspective of both business decision makers and technical leaders.
Robert Seacord, author of Effective C, The CERT C Coding Standard and Secure Coding in C and C++, discusses why the C programming language can be insecure, the top 5 security issues and the tools and techniques you can employ to write secure code in C.
Robert Seacord, author of Effective C, The CERT C Coding Standard and Secure Coding in C and C++, discusses why the C programming language can be insecure, the top 5 security issues and the tools and techniques you can employ to write secure code in C.
Ram Sriharsha of Pinecone discusses the role of vectors in machine learning, a technique that lies at the heart of many of the machine learning applications we use every day. Host Philip Winston spoke with Sriharsha about the basics of vectors, vector...
Sam Scott, CTO of Oso discusses how to build a global authorization service and challenges with host Priyanka.
Chase Kocher, the Founder and CEO of aim4hire, a technology recruitment agency, discusses the recruiting lifecycle from the candidate, the company and the recruiter’s point of view with host Kanchan Shringi.
Tim McNamara, author of Rust in Action, discusses the top three benefits of Rust and why they make it a performant, reliable and productive programming language.
Guest Sam Boyer, author of So you want to write a package manager talks about package management. The discussion covers - what is a package? what does it mean to manage package? package meta-data; package versioning; the quantity of packages in modern...
Chris Riccomini and Dmitriy Ryaboy discuss their book, The Missing Readme, which is intended to be the missing manual for new software engineers. Felienne spoke with Riccomini and Ryaboy about a range of topics that new software engineers might not have..
Davide Bedine, a cloud solution architect at Microsoft and professional Dapr enthusiast joined host Jeff Doolittle to discuss his book, Practical Microservices with Dapr and .NET. Dapr, the Distributed Application Runtime, simplifies cloud-native...
Bob Nystrom, author of Crafting Interpreters and a software engineer at Google working on the Dart programming language, discusses the key features of Dart which make it an excellent choice for fast apps on any platform.
Howard Chu, CTO of Symas Corp and chief architect of the OpenLDAP project, discusses the key features of B+Tree Data Structures which make it the default selection for efficient and predictable storage of sorted data.
Audrey Lawrence of Amazon discusses Timeseries Databases and their new database offering Amazon Timestream. Philip Winston spoke with Lawrence about data modeling, ingestion, queries, performance, life-cycle management, hot data vs. cold data...
Alexander Pugh discusses why and when to use Robotic Process Automation (RPA). Host Jeremy Jung spoke with Pugh about interacting with systems without APIs like mainframes; the importance of having developers involved when building bots; the difficulty...
Luke Hoban, CTO of Pulumi, joined host Jeff Doolittle for a conversation about infrastructure as code (IAC), which allows software development teams to configure and control their cloud infrastructure assets using code in contrast to other approaches...
Ipek Ozkaya joined host Jeff Doolittle to discuss a book she co-authored entitled Managing Technical Debt. In the book, Ozkaya describes nine principles of technical debt management to aid software companies in identifying, measuring, tracking...
Host Kanchan Shringi speaks with Venky Naganathan,Sr. Director of Engineering at Conga specializing in Artificial Intelligence and Chatbots about the Conversational UI paradigm for Enterprise Apps as well as the enablers and business use cases suited...
Luis Ceze of OctoML discusses Apache TVM, an open source machine learning model compiler for a variety of different hardware architectures with host Akshay Manchale. Luis talks about the challenges in deploying models on specialized hardware and how TVM.
Satish Mohan, CTO of AirGapNetworks discussed "Air Gapped Networks" with host Priyanka Raghavan.
Josef Strzibny the author of Deployment from Scratch discusses how and why it's valuable to learn how to self host applications.
Leonid Shevtsov talks with host Robert Blumen about email protocols and transactional email.
Rey Bango, Senior Director of Developer and Security Relations at Veracode discussed Secure coding with host Priyanka Raghavan.
Paul Butcher of AdaCore discusses Fuzz Testing, an automated testing technique used to find security vulnerabilities and other software flaws. Host Philip Winston spoke with Butcher about negative testing, brute-force fuzz testing...
Mike Del Balso, co-founder of Tecton discusses Feature Stores which are data platforms to operationalize Machine Learning applications. He talks about challenges faced by teams in creating custom data pipelines to serve models in production...
Liram Haimovitch talks about how a business handles customer issues with a software product. How issues start out with a dedicated customer-facing team and when they may be escalated to engineering.
CEO and security expert Jason Meller discusses modern tech stacks across a variety of programming languages to consider when building your next project or startup.
L Peter Deutsch of Aladdin Enterprises and formerly of Sun Microsystems joined host Jeff Doolittle to discuss the fallacies of distributed computing. Peter retold the history and origin of the fallacies and how they have been addressed over...
Dhruba Borthakur, CTO and co-founder of Rockset, discusses the use cases and core requirements of real-time analytics, as well as the evolution from batch to real time and the need for a new architecture with host Kanchan Shringi.
Networking researcher Iljitsch van Beijnum discusses internet routing and the border gateway protocol (BGP) with host Robert Blumen.
Kim Carter of BinaryMist discusses Dynamic Application Security Testing (DAST) and how the OWASP purpleteam project can improve early defect detection. Host Justin spoke with Carter about how DAST can provide meaningful feedback loops to developers...
Casey Aylward, Principal at Costanoa Ventures discusses Venture capital with a focus on early stage investing from the perspective of the entrepreneur and the VC with host Kanchan Shringi.
Trisha Gee and Kevlin Henney of 97 things every Java developer should know discusses their book, which is a collection of essays by different developers covering the most important things to know. Host Felienne spoke withGee and Henney about all things...
Rowland Savage, author of How to Stick the Landing: The M&A Handbook for Startups, discusses how company acquisitions work, the three types, and why it is so important for software engineering startups to know the details to make an acquisition happen.
Yaniv Tal discusses The Graph’s key features and also explains to user basics of blockchain infrastructure, Ethereum.
Felienne joins host Jeff Doolittle as a guest on the show to discuss her book, The Programmers Brain. While programmer’s brains are not special in comparison to the brains of others, they face unique cognitive challenges...
Evan Weaver of Fauna discusses the Fauna distributed database. Host Felienne spoke with him about its design and properties, as well as the FQL query language, and the different models it supports: document-based as well as relational.
Otakar Nieder, Senior Director of Development at Bohemia Interactive Simulations, discusses how simulation apps are different from gaming with host Kanchan Shringi.
Daniel Roth from Microsoft discusses Blazor’s key features and benefits of using c# full stack for building web apps with host Priyanka Raghavan.
Jeffery D Smith, author of Operations Anti-Patterns, DevOps Solutions, talks about how things can go wrong in development organizations and what DevOps has to offer with host Robert Blumen.
Tomer Shiran, co-founder of Dremio, talks about managing data inside a data lake, historical changes and motivations for managing data as a data lake, and the common tools and methods for ingestion, storage, and analytics on top of the underlying data.
Jamie author of Software Telemetry book discusses Software Telemetry, why telemetry data is so important and the discipline of tracing, logging, and monitoring infrastructure.
Thomas Richter is the founder of Swarm64, a Postgres extension company designed to boost performance of your Postgres instance. This episode examines the internals of Postgres, performance considerations, and relational database types.
Aaron Rinehard, CTO of Verica and author, discusses security chaos engineering (SCE) and how it can be used to enhance the security of modern application architectures.
Luke Kysow from Hashicorp does a deep dive into the key features of Consul with host Priyanka Raghavan.
Hadley Wickham, chief scientist at RStudio and creator of the Tidyverse, discusses how R and its data science package the TidyVerse are used and created. Host Felienne speaks with Wickham about the design philosophy of the Tidyverse, and how it supports..
Dan Moore, cofounder of Vaporware, discusses the benefits and drawbacks of building or buying software solutions, including evaluation criteria, how to inspect an API, and cost considerations for purchasing software from external vendors.
Matt Arbesfeld, cofounder of LogRocket, discusses the benefits and drawbacks of starting a software company as a software engineer, including finding cofounders, fundraising, and determining what ideas are worth pursuing.
Michael L. Perry discusses his recently published book, The Art of Immutable Architecture, distinguishing immutable architecture from other approaches and, using familiar examples such as git and blockchain, addresses some possible misunderstandings...
Nigel Poulton, author of The Kubernetes Book and Docker Deep Dive, discusses Kubernetes fundamentals, why Kubernetes is gaining so much momentum, deploying an example app, and why Kubernetes is considered "the" Cloud OS.
Thomas Graf, Co-Founder of Cilium, discusses eBPF and XDP and how they can be leveraged for a wide variety of use cases across networking, observability, and security.
Tug Grall of Redis Labs discusses Redis, its evolution over the years and emerging use cases today,its module based ecosystem and Redis’ applicability in a wide range of applications beyond being a layer for caching data such as search, machine learning
Felienne discusses diversity and inclusivity in software development with Shawn Wildermuth, Microsoft MVP and creator of the Hello World movie.
Arin Bhowmick, Global Vice President and Chief Design Officer at IBM, discusses why and how UX design for enterprise applications is different than for consumer applications.
James Smith, CEO and co-founder of Bugsnag discusses “Why it is ok to ship your software with Bugs.”
Alexis Richardson discusses gitops - a deployment model based on convergent infrastructure as code with host Robert Blumen.
JP Aumasson, author of Serious Cryptography, discusses cryptography, specifically how encryption and hashing work and underpin many security functions.
Andy Powell is the CISO of AP Moller Maersk and discusses the 2017 cyber attack that hit the company and the lessons learned for preventing and recovering from future attacks.
Tim Sneath, product management for Flutter and Dart at Google discusses what Flutter is, why it was created, where Dart came from, what the different layers of Flutter are, why it is so popular and why it makes a developers life much easier.
Yi Pan is the lead maintainer of the Apache Samza project and discusses the use cases for stream processing frameworks, how to use them, and the benefits & drawbacks of a framework like Samza.
Julie Lerman discusses Object Relational Mappers and Entity Framework with Jeremy Jung.
Julie Lerman discusses Object Relational Mappers and Entity Framework with Jeremy Jung.
Steven Skiena speaks with SE Radio’s Adam Conrad about practical applications for data structures and algorithms, as well as take-aways on how to best study Skiena’s book when prepping for the technical interview process.
Jay Kreps, CEO and Co-founder of Confluent discusses ksqlDB which is a database built specifically for stream processing applications to query streaming events in Kafka with SQL like interface.
brian d foy, author of many Perl books discusses what Perl 7 is, where it’s going, what you need to do to get ready and various pieces advice on making the most of your Perl and programming life.
Felienne spoke with Youens-Clark about new features in Python, why you should teach testing to beginners from the start and the importance of the Python ecosystem.
Felienne interviews Marco Faella about his book ‘Seriously Good Software,’ which aims to teach programmers to use six key qualities to better analyze the quality of their code bases.
Rob Skillington discusses the architecture, data management, and operational issues around monitoring and alerting systems with a large number of metrics and resources.
Matt Lacey, author of the Usability Matters book discusses what mobile app usability is and why it can make or break an app destined for consumers, business users or in-house users and what you can do to make the best app possible.
Sven Schleier and Jeroen Willemsen from the OWASP Mobile Application Security Verification Standard and Testing Guide project discuss mobile application security and how the verification standard and testing guide can be used to improve your app’s...
Philip Kiely discusses his book Writing for Software Developers. Software development primarily involves writing code but strong written communication skills are critical. Technical comprehension is vital but solid written communication skills are also...
Paul Smith discusses the Crystal Programming Language and the Lucky web framework with Jeremy Jung.
Sean Knapp of Ascend.io talks to Robert Blume about data pipeline automation with an orchestration layer.
Ryan Singer, Head of Strategy at Basecamp discusses the mindset and culture behind a successful remote work for engineers. Akshay spoke with Ryan about communication, collaboration and cultural aspects of working remotely.
Kanchan spoke with Michael Geers on the Micro Frontends. Micro Frontends is an architectural style that aims to extends the benefits of microservices to UI.
Doug Fawley of the gRPC project discusses gRPC with host Robert Blumen. Their conversation covers the HTTP layer, protobuf, and use cases within microservices architectures.
Kanchan spoke with Ryan Ripley about the pre-requisites for an organization to adopt scrum, need for management buy-in, the importance of scrum values and the key responsibilities of the roles defined by scrum and the anti-patterns to watch out for...
Host Kanchan Shringi spoke with Ellithorpe about defining the core essence of the CTO role, the skills that are key for success in the role, how to gain these skills and mentor others.
Vladimir Khorikov discusses functional programming in enterprise applications with Jeremy Jung.
Alex Petrov, author of Database Internals explains the ins and outs of database storage engines. What are they? How do they differ? What problems do they solve? Host Adam Gordon Bell spoke with Alex about these questions as well as how information...
Adam Shostack of Shostack & Associates and author of Threat Modeling: Designing for Security discussed different approaches to threat modeling, the multiple benefits it can provide, and how it can be added to an organization’s existing software proc
Berkay Mollamustafaoglu, founder of Ops Genie, discusses the keys to an effective incident management process. Many aspects of incident management are counter intuitive. Why does increasing the rate of change increase uptime? Why is culture the most...
Jens Gustedt, author of the Modern C book discusses Modern C, what is legacy C and all aspects of the C programming world with its historic flaws, modern improvements and simple beauty.
Spencer Kimball talks to Akshay Manchale about CockroachDB which is a distributed, resilient, SQL database system. He talks about challenges of using single node databases and features and principles behind CockroachDB that make it a better alternative open source database.
Felienne spoke with Gavis-Hughson about how to prepare for the dreaded 'whiteboard interview'.
Aaron Vonderhaar, maintainer and open source contributor to the Elm programming language, talks with host Adam Conrad about the Elm language, its foundations, features, and applications in the front end web development ecosystem.
Sara Leen discusses localizing, porting, and modernizing Japanese games with Jeremy Jung.
Joe Kutner, Software Architect for Heroku at Salesforce.com, spoke with host Kanchan Shringi about the 12-Factor App methodology, which aids development of modern apps that are portable, scalable, easy to test, and continuously deployable.
Felienne spoke with Mike McCourt on difficulties in processing voice data using machine learning.
Juval Löwy, Software Legend and Founder of IDesign discusses his recently published book, Righting Software, with host Jeff Doolittle. This episode focuses on Löwy’s belief that the software industry is in a deep crisis, evident from the numerous...
Torin Sandall of Styra and Open Policy Agent discussed OPA and policy engines and how they can benefit software projects security and compliance. Host Justin Beyer spoke with Sandall about the benefits of removing authorization logic from your application...
Yevgeniy Brikman, author of Terraform: Up & Running: Writing Infrastructure as Code and co-founder of Gruntwork talks with host Robert Blumen about how to apply best practices from software engineering to the development of infrastructure as code...
Bert Hubert, author of the open source PowerDNS nameserver discusses DNS security and all aspects of the Domain Name System with its flaws and history.
Felienne interviews Karl Hughes about doing tech talks. How to get into conferences and how to design and deliver a great talk.
Rich Harris, author of the JavaScript module bundler Rollup, discusses his JavaScript framework Svelte as a high-performance alternative to mainstay frameworks like React, Angular, and Vue. We begin with a brief overview of the framework and how...
Jeremy Miller, Senior Software Architect at Calavista Software, compares and contrasts his experiences with waterfall and agile methodologies. Host Jeff Doolittle spoke with Miller about the history of these methodologies and how teams can experience...
Michaela Greiler spoke with SE Radios Felienne about code review best practices and how to improve the effectiveness of your reviews.
Sumit Kumar, Head of Engineering at SHARE NOW talks with Jeremy Jung about creating mapping applications in JavaScript using the Leaflet library.
Adar Leiber-Dembo talks to SE Radio’s Akshay Manchale about Apache Kudu, a system for fast analytics in a column-based storage system. They explore how to leverage Kudu for data analytics, as well as its rich feature set and integration options with other SQL and analytical engines.
Pat Helland talks to host Akshay Manchale about Data Management at scale in a Microservices world. Pat talks about trends in managaging data in a distributed microservices world, immutability, idempotence, inside and outside data, descriptive...
Barry OReilly of Black Tulip Technology discusses Antifragile Architecture, an approach for designing systems that actually improve in the face of complexity and disorder.
Katharine Jarmul of DropoutLabs discusses security and privacy concerns as they relate to Machine Learning. Host Justin Beyer spoke with Jarmul about attack types and privacy-protected ML techniques.
Chris McCord, author of the Phoenix Framework and Programming Phoenix 1.4, discusses Phoenix's LiveView functionality to showcase the power or real-time applications without the need for writing a single line of JavaScript.
Jay Kreps, CEO of Confluent, talks with Robert Blumen about how an enterprise integration architecture organized around a Kafka event log simplifies integration and enables rich forms of data sharing. #podcast #seradio #ieeecs #ComputerSociety
Stephen Wolfram, creator of Mathematica and Wolfram Alpha discusses the wolfram language, the language behind both projects. Host Adam Gordon Bell spoke with Stephen Wolfram about computing, computational essays, building a language, notebook based...
Jeremy Howard from fast.ai explains deep learning from concept to implementation. Thanks to transfer learning, individuals and small organizations can get state-of-the-art results on machine learning problems using the open source fastai library...
Sam Procter of the SEI discusses architecture design languages, specifically Architecture Analysis and Design Language, and how we can leverage the formal modeling process to improve the security of our application design and improve applications overall.
Ryan Singer on Basecamp’s “Shape Up” software development process. Basecamp has ditched the backlog and 2-week sprint in favor of solution “shaping” and strategic 6-week projects, using tools like scope mapping, checklists, and hill charts to understand and reduce risk.
Bob Kepford discusses Decoupled CMS. Many CMS practitioners are adopting a decoupled approach to improve scale, allow for more specialized roles, and to separate data collection from delivery. Host Jeff Doolittle spoke with Kepford about what makes a Decoupled CMS different.
Abhinav Asthana, a founding partner and CEO of the API development tool Postman, discusses API design and testing, where to start, which types of APIs to offer, what tools you can use, what features to expose and what is his favorite API to reference.
WebRTC provides real time video and audio streaming capabilities to applications. Spencer Dixon explains the different parts of WebRTC and how they used it to build a pair programming application.
Evan Gilman and Doug Barth, authors of Zero-Trust Networks: building secure systems in untrusted networks discuss zero-trust networks.
Boris Cherny, author of Programming TypeScript, explains how TypeScript can scale JavaScript projects to larger teams, larger code bases, and across devices. Topics include: gradual typing, type refinement, structural typing, and interoperability...
Neil Madden, author of the API Security in Action book discusses the key requirements needed to secure an API, the risks to consider, models to follow and which task is the most important.
Michael Chan has been teaching React since 2013 and is the host of the React Podcast. He currently works at Ministry Centered Technologies as a Frontend Architect.
Josh Long, developer advocate at Pivotal, discusses using Spring Boot to efficiently develop production ready enterprise web applications. Josh talks about working with different databases, and developing and testing microservices using Spring Boot.
Felienne interviews Margaret Burnett on GenderMag, a systematic way to assess the inclusivity of software.
Felienne interviews Claire Le Goues about automatic program repair. Can programs repair themselves and what techniques are involved in that?
Joshua Davies discusses TLS, PKI vulnerabilities in the PKI, and the evolution of the PKI to make it more secure, with host Robert Blumen.
Heidi Howard, a researcher in the field of distributed systems, discusses distributed consensus. Heidi explains when we need it, when we don't need and the algorithms we use to achieve it.
Justin Richer, lead author of the OAuth2 In Action book discusses the key technical features of the OAuth2 authorization protocol and the current best practices for selecting the right parts of it for your use case.
Gabriel Gonzalez, the creator of Dhall the programmable configuration language, discusses configuration, why it is important and how we can make it better. Adam Gordon Bell spoke Gonzalez about Dhall, yaml, total functional programming and dealing...
Motivation comes through relationships, safety, and environments which allow everyone to contribute.
Joel Spolsky on founding Stack Overflow, land grabs vs. bootstrapping with profitability, raising more money using proof points, what developers and companies get massively wrong, choosing your next job, and how to ask and answer on Stack Over
Aaron Patterson of GitHub discusses the Ruby language and its runtime. Host Jeremy Jung spoke with Aaron about the Ruby language and how it works. They discuss the language virtual machine, concurrency, garbage collection, and JIT compilation.
Howard Chu, CTO of Symas Corp and chief architect of the OpenLDAP Project, discusses the key technical features of the Lightning Memory-mapped Database (LMDB) that make it one of the fastest, most efficient and safest embedded data stores in the world.
Chris Richardson of microservices.io and author of the book Microservice Patterns discuss microservice patterns which constitute a set of best practices and building-block solutions to problems inherent microservice architecture.
Learn how to simplify your application architecture with the introduction of a messaging system. You'll hear how different messaging patterns can make your application more flexible, easier to maintain, and improve its performance.
The use of distributed and remote software teams have grown dramatically in the past five years, presenting new challenges for managers and engineers alike. Bryan Helmig talks about the best practices his company, Zapier, uses to manage remote software...
Felienne talks to Diomidis Spinellis about different forms of debugging. From using print-statements to version-control systems and operating system tools. We also discuss debugging strategies for different types of programming systems.
Arnon Axelrod speaks with SE Radio’s Simon Crossley about test automation, a large complex subject that most listeners will have at least some familiarity with. Axelrod has worked in software engineering and test automation in several high-tech companie...
Today's guest is Thorsten Ball, author of Writing an interpreter in Go as well as its sequel Writing a Compiler in Go. Thorsten lives near Frankfurt, Germany. Thorsten loves to deep dive into programming topics like programming languages, interpreters...
Peter Zaitsev explains: avoiding vendor lock-in, judging what databases are bad at, why not to copy the big players, when to "go with the crowd", when to use cloud services vs. running your own infrastructure, and the role of containerization.
Jonathan Boccara, author of The Legacy Code Programmer’s Toolbox discusses understanding and working with legacy code. Working with legacy code is a key skill of professional software development that is often neglected.
Simon Riggs, founder and CTO of 2nd Quadrant, discusses the advanced features of the Postgres database, that allow developers to focus on applications whilst the database does the heavy lifting of handling large and diverse quantities of data.
Daniel Berg, a distinguished Engineer at IBM cloud unit, talks with host Nishant Suneja, about Istio service mesh and how it lets developers deploy microservices into the cloud in a secure, efficient fashion by taking away the burden of devops...
Pete Koomen, Co-founder and CTO at Optimizely discusses A/B testing. Edaena Salinas spoke with Pete about how A/B testing is used in software products, and how A/B tests can be written. Pete explained the components of A/B testing and lessons learned from running over 200,000 A/B tests.
How can you scale an engineering organization when you havent already experienced rapid growth? Jean-Denis Greze of Plaid explains how to proactively enhance team capabilities and readiness by leveling up through a maturity map.
Dr. Andrii Gakhov, author of the book Probabilistic Data Structures and Algorithms for Big Data Applications talks about probabilistic data structures and their application to the big data domain with host Robert Blumen.
Felienne interviews Adam Barr about code quality? Why do programmers pick up bad habits about programming and what can be done to improve that?
Tim Coulter, the founder of Truffle (Ethereum DApp development framework) discusses the Truffle framework for Ethereum SmartContracts and Decentralized App development. Kishore Bhatia spoke with Tim Coulter about: Ethereum Decentralized Apps (DApps)...
Randy Shoup talks with SE-Radio’s Travis Kimmel about how to scale technology and organizations together, so that an organization can move faster as they grow (and not slow down). Their discussion covers how to effectively scale culture, process...
Avi Kivity of Scylladb deep dives into the internals of Scylladb and what makes it a high performant version of Cassandra, a distributed key-value datastore. The discussion covers the architecture of Scylladb, its relationship with high performance...
Max Neunhoffer of ArangoDB discusses about multi-model databases in general, and open source ArangoDB, in specific, with show host Nishant Suneja. The show discussion covers motivation behind deploying a multi-model database in an enterprise setting, and deep dives into ArangoDB internals.
Travis Kimmel talks with Johnathan Nightingale about scaling engineering management. Their discuss when to hire additional engineering managers and how to set them up for success, how leaders can prepare for “growing pains” as an organization scales,
Bernd Rücker, who has contributed to multiple open source workflow management projects, discusses orchestrating microservices with workflow management. As distributed systems evolve into a family of microservices that must handle long-running stateful processes with time-dependent actions, events, multiple paths through the system, and complex rollbacks, the workflow management model provides a way to ensure clear modeling, correctness, and separation of concerns. Rücker recommends a federated model in which each microservice is paired with its own workflow to handle retries and other policies and failure modes around that service. Robert Blumen spoke with Rücker about microservice architecture, event-driven systems, long-running stateful processes versus synchronous request/response, event handling, time-outs, and handling exceptional conditions with compensating transactions. Rücker compares the choreography versus orchestration models for collaboration and discusses why orchestration provides a better separation of concerns. The discussion delves into the implementation of workflow management systems including persistence, scaling, event handling, timers and scheduling, and similarities to CQRS. The discussion wraps up with monitoring and visualization.
Vivek Ravisankar, the CEO and founder of HackerRank spoke with SE Radio’s Kishore Bhatia about automated coding skills assessments and the HackeRank platform. Topics include: HackerRank as a coding skills assessment platform and how such platforms help in skills assessments and coding interviews - both for developers and employers. The interview also covers the journey from developer learning to getting assessed & recruited through these platforms. Learning from Vivek’s experience giving coding interviews and automating the process of technical screening for Hiring Software Engineers.
Gary Rennie, a core contributor to Phoenix and Plug, discusses the Phoenix, a web framework for Elixir. Host Nate Black talks with Gary about the parts of Phoenix, writing a Phoenix application, and troubleshooting performance issues.
Felienne interviews Riccardo Terrell on his book Concurrency in .NET: Modern patterns of concurrent and parallel programming on concurrency, parallelism and immutability and common issues that developers run into when solving concurrent problems.
Guest Daniel Corbett discusses how to scale your application with the help of load balancing. Hear details on HAProxy and the load balancing ecosystem as a whole.
Edaena Salinas talks with Stephen Ewen about streaming architecture. Stephen is one of the original creators of Apache Flink. Topics discussed: stream processing vs batch processing, architecture components of stream architectures, Apache Flink...
Learn how to protect and speed up your application with the help of a Content Delivery Network. You'll also hear about advancements in CDNs that allow you to handle application logic and dynamic content at the edge.
Edaena Salinas talks with Pat Helland about Web Scale. Pat is a Principal Software Architect at Salesforce where he works on a cloud based multi-tenant database technology. The discussion covers: Datacenters and hardware, DevOps, developing at scale, stateless vs stateful services, preparing a system for failures and sql vs nosql databases.
Kishore Bhatia discussed Ethereum and Smart Contracts with John Crain. Topics include: understanding the motivations for a decentralized computing model, Application architecture on Ethereum, development frameworks and tools. John’s experience developing and launching his own product Pixura on Ethereum mainnet, approaches,
István Lam of Tresorit talks with host Kim Carter about GDPR (the EU General Data Protection Regulation, which has been described as “the most important change in data privacy regulation in 20 years.”) The discussion covers terminology, planning, implementation, users' rights regarding their personal data, managing personally identifiable information (PII) across an organization, and required documentation. István talks about establishing the intent of different types of PII; when data can be shared or sold, when PII can be stored; storage of backups, and the ability to reveal, modify, or remove all of a customer's PII.
Michael Hausenblas talks with host Kim Carter about topics covered in Michael’s ebook Container Networking, such as single vs. multi-host container networking, orchestration, Kubernetes, service discovery, and many more. Michael and Kim also discuss the roles that IPTables plays, how the allocation of IP addresses is handled, along with the assignment of ports. Overlay networks are covered along with topics such as the open Container Network Interface (CNI).
Travis Kimmel talks with Lara Hogan and Deepa Subramaniam about evidence-based tactics that product and engineering leaders can use to can use to diagnose problems that are holding back their teams, and build healthier, high-performing organizations.
Jafar Soltani of Rare (Microsoft Studios) discusses Continuous Delivery in AAA Games and how it can increase quality, reduce crunch, and deliver games faster. Topics include implementation and architecture, asset and delivery pipelines, and special challenges of games.
Brent Laster, author of a book on Jenkins 2, speaks with host Robert Blumen about the Jenkins 2 build server, CI/CD, DevOps and “pipeline as code”.
Ben Sigelman CEO of LightStep and co-author of the OpenTracing standard discusses distributed tracing, a form of event-driven observability for debugging distributed systems, understanding latency outlyers, and delivering "white box" analytics.
Saša Jurić, author of Elixir in Action, explains the Elixir programming language and how it unlocks the benefits of the Erlang ecosystem, revealing the “sweet spot” for Elixir programs: highly scalability and fault tolerant systems with a simple arc
Edaena Salinas talks with Maria Gorlatova about Edge Computing. Maria Gorlatova is an Associate Research Scholar at Princeton University Department of Electrical Engineering. The discussion covers: IoT, edge computing, the architecture of edge computing, running a machine learning model on the edge, and the benefits of edge computing.
Jeremy Jung talks with David Calavera about zero-downtime migrations and rollbacks with Kubernetes. In this episode we define migrations, rollbacks, and discuss how Netlify was able to migrate to Kubernetes and roll back off of it multiple times without impacting their users. David explains how developers can run old and new systems simultaneously, the importance of defining errors in your system, and when to apply fixes vs rolling back. We also discuss their decision to move to Kubernetes, and the benefits they received.
Felienne interviews Marian Petre & André van der Hoek on their book ‘Software Design Decoded’, which contains 66 scientifically backed insights for the design process.
Learn how a business that struggled with outages, performance problems, and an inability to ship overcame their problems by introducing monitoring, docker, continuous integration, and some fresh perspectives.
Travis Kimmel and Kevin Goldsmith discuss the correspondence between organizational design and software architecture. Their conversation covers: what Conway’s Law is; Kevin’s experiences in different organizational structures (e.g., Avvo, Spotify, Adobe, and Microsoft) and how those structures influenced the software architecture; what the “Reverse Conway Maneuver” is and how organizations can leverage it; how organizations can evolve existing architectures.
Natalie Silvanovich and Kim Carter discuss reducing the attack surface of the software that Engineers are creating today. Code sharing, third-party code, Developer workflow, and a collection of 0 day bugs are all discussed.
Felienne interviews Andreas Stefik about creating programs that are accessible for blind and visually impaired users. How do they consume and create software?
Postgres developer Bruce Momjian joins Robert Blumen for a discussion of the SQL query optimizer in the Postgres RDBMS. They delve into the internals of query planning and look at how developers can make it work for their apps.
Nate Black interviews Glynn Bird on using open source to develop your career or get a job, and how maximize productivity and learning. We discuss how to get your pull request accepted, how to make your own project successful, and how to survive updates.
Dmitry Jeremov and Svetlana Isakova speak to Matthew Farwell about the Kotlin programming language.
Edaena Salinas talks with Tammy Butow about Chaos Engineering. Tammy is a Principal Site Reliability Engineer at Gremlin. The discussion covers: how Chaos Engineering emerged, the types of chaos that can be introduced to a system, and how to structure...
What is code coverage, how can you measure it, and what are the pitfalls of this metric? Diomidis Spinellis talks with Marc Hoffmann, a key developer of the JaCoCo code coverage library for Java, on how code test coverage can improve software reliability
Bill Venners speaks to Matthew Farwell about Property Based Tests, how they can be used, when they should not be used. We also cover how to define a property, how to generate the data required for a property based test.
Péter Budai and Kim Carter discuss End to End Encryption (E2EE), backdoors, the scenarios where E2EE can be and should be used. IM, VoIP, Email scenarios, interservice communication scenarios such as securing data in use.
Kishore Bhatia discusses with Nate Taggart about Serverless. Topics include: understanding the motivations for this computing model, deep dive learning about Serverless architecture, development frameworks and tools. Learn from Nate’s experience with Serverless paradigm developing Operations tools at Stackery and find out various approaches, challenges and best practices for architecting and building Serverless applications.
Edaena Salinas talks with Nicole Hubbard at KubeCon 2017. They discuss why WP engine is migrating from VMs to Kubernetes and how the migration is structured. Nicole explained the VM infrastructure at WP Engine and why there was a need to move...
Felienne interviews Veronika Cheplygina about image recognition. We cover the basic concepts of computer vision, its applications and relationship to machine learning.
Kishore Bhatia talks with Travis Kimmel about Engineering Impact: In the age of data-driven decision making, how does one go about measuring, communicating, and improving engineering productivity? We’ll learn from Travis’ experience building data analytics tools in this space, with insights and best practices for engineering teams and business stakeholders for measuring value and productivity.
Nate Black talks with Nicolai Parlog about Java 9. Topics include: a timeline of Java features; new patterns enabled by Java 8 lambdas, default interface implementations and how they enable code evolution; how Java 9 takes this further with private default methods; an introduction to Java modules: the Java Platform Module System (JPMS); “launch time” dependency validation; module “requires” and “exports”: documentation as code and a new topic for code reviews; how to migrate an existing codebase to Java 9 and modules; benefits of Java modules: reliable configuration and a smaller Java runtime; the new Java release schedule.
Felienne interviews Jeroen Janssens about data science, examining the basic concepts, as well as the skills and tools needed to be(come) a data scientist.
Scott Piper and Kim Carter discuss Cloud Security. The Shared Responsibility Model, assets, risks, and countermeasures, evaluation techniques for comparing the security stature of CSPs. Scott discusses his FLAWS CTF engine. Covering tools Security Monkey and StreamAlert.
Kishore Bhatia talks with Conor Delanbanque about DevOps Hiring, building and retaining top talent in the DevOps space. Topics include DevOps as a special Engineering skill, building DevOps mindset and culture, challenges in hiring and retaining top talent and building teams and best practices for DevOps engineers and employers hiring for these skills.
Edaena Salinas talks with Sachin Gadre about the internet of things. The discussion begins with an overview of what IoT is and how businesses are adopting it. It then explores the architecture of an IoT application and the security implications of these systems.
Kirk Pepperdine talks with Diomidis Spinellis about performance optimization. Topics include development practices, tools, as well as the role of software architecture, programming languages, algorithms, and hardware advances.
Founder of Signal Sciences Zane Lackey talks with Kim Carter about Application Security around what our top threats are today, culture, threat modelling, and visibility, and how we can improve our security stature as Software Engineers.
Bryan Reinero talks with Gregor Hohpe about IT Transformation, the process by which organizations adapt and reorganize themselves in response to evolution and how the Enterprise Architect leads that transformation.
Bryan Reinero talks with Harsh Sinha, VP of Engineering at TransferWise, about Product Management. Mr. Sinha details how requirements are derived from user needs, how to measure product success, and how successful product management is done.
Ron Lichty talks with SE Radio’s Nate Black about managing programmers. Topics include: why programming management is hard, what makes a good programming manager, the costs of micromanagement, self-organizing teams, team dynamics and motivation, and product team performance.
Edaena Salinas talks with Charlie Berger about Predictive Applications. The discussion begins with an overview of how to build a Predictive Application and the role of Machine Learning. It then explores different Machine Learning algorithms that can be implemented natively in a database.
Felienne talks with Evgeny Shadchnev about Code Schools, programs that prepare people to become a software developer in a few months. This episode explores the idea of code schools. Can we really teach programming in a few months rather than in a few years in university? Who teaches at those programs? Who attends them? What are their business models and should we teach programming online or offline?
Felienne interviews Zachary Burt about freelancing as a career option. How does freelancing differ from employment? How to do personal marketing and sales? How to find a work-life balance when you are self-employed? We also cover practical tips like deciding on an hourly rate and managing demanding customers.
- Founder of Thinkst, Haroon Meer talks with Kim Carter about Network Security. Topics include how attackers are gaining footholds into our networks, moving laterally, and exfilling our precious data, as well as why we care and what software engineers can do about it.
Bryan Reinero talks with Jason Hand about handling outages and responding to failures. The episode explores basic problem-solving strategies and diagnostic techniques, organizing teams to address incidents efficiently, communicating with stakeholders, learning from incidents, and managing stress.
Nate Black talks with Jonathan Stark about platforms for mobile development, making decisions about how to develop mobile apps, how to deploy mobile apps, native apps vs. progressive web apps, React Native, and the future of mobile applications.
Robert Blumen talks to Edson Tirelli about business rules, rules engines, and the JBoss Drools engine.
Felienne talks with Moshe Vardi about P versus NP. Why is this problem so central to computer science? Are we close to solving it? Is it necessary to solve it? Progress toward computing hard problems efficiently with SAT solvers. How SAT solvers work,; applications of SAT like formal verification.
Kishore Bhatia talks with Kieren James-Lubin about Blockchains. Topics include Blockchains, Cryptocurrency, Bitcoin, Ethereum, Smart Contract development with Solidity, ICO’s and Tokens.
Edwin Brady speaks to Matthew Farwell about Type Driven Development and the Idris Programming language. The show covers: what a type is; static vs dynamic types in programming languages; dependent types; the Idris programming language; why Idris was created. Type safe printf modelling state in Idris modelling protocols in Idris modelling concurrency in Idris type driven development and how it changes the development process.
Felienne talks with Michael Feathers about Legacy Code. When is something legacy? Is working on legacy different from working on greenfield code? Do developers need different skills and techniques? Testing legacy code. How to test a legacy system? When do we have enough tests to feel safe to start coding? Techniques to make legacy systems more testable.
Asaf Yigal talks with SE Radio’s Edaena Salinas about machine learning in log analysis. The discussion starts with an overview of the structure of logs and what information they can contain. Asaf discusses what the log analysis process looks like without machine learning -- and the role of humans in this – before moving on to how the process is improved by incorporating external resources using machine learning. Topics include: log analysis, machine learning, operations.
Yakov Fain talks with SE Radio’s Matthew Farwell about the Angular web development framework. The show covers the philosophy behind Angular; who would want to use the framework; how an Angular application is composed, including how to handle form submission and validation; why Typescript was chosen for Angular; how Angular uses reactive programming (RxJS, in particular); how to test an Angular application; security concerns of web applications; who developed Angular and how it is supported, and performance considerations of an Angular application.
Phillipp Krenn talks with SE Radio’s Jeff Meyerson about Elasticsearch, a scalable search index. The conversation begins with a discussion of search, how it compares to database queries, and what an inverted index is. Phillipp introduces Wikipedia as an example that runs throughout the episode because Wikipedia uses Elasticsearch to power its full-text search. A discussion of Elasticsearch’s scalability ensues, including basic terminology and an explanation of other applications of Elasticsearch.
Morgan Wilde talks with SE Radio’s Jeff Meyerson about the LLVM compiler toolchain. They begin with a discussion of how a compiler works and how compiled code executes against different processor architectures. Using the JVM as a model for interoperability, they move on to how LLVM is a system that optimizes an intermediate representation (IR), which is similar to the Java bytecode: every programming language that compiles down to IR can leverage the same optimizations of that IR. The conversation concludes with a discussion of applications of LLVM and the future of the ecosystem.
Docker Security Team lead Diogo Mónica talks with SE Radio’s Kim Carter about Docker Security aspects. Simple Application Security, which hasn’t changed much over the past 15 years, is still considered the most effective way to improve security around Docker containers and infrastructure. The discussion explores characteristics such as Immutability, the copy-on-write filesystem, as well as orchestration principles that are baked into Docker Swarm, such as mutual TLS/PKI by default, secrets distribution, least privilege, content scanning, image signatures, and secure/trusted build pipelines. Diogo also shares his thoughts around the attack surface of the Linux kernel; networking, USB, and driver APIs; and the fact that application security remains more important to focus our attention on and get right.
James Turnbull joins Robert Blumen for a discussion of Terraform, an infrastructure-as-code tool, and a deep dive into how Terraform implements the declarative programming model.
Francois Raynaud and Kim Carter cover moving to DevSecOps from traditional delivery approaches. Shifting security focus up front. Building a development team with not only development specialties, but also security and operations.
Neal Ford chats with Kim Carter about the required skills of a Software Architect, creating and maintain them, transition roles. The importance of history, developing soft skills, and dealing with losing technical skills.
Show host Edaena Salinas talks with Katie Malone about Machine Learning. Katie Malone is a Data Scientist in the Research and Development department at Civis Analytics. She is also an instructor of the Intro to Machine Learning online course from Udacity and host of Linear Digressions, a podcast about machine learning. Topics include: machine learning, data science, a career in machine learning.
James Cowling of Dropbox tells Robert Blumen about their massive migration from Amazon’s S3 to their own distributed storage system.
John Allspaw CTO of Etsy speaks with Robert Blumen about systemic failures and outages. Why they cannot be totally prevented, how to respond, and what we can learn from them.
Felienne talks with Alexander Tarlinder on how to test as a developer. What can and should developers test?
Donny Nadolny of PagerDuty joins Robert Blumen to tell the story of debugging an issue that PagerDuty encountered when they set up a Zookeeper cluster that spanned across two geographically separated datacenters in different regions.
Edaena Salinas talks with James Whittaker about Career Strategy in the technology field. James is a Distinguished Technical Evangelist at Microsoft and author of “How Google Tests Software” and the viral blog post “Why I left Google”. Topics include: Career Management, the role of mentors and managers in your career, a discussion on 1:1 meetings, job specialization and advice on when to switch jobs.
Host Marcus Blankenship talks with Gerald Weinberg about his new book, Errors: Bugs, Boo-boos, and Blunders, focusing on why programmers make errors, how teams can improve their software, and how management should think of and discuss errors.
Eberhard talks with Florian Gilcher about the programming language Rust. Rust originates from Mozilla research. Its focus is on system programming and it is often used to replace C or C++. Topics include the concepts behind Rust; concurrent and safe programming; advanced and unique features like ownership and borrowing; the rust type system (which supports other features like traits, generics and macros). The show finishes with: the evolution of Rust based, features of libraries, and how the community works.
Felienne talks with Peter Hilton on how to name things. The discussion covers: why naming is much harder than we think, why naming matters in programming and program comprehension, how to create good names, and recognize bad names, and how to improve your naming skills.
Gil Tene joins Robert Blumen for a discussion of tail latency. What is latency? What is "tail latency"? Why are the upper percentiles of latency more relevant to humans? How is human interaction with an application influenced by tail latency? What are the economics of tail latency? What are the origins of tail latency within a system? What is the difference between response time and service time? How does queuing within a system contribute to response time? Java garbage collection and its contribution to latency outliers. How can we build systems with bounded tail latency out of components with variable latency? What type of observability to do we need to build systems with bounded latency? How is latency a driver of capacity planning?
Björn Rabenstein discusses the field of Site Reliability Engineering (SRE) with host Robert Blumen. The term SRE has recently emerged to mean Google's approach to DevOps. The publication of Google's book on SRE has brought many of their practices into more public discussion. The interview covers: what is distinct about SRE versus devops; the SRE focus on development of operational software to minimize manual tasks; the emphasis on reliability; Dickerson's hierarchy of reliability; how reliability can be measured; is there such a thing as too much reliability?; can Google's approach to SRE be applied outside of Google?; Björn's experience in applying SRE to Soundcloud - what worked and what did not; how can engineers best apply SRE to their organizational situation?; the importance of monitoring; monitoring and alerting; being on call, responding to incidents; the importance of documentation for responding to problems; they wrap up with a discussion of why people from non-computer science backgrounds are often found in devops and SRE.
Marcus Blankenship talks with Josh Doody about salary negotiation. Topics include a framework for thinking about salary negotiations, how you can know what you're worth, the employers view of salary negotiation, and missed negotiation opportunities. Also discussed are common fears about negotiating and how to overcome them, common mistakes during negotiations, and how negotiation makes your more desirable as an employee.
Felienne talks with Sam Aaron on Sonic Pi about how he designed Sonic Pi, a language, both for professional musicians performing with code as well as for schoolchildren.
Sven Johann talks with Steve McConnell about Software Estimation. Topics include when and why businesses need estimates and when they don’t need them; turning estimates into a plan and validating progress on the plan; why software estimates are always full of uncertainties, what these uncertainties are and how to deal with them. They continue with: estimation, planning and monitoring a Scrum project from the beginning to a possible end. They close with estimation techniques in the large (counting, empirical data) and in the small (e.g. poker planning).
Jeff Meyerson talks with Frances Perry about Apache Beam, a unified batch and stream processing model. Topics include a history of batch and stream processing, from MapReduce to the Lambda Architecture to the more recent Dataflow model, originally defined in a Google paper. Dataflow overcomes the problem of event time skew by using watermarks and other methods discussed between Jeff and Frances. Apache Beam defines a way for users to define their pipelines in a way that is agnostic of the underlying execution engine, similar to how SQL provides a unified language for databases. This seeks to solve the churn and repeated work that has occurred in the rapidly evolving stream processing ecosystem.
Jeff Meyerson talks to Idit Levine about Unikernels and unik, a project for compiling unikernels. The Linux kernel contains features that may be unnecessary to many application developers--particularly if those developers are deploying to the cloud. Unikernels allow programmers to specify the minimum features of an operating system we need to deploy our applications. Topics include the the Linux kernel, requirements for a cloud operating system, and how unikernels compare to Docker containers.
Jeff Meyerson talks with Brian Brazil about monitoring with Prometheus, an open source tool for monitoring distributed applications. Brian is the founder of Robust Perception, a company offering Prometheus engineering and consulting. The high level goal of Prometheus is to allow developers to focus on services rather than individual instances of a given service. Prometheus is based off of the Borgmon monitoring tool, widely used at Google, where Brian previously worked. Jeff and Brian discuss the tradeoffs of choosing not to replicate our monitoring data. In some situations, the monitoring system will lose data because of this decision. Other topics that are discussed are distributed consensus tools, integrations with Prometheus, and the broader topic of monitoring itself.
Eberhard Wolff talks with Phillip Carter about F# - a multi-paradigm programming language supporting object-oriented, imperative, and functional programming paradimgs. Its unique features make it especially fit for parallel programming or DSLs.
Kief Morris talks to Sven Johann about Infrastructure as Code and why it is important in the “Cloud Age”. Kief talks about the practices and benefits and why you should treat your servers as cattles, not pets.
Eberhard Wolff talks with Jürgen Höller about Reactive Spring. Reactive programming is a hot topic, but adoption has been slow in the enterprise. Spring 5 incorporates Reactor and the RxJava API to help Java developers build scalable high-performance web applications. The discussion explores architectural challenges, transactions, porting existing applications, and increased code complexity.
Charles Nutter from the JRuby project talks to Charles Anderson about JRuby and the Java Virtual Machine (JVM) as a platform for implementing programming languages. They begin by discussing the Java platform beyond just the Java language. As a case study in implementing a language other than Java on the JVM, they discuss JRuby - what it is and how it’s implemented on the JVM. They discuss recent additions to the Java platform like the invoke-dynamic byte code and lambdas in Java 8. The conversation concludes by discussing the future of the Java language, platform, and virtual machine.
Johannes Thönes talks to Patrick Kua about the role of a technical lead and how to become one. The show starts with introducing the concept of a lead and contrasts the lead role with other roles, such as technical manager, architect and senior developer. The discussion continues to the responsibilities of a tech lead (supporting engineering practices, managing, resolving conflict, and growing people). The discussion continues on to talk about the challenges of becoming a tech lead and how to overcome them and closes with the question: “how can you tell if you are succeeding as a tech lead”?
Charles Anderson talks with James Phillips about service discovery and Consul, an open-source service discovery tool. The discussion begins by defining what service discovery is, what data is stored in a service discovery tool, and some scenarios in which it’s used. Then they dive into some details about the components of a service discovery tool and how reliability is achieved as a distributed system. Finally, James discusses Consul, the functions it provides, and how to integrate it with existing applications, even if they use configuration files instead of a service discovery tool.
Stefan Tilkov talks to Camille Fournier about the challenges developers face when building distributed systems, whether the can avoid building them at all, and what changes occur once they do.
Sven Johann talks with Bill Curtis about Software Quality. They discuss examples of failed systems like Obama Care; the role of architecture; move an org from chaos to innovation; relation between Lean, quality improvement and CMM; Team Software Process.
David Heinemeier Hansson, creator of the Ruby on Rails framework and a partner at the software development company Basecamp, talks to Stefan Tilkov about the state of Ruby on Rails and its suitability for long-term development. He addresses some of its common criticisms, such as perceived usefulness for only simple problems, claimed lack of scalability, and increasing complexity. David also talks about the downsides of building JavaScript-centric, “sophisticated” web UIs, and why he prefers well-structured, “majestic” monoliths to microservices.
Jeff Meyerson talks to Haoyuan Li about Alluxio, a memory-centric distributed storage system. The cost of memory and disk capacity are both decreasing every year–but only the throughput of memory is increasing exponentially. This trend is driving opportunity in the space of big data processing. Alluxio is an open source, memory-centric, distributed, and reliable storage system enabling data sharing across clusters at memory speed. Alluxio was formerly known as Tachyon. Haoyuan is the creator of Alluxio. Haoyuan was a member of the Berkeley AMPLab, which is the same research facility from which Apache Mesos and Apache Spark were born. In this episode, we discuss Alluxio, Spark, Hadoop, and the evolution of the data center software architecture.
John Purrier talks with Jeff Meyerson about OpenStack, an open-source cloud operating system for managing compute resources. They explore infrastructure-as-a-service, platform-as-a-service, virtualization, containers, and the future of systems development and management.
Robert Blumen talks with Cody Voellinger, the founder of a recruiting firm that specializes in filling software engineer roles for San Francisco-area startups, about how jobs are created and how companies and engineers get matched up. Their discussion covers the entire job search process, from job descriptions to salary negotiations. They look at the job market from both sides: how companies define what they want, find the right people, and evaluate candidates, and how job seekers can position themselves for the role they want. Other topics include culture fit versus skill and resumes in an age of social networking. They conclude with a look at the mistakes that job seekers, recruiters, and companies should avoid.
Michael Nygard of “Release It!” fame talks with Stefan Tilkov about his experience using the Clojure programming language. Topics include the tool chain and development process, the Clojure learning curve, and on-boarding new developers. Michael explains the similarities and differences compared to typical OO languages when implementing domain logic, and uses both game development and typical web development projects as examples. Finally, the two discuss how well Clojure can be used in the face of long-running projects, and some typical obstacles and strategies for introducing it to real-world scenarios.
Monica Beckwith joins Robert Blumen for a discussion of java garbage collection. What is garbage collection? GC algorithms; history of GC in the java language; fragmentation and compaction; generational strategies; causes of pauses; impact of pauses on application performance; tuning GC; GC on multi-core and large memory machines; should production servers be implemented in non-GC languages?; going off heap and other programming techniques to avoid garbage; the future of java GC.
Mike Barker talks with Sven Johann about the architecture of the LMAX system. LMAX is a low-latency, high-throughput trading platform. Their discussion begins with what LMAX does; the origins of LMAX; and extreme performance requirements faced by LMAX. They then delve into systems that LMAX communicates with; LMAX users; the two main components of the system (broker and exchange); Mechanical Sympathy as an architectural driver; message flow using the Disruptor library; and lock-free algorithms. Mike and Sven wrap up by discussing how a well modeled domain model can improve the performance of any system; automated (performance) tests; continuous delivery; and measuring response times.
Fred George talks with Eberhard about "Developer Anarchy" - a manager-less development approach Fred has been using very successfully in different organizations - combined with microservices.
Robert Blumen talks to Christopher Meiklejohn about conflict-free replicated data types. The discussion covers consistency in distributed systems, CRDTs, and their use in NoSQL databases.
Martin Klose talks with Eberhard Wolff about Coderetreats - events where developers practice development techniques to become better programmers. He explains how to join such events and what it takes to do your own Coderetreat.
Alex Budzier of the Oxford Saïd Business School and Jürgen Laartz of McKinsey Berlin join Robert Blumen to talk about the their research on large IT project failures. Why do large projects fail and to what extent are these failures avoidable?
Johannes Thönes talks to Axel Rauschmayer about JavaScript and ECMAScript 6. They talk about the origin and version history. Then they dive into key JavaScript concepts and explain the features coming into the language with ECMAScript 6.
Sven Johann talks with Andrew Phillips about DevOps. First, they try to define it. Then, they discuss its roots in agile operations, its relationship to lean development and continuous delivery, its goals, and how to get started. They proceed to system thinking and what “You build it, you run it” means for a system when developers have pager duty.
They continue with the diversity of DevOps requirements among companies and industries; copying ideas versus finding your own way; culture, mindset, and recommended practices; and the mandatory tool chain. They wrap up by discussing architectural styles that support DevOps and DevOps costs versus benefits.
John Wilkes from Google talks with Charles Anderson about managing large clusters of machines. The discussion starts with Borg, Google’s internal cluster management program. John discusses what Borg does and what it provides to programmers and system administrators. He also describes Kubernetes, an open-source cluster management system recently developed by Google using lessons learned from Borg, Mesos, and Omega
Gernot Starke talks about arc42: an open-source set of templates he developed to document software architecture based on his practical experience with real projects. Also Gernot and host Eberhard then discuss how documenting architecture fits into agile processes and how to find the right amount of documentation for a system. They walk through the different parts of the arc42 templates covering requirements and the context of the system and the solution structure, including building blocks, runtime, and deployment. They discuss tooling, versioning, testing documentation, and how to keep documentation up to date.
Ben Hindman talks to Jeff Meyerson about Apache Mesos, a distributed systems kernel. Mesos abstracts away many of the hassles of managing a distributed system. Hindman starts with a high-level explanation of Mesos, explaining the problems he encountered trying to run multiple instances of Hadoop against a single data set. He then discusses how Twitter uses Mesos for cluster management. The conversation evolves into a more granular discussion of the abstractions Mesos provides and different ways to leverage those abstractions.
Josh Long talks to Activiti cofounder Joram Barrez about the wide world of (open source) workflow engines, the Activiti BPMN2 engine, and what workflow implies when you’re building process-driven applications and services. Joram was originally a contributor to the jBPM project with jBPM founder Tom Baeyens at Red Hat. He cofounded Activiti in 2010 at […]
Nathan Marz is the creator of Apache Storm, a real-time streaming application. Storm does for stream processing what Hadoop does for batch processing. The project began when Nathan was working on aggregating Twitter data using a queue-and-worker system he had designed. Many companies use Storm, including Spotify, Yelp, WebMD, and many others. Jeff and Nathan […]
Johannes Thönes interviews Jez Humble, senior vice president at Chef, about continuous delivery (CD). They discuss continuous delivery and how it was done at Go, CD, and HP firmware; the benefits of continuous delivery for developers; Conway’s law and cross-functional teams; scary releases and nonscary releases; fix-forward, blue-green deployments, and A/B testing; origins of continuous […]
Robert Blumen talks to Jon Gifford of Loggly about logging and logging infrastructure. Topics include logging defined, purposes of logging, uses of logging in understanding the run-time behavior of programs, who produces logs, who consumes logs and for what reasons, software as the consumer of logs, log formats (structured versus free form), log meta-data, logging […]
Jeff Meyerson talks to Jun Rao, a software engineer and researcher (formerly of LinkedIn). Jun has spent much of his time researching MapReduce, scalable databases, query processing, and other facets of the data warehouse. For the past three years, he has been a committer to the Apache Kafka project. Jeff and Jun first compare streaming […]
Guest Udi Dahan talks with host Robert Blumen about the CQRS (command query responsibility segregation) architectural pattern. The discussion begins with a review of the command pattern. Then a high-level overview of CQRS, which consists of a separation of a command processing subsystem that updates a write model from one or more distinct and separate, […]
James Turnbull joins Charles Anderson to discuss Docker, an open source platform for distributed applications for developers and system administrators. Topics include Linux containers and the functions they provide, container images and how they are built, use cases for containers, and the future of containers versus virtual machines. Venue: Internet Related Links James’s home page: […]
Adrian Cockcroft discusses the challenges in creating a dynamic, flexible, cloud-based platform with SE Radio host Stefan Tilkov. After briefly discussing the definition of “cloud computing,” Adrian explains the history behind Netflix’s move to the cloud (which he led). After highlighting some of the differences that have developers and architects must face, Adrian talks about […]
Johannes Thönes talks with Erich Gamma, Ralph Johnson and Richard Helm from the Gang of Four about the 20th anniversary of their book Design Patterns. They discuss the following topics: the definition of a design pattern and each guest’s favorite design pattern; the origins of the book in architecture workshops; the writing of the book […]
Grant Ingersoll, founder and CTO of LucidWorks, talks with Tobias Kaatz about his book Taming Text: How to Find, Organize, and Manipulate It. They begin by discussing popular existing systems for the automated understanding of contextual information. One such system, IBM Watson, drew attention for its victory in the “Jeopardy” game show. They proceed to […]
Johannes Thönes talks to James Lewis, principal consultant at ThoughtWorks, about microservices. They discuss microservices’ recent popularity, architectural styles, deployment, size, technical decisions, and consumer-driven contracts. They also compare microservices to service-oriented architecture and wrap up the episode by talking about key figures in the microservice community and standing on the shoulders of giants. Recording […]
Tobias Kaatz talks to former Kixeye CTO Randy Shoup about company culture in the software industry in this sequel to the show on hiring in the software industry (Episode 208). Prior to Kixeye, Randy worked as director of engineering at Google for the Google App Engine and as chief engineer and distinguished architect at eBay. […]
Johannes talks with Rachel Laycock and Max Lincoln from ThoughtWorks about continuous delivery on Windows. The outline includes: introduction to continuous delivery; continuous integration; DevOps and ChatOps; decisions to be taken when implementing continuous delivery on windows; build tools on windows; packaging and deploy on windows; infrastructure automation and infrastructure as code with chef, puppet […]
Micro services is an emerging trend in software architecture that focuses on small, lightweight applications as a means to avoid large, unmaintainable, monolithic systems. This approach allows for individual technology stacks for each component and more resilient systems. Micro services uses well-known communication schemes such as REST but also require new technologies for the implementation. […]
Josiah Carlson discusses Redis, an in-memory single-threaded data structure server. A Redis mailing list contributor and author, Josiah talks with Robert about the differences between Redis and a key-value store, client-side versus server-side data structures, consistency models, embedding Lua scripts within the server, what you can do with Redis from an application standpoint, native locking […]
With this episode, Software Engineering Radio begins a series of interviews on social/nontechnical aspects of working as a software engineer as Tobias Kaatz talks to Randy Shoup, former CTO at KIXEYE, about hiring in the software industry. Prior to KIXEYE, Randy worked as director of engineering at Google for the Google App Engine and as […]
Charles Anderson talks to Mitchell Hashimoto about the Vagrant open source project, which can be used to create and configure lightweight, reproducible, and portable development environments. Vagrant aims to make new developers on a project productive within minutes of joining the project instead of spending hours or days setting up the developer’s workstation. The outline […]
Johannes Thönes talks to Dr. Ken Collier, Director of Agile Analytics at ThoughtWorks about Agile Analytics. The outline includes: descriptive analytics, predictive analytic and prescriptive analytics; artificial intelligence, machine learning, data mining and statistics; collaborative filtering; data science and data scientists; data warehousing and business intelligence; online analytical processing (OLAP), extract transform load (ETL), feature […]
Eberhard Wolff talks with Martin Lippert of Pivotal about the Eclipse Flux project. This projects is in its early stages — and has a very interesting goal: It aims to put software development tools into the cloud. It is a lot more than just an IDE (integrated development environment) in a browser. Instead the IDE […]
Robert talks to Dr. Anil Madhavapeddy of the Cambridge University (UK) Systems research group about the OCaml language and the Mirage cloud operating system, a microkernel written entirely in OCaml. The outline includes: history of the evolution from dedicated servers running a monolithic operating system to virutalized servers based on the Xen hypervisor to micro-kernels; […]
Leslie Lamport won a Turing Award in 2013 for his work in distributed and concurrent systems. He also designed the document preparation tool LaTex. Leslie is employed by Microsoft Research, and has recently been working with TLA+, a language that is useful for specifying concurrent systems from a high level. The interview begins with a […]
Andrew Gerrand works on the Go programming language at Google. His conversation with Jeff begins with a history of the language, including the details behind how Go was conceived and how the open source community contributes to it. Andrew explains how Go intends to simplify problems which have been motifs as Google has scaled. The […]
Martin Thompson, proprietor of the blog Mechanical Sympathy, founder of the LMAX disruptor open source project, and a consultant and frequent speaker on high performance computing talks with Robert about computer program performance. Martin explains the meaning of the term “mechanical sympathy,” derived from auto racing, and its relevance to program performance: the importance of […]
For Episode 200 of Software Engineering Radio, Diomidis Spinellis interviews Markus Völter, the podcast’s founder. Markus works as an independent researcher, consultant, and coach for itemis AG in Stuttgart, Germany. His focus is on software architecture, model-driven software development and domain specific languages as well as on product line engineering. Markus also regularly publishes articles, […]
Recording Venue: Skype Guest: Michael Stonebraker Dr. Michael Stonebraker, one of the leading researchers and technology entrepreneurs in the database space, joins Robert for a discussion of database architecture and the emerging NewSQL family of databases. Dr. Stonebraker opens with his take on how the database market is segmented around a small number of use […]
Recording Venue: WebEx Guest: Wil van der Aalst Robert Blumen interviews Professor Wil van der Aalst of the Technical University of Eindhoven, one of the world’s leading researchers in business process management and workflow systems. Professor van der Aalst leads off with an overview of the main concepts in the field business processes, business process […]
Recording Venue: WebEx Guest: Lars Vogel Lars Vogel, consultant, Eclipse committer, and owner of vogella.com, gives an overview of the Android operating system. His conversation with Jeff begins with a definition of Android and a brief history. Android is an operating system programmed in Java. It can be found on different types of devices such […]
Recording Venue: WebEx Guest: Jim Benson Jim Benson is CEO of Modus Cooperandi, a collaborative management consultancy in Seattle, Washington. After being steeped in Agile for many years, Jim started working with Kanban and Lean thinking in 2005. In 2008, he started taking this idea further with Personal Kanban, which brings flow based work to the […]
Recording Venue: WebEx Guest: Ellen Gottensdiener and Mary Gorman Ellen Gottensdiener and Mary Gorman of EBG Consulting talk with Neil Maiden about agile projects, requirements practices and their new book entitled Discover to Deliver: Agile Product Planning and Analysis. The conversation begins with an exploration of how agile has changed requirements and project practices over the […]
Recording Venue: Skype Guest: Michael Hunger Michael Hunger of Neo Technology, and a developer on the Neo4J database, joins Robert to discuss graph databases. Graph databases fall within the larger category of NoSQL databases but they are not primarily a solution to problems of scale. They differentiate themselves from RDBMS in offering a data model built […]
Recording Venue: Skype Guest: Grant Ingersoll Grant Ingersoll, founder of the Mahout project, talks with Robert about machine learning. The conversation begins with an introduction to machine learning and the forces driving the adoption of this technique. Grant explains the three main use cases, similarity metrics, supervised versus unsupervised learning, and the use of large data […]
Recording Venue: Swiss Federal Institute of Technology, Zürich Guest: Georg von Krogh Open source development has had a major impact on both private and public development and use of software. This is an interview with one of the key researchers on open source development, Professor Georg von Krogh of the Swiss Federal Institute of Technology in […]
Recording Venue: Skype Guest: Douglas C. Schmidt In this episode we talk with Douglas C. Schmidt, who is a professor of computer science at Vanderbilt University and a well-respected authority in the fields of patterns and frameworks for concurrent and networked software. In this interview we talk about these topics in the context of massive […]
Recording Venue: WebEx Guest: Christof Ebert Christof Ebert, managing director of Vector Consulting Services talks with Frances Paulisch on his insights to how lean applies to product development. The interview centers around five key principles of lean development, namely end-to-end focus on creating value for the customer, eliminating waste, optimizing value streams, empowering people, and […]
Recording Venue: Skype Guest: Eric Lubow Eric Lubow and Robert discuss polyglot persistence, a term used to describe systems that incorporate multiple specialized persistent stores rather than a single general-purpose database. Eric provides insights into the forces driving this trend: including diverse data usage patterns, low latency, and increasing volumes of data. The emergence of […]
Recording Venue: Paddington, London Guests: Suzanne Robertson and James Robertson, Atlantic Systems Guild Neil Maiden, Editor of the Requirements column in IEEE Software, talks with Suzanne and James Robertson of the Atlantic Systems Guild about the emergence and impact of agile practices on requirements work. The interview begins with an exploration of how agile practices have […]
Recording Venue: Lucene Revolution 2012 (Boston) Guest: Grant Ingersoll Grant Ingersoll, a committer on the Apache Solr and Lucene, talks with Robert about the problems of full-text search and why applications are taking control of their own search, and then continues with a dive into the architecture of the Solr search engine. The architecture portion of the […]
Recording Venue: Skype Guest: Martin Fowler and Pramod Sadalage In this episode, we talk with Pramod Sadalage and Martin Fowler about database evolution and agile database development. We discuss the basic challenges for working with a database in an agile development culture and how to include database design and most of all, database evolution, in […]
Recording Venue: MongoSF, San Francisco Guest: Dwight Merriman As application data size and throughput have outgrown the processing and storage needs of commodity servers, replication has become an increasingly important strategy. In this episode, Robert talks with Dwight Merriman about database replication. Topics covered include replication basics, master-slave versus master-master, failure and recovery, replication versus […]
Recording Venue: Phone Guest: Jeff Frey System z, or the Mainframe, holds most of us in awe — the ultimate computing platform, referenced in Hollywood as well as by those who thought they were dealing with “legacy” systems — but what does Mainframe really mean? What does its stack look like? This leading virtualized infrastructure […]
SE Radio will continue producing podcasts under the wings of IEEE Software, a respected magazine published by the IEEE Computer Society.
In this episode, Markus talk with Martin Fowler and Rebecca Parsons about domain-specific languages.
In this episode we talk with Rini van Solingen about scrum and agile software development in distributed settings.
In this episode Michael interviews Jurgen Appelo on the topic of leading agile developers.
Cassandra is a distributed, scalable non-relational data store influenced by the Google BigTable project and many of the distributed systems techniques pioneered by the Amazon Dynamo paper.
Recording Venue: Phone Guest: Steve Will IBM i (formerly known as OS/400) is an advanced object-based operating system by IBM that runs thousands of businesses around the world. Steve Will, the Chief Architect of IBM i speaks with us about the history, technical features, and underlying architecture discussing the concepts of Single Level Store, integrated […]
We talk with Martin Laforest about topics ranging from how quantum computing works, which different models of quantum computing are explored, current and future uses of the approach as well as the current state of the art.
We discuss characteristics and performance properties of modern games and outline the challenges for software development.
Guest: Wilbert Albers Host: Markus In this episode we take a look at microchip production, with a special focus on waferscanners. To do this, we talked with Wilbert Albers of ASML, the leading waferscanner manufacturer in the world. In the episode, we talk about the overall chip production process (from silicon sand over wafer cutting […]
Recording Venue: University of Passau Guest: Sven Apel Host: Stefan In this second episode on Feature-Oriented Software Development (FOSD), Sven Apel gives us an overview of programming language and tool support for FOSD. He introduces the Eclipse-based FeatureIDE which covers important phases of the FOSD process, namely domain implementation as well as configuration and generation. […]
Sven Apel explains why developing software in a feature-oriented manner is so vital for us as software engineers and why objects are simply not enough.
In this episode Michael talks with Bas Vodde about how to apply agile principles to large and distributed development organizations.
In this episode, Robert talks with Nati Shalom about the emergence of large-system architectures consisting of a grid of high-memory nodes.
This time we have John Wiegand on the mic for an episode on architectures and agile software development. We talk about the role of architectures in an agile world and why architectures change and need to change over time. We discuss the characteristics of those living architectures, using the Eclipse and the Jazz projects as examples, and the surrounding development methods for such environments.
Dwight Merriman talks with Robert about the emerging NoSQL movement, the three types of non-relational data stores, Brewer's CAP theorem, the weaker consistency guarantees that can be made in a distributed database, document-oriented data stores, the data storage needs of modern web applications, and the open source MongoDB.
This episode covers the topic of agile testing. Michael interviews Lisa Crispin as an practionier and book author on agile testing. We cover several topics ranging from the role of the tester in agile teams, over test automation strategy and regression testing, to continuous integration.
Jay Kreps talks about the open source data store Project Voldemort. Voldemort is a distributed key-value store used by LinkedIn and other high-traffic web sites to overcome the inherent scalability limitations of a relational database. The conversation delves into the workings of a Voldemort cluster, the type of consistency guarantees that can be made in a distributed database, and the tradeoff between client and the server.
In this episode, we discuss with Roman Pichler how Scrum impacts product management and how agile product management differs from traditional approaches. The topics covered include product owners on large projects and product owner teams, facilitating customer feedback through early and frequent releases, envisioning the product, and creating products with the minimum functionality. Enjoy!
This episode is a conversation with Ramnivas Laddad about aspect-oriented programming (AOP), Aspect J, and Spring AOP. We review the fundamental concepts of AOP, discuss AspectJ (an open source compiler that extends java with support for AOP), and cover the Spring Framework's proxy-based AOP system. Laddad also gives his thoughts on the use cases for AOP and where we are in the technology adoption curve, and updates on the state of the AspectJ project itself.
This episode is a conversation with Scott Meyers about the upcoming C++0x standard. We talk a bit about the reasons for creating this new standard and then cover the most important new features, including upport for concurrency, implicitly-typed variables, move semantics, variadic templates, lambda functions, and uniform initialization syntax. We also looked at some new features in the standard library.
This episode is a coversation with Rich Hickey about his programming language Clojure. Clojure is a Lisp dialect that runs on top of the JVM that comes with - among other things - persistent data structures and transactional memory, both very useful for writing concurrent applications.
Philip Zeyliger of Cloudera discusses the Hadoop project with Robert Blumen. The conversation covers the emergence of large data problems, the Hadoop file system, map-reduce, and a look under the hood at how it all works. The listener will also learn where and how Hadoop is being used to process large data sets.
This episode is part of our series on agile software development. We talk with David Anderson about Kanban, an agile software development method that is quite different from most of the other agile methods out there. We discuss the basic ideas behind Kanban, the differences between Kanban and Scrum and when and why projects can benefit from using Kanban. This episode is done in cooperation with the German magazine ObjektSpektrum (thanks for sharing this interview with us).
In this episode Johannes Link interviews Lasse Koskela - the author of "Test-Driven" - about test-driven development (TDD). We cover the basics, the rationale behind it and the challenges you face when doing it in more difficult environments.
This is a conversation with Ola Bini on his experimental language Ioke. We cover the idea behind the Ioke experiment as well as important language concepts and the thinking behind them.
This episode is a conversation with Jan Bosch about product line engineering (PLE). Jan has worked in various roles and industries and academia in the context of product lines. In this episode we look at Jan's view of what is next for product lines: software ecosystems. What is their relationship to PLE and how should PLE change to remain relevant?
Our guest Johan Bezem explains the idea behind and the benefits of MISRA. MISRA defines guidelines for C and C++ programming in order to ensure quality. While it got started for embedded automotive development, it is more generally applicable.
This episode is a discussion with Shane Clifford, who is a development manager at Intentional Software. We discuss the idea behind intentional programming, key concepts of the technology as well as example uses and a little bit of history.
This episode is a conversation with "Uncle Bob" Bob Martin about agile software development and software craftsmanship specifically. We talk about the history of the term, the reasons for coming up with it some of the practices and the relationship to other agile approaches. We conclude our discussion with an outlook on some of todays new and hyped programming languages.
Michael discusses with his guest Chuck Connell the differences between software engineering and computer science. What makes software engineering so unpredictable, with so few formal results? And how can we advance the field of software engineering without these results?
Dave explains why reading source code is at least as important a skill as writing source code. He shares approaches for how to get to grips with unknown and undocumented source code even if it is non-trivial in size. He finishes with advice for how to get started reading code.
Michael and Markus discuss what makes a good R&D manager and how to potentially become an R&D manager. You will learn what some of the essential skills are, what the challenges are, and what the 'mission/vision/strategy thing' is actually good for.
This episode is a discussion with various authors of patterns reviewed at EuroPLoP 2009. Topics include Product Line Engineering, Distributed Development, Open Source and Embedded Systems
In this episode we discuss the current state of the spring framework. We talk about core features (dependency injection, AOP) but also about the spring universe, i.e. some of the more specific frameworks such as Spring Batch.
In this episode we talk with Doug Simon from Sun Microsystems Laboratories about the Maxine Research VM, a so-called meta-circular virtual machine. Maxine is a JVM that is written itself in Java, but aims at taking JVM development to the next level while using highly integrated Java IDEs as development environments and running and debugging the VM itself directly from the Inspector, an IDE-like tool specialized for the Maxine VM. During the episode we talk about the basic ideas behind Maxine, what exactly "meta-circular" means and what makes it interesting and promising to build a Java VM in Java. We talk about the relationship to Sun's current production JVM (HotSpot) and about ideas and directions for the future of Maxine.
This episode is a discussion with Jim Des Rivieres about APIs: How to design good APIs, the role of the documentation/specification in APIs, API evolution and other relevant topics.
This is another episode recorded at OOP 2009, thanks to SIGS Datacom and programme chair Frances Paulisch for making this possible. Here is the abstract from the conference program: Many software systems have fragile architectures that are based on brittle assumptions or rigid architectures that reduce options and make change difficult. On the one hand, an architecture needs to be fit for the present day, suitable for immediate use, and on the other it needs to accommodate the future, absorbing reasonable uncertainty. However, an approach that is overly focused on today's needs and nothing more can create an inflexible architecture. An approach that becomes obsessed with possible future changes creates an overly complex architecture that is unfit for both today's and tomorrow's needs. Both approaches encourage an early descent into legacy for a system. The considerations presented in this talk reflect an approach that is more about thinking in the continuous present tense than just the present or the future tense. This includes principles from lean thinking, practices common in agile processes and techniques for loosely coupled design.
In the first part of this episode we discuss a couple of basics about SecondLife (scaling, partitioning, etc). The second part specifically looks at how the dev team tackled a number of interesting problems in the context of executing their own LSL scripting language on top of Mono.
This episode is a conversation with Gilad Bracha about Newspeak, type systems in general and optional/pluggable types in particular. It was recorded during DSL Devcon in the gardens of the Microsoft campus, and thanks to Gilad's "speaking like a book" way of talking it is published completely unedited :-)
This episode is once again with Linda Rising, this time on the book she coauthored with Mary Lynn Manns on introducing ideas into organizations. The talk is another one of the SE Radio Live sessions recorded at OOP 2009 - thanks to SIGS Datacom and programme chair Frances Paulisch for making this possible.
In this episode, Allan shares his insights about how learning is a necessary part of software development. He covers the personal as well as the team and the organizational level and offers practical advice.
In this episode, Arno talks to Jim Melton about the SQL programming language. In addition to covering the concepts and ideas behind SQL, Jim shares stories and insights based on his many years' experience as SQL specification lead.
In this episode, Dirk talks with David Frankel, resident Metamodeller and MDA expert at SAP Labs LLC, SAP's subsidiary in the Silicon Valley. Dave's extensive experience provides a big picture, from the early days of CORBA all the way to current issues that are bugging most enterprise architects' work with MDA.
In this episode Michael interviews one of our regular listeners: Petri Ahonen. Petri introduces Software Configuration Management by defining key terms and describing relevant concepts.
This episode is a discussion with Michael Nygard about his book "Release It" which covers aspects of software architecture you often don't think of initially when starting to build a system. Some of the points we discussed were capacity planning, recovery as well as making the system suitable for operation in a data center.
In this episode Markus discusses with Chris Read basics and some advanced topics in the space of continuous integration. We cover concepts, some tools, as well as a number of best practices.
This is a discussion with Eoin Woods about his collection of top 10 software architecture mistakes. Looking at things that don't work is always a good way to learn what you should actually do.
This episode is an interview with Tom DeMarco and Peter Hruschka about the new book of the Altantic Systems Guild: Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior.
This is a session recorded live at OOP 2009. SE Radio thanks Tom and Peter, SIGS Datacom and the programme chair, Frances Paulisch, for their great support!
This episode is a discussion about code and metrics visualization with Michele Lanza. Michele invented the Code Cities idea about which he talks in this episode.
The majority of hacker attacks (70 %) are directed at weaknesses that are the result of problems in the implementation and/or architecture of the application. This session shows how you can protect your web applications (J2EE or .NET) against these attacks. The session covers lots of practical examples and techniques for attack. Furthermore, it shows strategies for defense, including a "Secure Software Development Lifecycle". A "Live Hacking" demo rounds it out.
This is a session recorded live at OOP 2009. SE Radio thanks Bruce, SIGS Datacom and the programme chair, Frances Paulisch, for their great support!
This episode is an introduction to user interface design with Joachim Machate of UID. We talk about the importance of user interface design, about its relationship to the overall software engineering process, as well as about UID's process for systematic user interface design.
In this episode we take a brief look at Jetbrains' Meta Programming System, a language workbench for creating external DSLs or for extending existing languages (such as Java). In a brief telephone discussion, Konstantin Solomatov explains what the system does and how it works. The system has recently been released into public beta and will be made available under then Apache 2.0 Open Source license.
In this episode Martin talks with Chris Grindstaff about the fundamentals of performance engineering. The episode discusses when and how to work on performance of client- and server-side systems, what you should take into account during development to avoid performance issues, typical situations that cause performance problems, and some common pitfalls when analysing performance.
In this episode we look at SUN's open source strategy for the OpenJDK. We discuss challenges in creating such a big open source project, and ways to keep it focused and organized. We discuss what it means for the Java runtime to be adopted as the technological foundation for other programming languages.
In this episode we discuss Microsoft's OSLO platform with Doug Purdy and Don Box. We briefly discuss what OSLO is in general and then look at the various components of OSLO. We also look at how OSLO fits in with the general Microsoft strategy and how it compares to other DSL/Model-driven approaches. We then look at language modularization and composition and discuss the similarities with XML and Smalltalk. Finally, we discuss possible integrations of OSLO with other MD* approaches and technologies.
This is a discussion with Janos Sztipanovits about Cyber Physical Systems and how DSLs are used to approach some of the challenges in that domain. Specifically, in the second part we talk about formalizing DSL semantics.
In this episode, Michael Plöd is interviewed about Object-Relational Mapping technology. He talks about the common concepts, compares the range of different tools that go by this name, and goes into the design and architectural consequences of using an OR mapper.
In this episode we're talking to Anneke Kleppe about model-driven software development and language engineering. We start with her involvement in the creation of the Object Constraint Language (OCL) and discuss the intial expactations, actual experiences, and the place of OCL in the current day. From here, Anneke talks us through her take on the formative years of UML and MDA. From here, we expand to the realm of Domain-Specific Languages and Anneke discusses their place in software engineering in general and why we should expect DSLs in significant numbers to become a common sight.
In this episode, Markus talks with Juha-Pekka Tolvanen about using DSLs and code generation in practice. The main part of the episode is the discussion about a number of case studies that show how DSLs and code generation are used in practice.
- Omega Tau, Markus' new podcast mentioned in the beginning of the show
In this episode we're talking to Eelco Visser about parsing text. We start at the basics - what is parsing? - covering classic tools such as Yacc and classic parsing approaches such as LALR before examining how more recent approaches such as scannerless parsing can make parsing easier and enable previously impractical use cases.
In this episode we're talking to Bran Selic of Malina Software about modelling in general and UML2 in particular. Bran covers the basics of modelling, the history of UML, and what's new in UML2.
In this episode we're talking to James A. Hendler about the semantic web. We start with a definition of the semantic web and by discussing the main ingredients. We then look at (more or less) related topics such as prolog, artificial intelligence, wisdom of the crowds, and tagging. In the next section we discuss the core semantic web technologies: RDF, OWL, inference engines, SPARQL, and GRDDL. We conclude our discussion by looking at the status of the semantic web today and a couple of example applications.
During Evolution of a software system, it becomes more and more difficult to understand the originally planned software architecture. Often an architectural degeneration happens because of various reasons during the development phases. In this session we will be looking how to avoid such architectural decay and degeneration and how continuous monitoring can improve the situation (and avoid architectural violations). In addition we will look at "refactoring in the large" and how refactoring can be simulated. A new family of "lint like tools for software architectures" is currently emerging in the marketplace I will show some examples and how they scale and support you in real world projects.
In this episode we talk to Christof Ebert about requirements engineering. As the name "engineering" suggests, we need to be systematic when working and managing requirements. Christof will structure RE into several activities, namely elicitation (identifying the relevant requirements), specification (clearly describing requirements), analysis (synthesizing a solution), verification and validation (achieving good requirements quality), comittment (allocating requirements to a project, product release or iteration), and management (keeping track of the implementation status of requirements). In this episode we discuss these activities and highlight lots of practical guidance.
In this episode we talk with Jeff McAffer about building platforms. We start with a brief discussion about what a platform is in contrast to a framework or an application. Drawing from his experiences working on the Eclipse platform for years, Jeff talks with us about how to develop platforms, why developing a platform is different from developing an application, what makes a good platform great, and why API design becomes so extremely important for platforms. He provides us with some insights on how the development process and the client collaboration for platform development could look like and what has and has not worked in the past.
This is the second part of the two part topic on roles in software engineering. Michael and Markus discuss role definitions in a corporate environment. For several typical roles we give hints on the expected skills, knowledge, and mindset. In this episode we discuss the roles technical lead, technologist, requirements engineer, product manager, and project manager.
In this episode we discuss the status of SE Radio today and introduce the team members. Among other things, Markus discusses stats, sound quality, partners, transcripts, and the cooperation with Hillside Europe. Also, the team members introduce themselves with a one to two minute clip.
This is the first part of a two part topic on roles in software engineering. Michael and Markus discuss role definitions in an corporate environment. For several typical roles we give hints on the expected skills, knowledge, and mindset. In this episode we discuss the roles junior developer, senior developer, and software architect.
In this episode we discuss with Randy Shoup, Distinguished Architect at eBay, about architectural pinciples and patterns used for building the highly scalable eBay infrastructure. The discussion is structured into four main ideas: partition everything, use asynchrony everywhere, automate everything, and design the system keeping in mind that everything fails at some point in a large distributed system.
We start our discussion with a brief look at what Haskell is and how a pure functional language is different from non-pure languages. We then look at the basic building blocks and the philosophy of the language, discussing concepts such as the lambda calculus, closures, currying, immutability, lazy evaluation, memoization, and the role of data types in functional languages. A significant part of the discussion is then spent on the management of side effects in a pure language - in other words, the importance of monads. We conclude the episode with a look at Haskell's importance and community today.
This episode is a discussion with Andrew Watson, Technical Director of the Object Management Group. The episode is structured into five parts. We start with the history of the OMG and its early work. Then we look at the set of standards it has been (or is currently) working on. Next is a discussion of the standardization process used by the OMG, including the much-debated topic of compliance testing. We then look at OMG's relationship to other standards bodies (W3C, OASIS). Finally Andrew and I briefly discuss our common passion, gliding :-)
This episode is a systematic introduction to Aspect Oriented Programming (in contrast to the interview with Gregor Kiczales). We discuss the fundamentals of AOP, define many of the relevant terms and also look at how and where AOP is used in practice, as well as at some current research trends.
In this episode we're talking to Linda Rising about retrospectives. We start by defining what a retrospective is and discuss some of the logistics of making it work for software projects. We then look at the different phases of a retrospective. The main part then is a discussion about some of the practices or games that are used to facilitate the retrospective. We conclude the retrospective discussion with destroying some of the prejudices against it and the relationship to process improvement and CMM. At the end of the interview we talk a little about Linda's current interest: how does the brain work?
In this episode we talk with Klaus Marquardt about building systems out of plugins. After briefly introducing the concept of a plugin in contrast to modules and related software engineering concepts, we discuss different views on plugins and different ways of working with plugins for developing software. We are looking at plugins for embedded systems as well as large business systems, at how plugins change the working mode and team organization, and discuss the possibilities of why and when to use plugins for implementing software systems.
In this episode we're talking to Jens Coldewey about his experiences in 10 years of introducing agile techniques to project teams. We discuss real-world examples and the lessons learned and strategies derived from them.
In this espisode we take a closer look at relational database systems and the concepts behind them. We start by discussing the relational paradigm, its concepts and ramifications, and go on to architectural aspects.
In this episode we're talking to Andreas Zeller. about debugging. We started the discussion with an explanation of what debugging and how it works in principle. We then briefly discussed the relationship between debugging and testing. Next was the importance of the scientific method for debugging. We then looked as debugging as a search problem, leading to a discussion about delta debugging, the main topic of this discussion. We concluded the discussion by looking at the practical usability of delta debugging and the relationship to other means of automatically finding problems in software.
In this episode we're talking to Hans-Joachim Popp, CIO at DLR about software in space. We start out by reviewing some well-known accidents of unmanned space flight that were caused by software faults and use this as a motivation to discuss how to avoid these in the future. We discuss culture, process, techniques and tools that DLR uses to create high-quality software for use in unmanned space systems.
This episode takes a close look at transactions from different angles, starting with their fundamental properties of Atomicity, Consistency, Isolation, Durability but also investigating advanced topics like distributed or business transactions.
In this episode we discuss REST (Representational State Transfer) with Stefan Tilkov. We started out by discussing the 5 steps to REST: IDs, links, Standard Methods, multiple representations and stateless communication. We then looked at how to use HTTP for REST, and discussed about how to use it for Web Services. We then we discussed whether and how to use REST for enterprise applications, and not just for apps on the internet. We concluded the discussion with a couple of recommendations.
In this episode we have the pleasure of talking to Anders Hejlsberg, Chief Language Strategist at Microsoft. We started by discussing his more distant past, namely, his involvement with Turbo Pascal and Borland's Delphi. We then looked at the influences Delphi had on C# and how C# evolved from Delphi. In the next section we discussed a couple of general language design issues, among them components and checked vs. unchecked exceptions. Next, we discussed interesting issues about languages of the future, static vs. dynamic typing, functional programming, meta programming as well as the importance of good support for concurrency. We concluded the discussion by looking at the interplay between languages and IDEs.
This episode is the long-awaited (and much requested) interview with Krzysztof Czarnecki, the author, together with Ulrich Eisenecker, of the book Generative Programming.
In the interview we discussed the state of generative programming today and related it to model-driven development and DSLs. We then talked a little bit about product lines in general. We then discussed his current field of research, which currently focusses on framework-specific modeling languages and non-trivial roundtrip engineering.
In this episode we talk to Matthew Wall (Guardian News and Media) and Erik Doernenburg (Thoughtworks) about their work on the new guardian.co.uk website. We discuss the challenge of scalability and interactivity, their use of Domain Driven Design, some of the technical building blocks as well as the approaches they use for performance measuring and scalability tuning.
In this episode we're talking to Dirk Riehle about open source business models. We started looking at the way OS projects work and defined different kinds of open source projects. In the main part of the discussion we looked at various ways of how to make money with open source: consulting, support contracts, commercial variant of an open source project, etc. We then looked at the chances and risks of each of these approaches. The next part focused on different open source licenses and how they are suitable for open source business. We concluded the episode by discussing a couple of specific questions and loose ends.
After the show, Dirk informed me about the following three corrections: Black Duck Software's main product is called protexIP not IP Central, there are presently 70 licenses approved by the Open Source Initiative, and EnterpriseDB has so far acquired $37M in venture capital
In this episode, Markus talks to Rebecca Wirfs-Brock on what she has learned from architecture reviews. This is a very complement to the earlier episode on architecture evaluation.
In this Episode, Arno talks with Oliver Jucknath about the art of writing computer games. A lot of myth is attached to this area of computing, and while a game technically is just another program, it is written in a different context than typical business applications.
This is true at the code level, where aggressive optimization is a focus throughout development. It also applies at the team level, where collaboration between specialists is pronounced. And the business context is different as well, which in turn influences the development effort as a whole.
In this episode, we talk with Kevlin Henney about the C++ programming language. We look at the history and the culture of the language, and how it went through several phases in its evolution. We also take a look at some of the special language features of C++ and their overall influence.
In this episode Charles Krueger, a well-known member of the product line engineering community, talks about his long term experiences in the field. Charles is also the founder and CEO of a company that provides tooling for variability management and product derivation. Besides some clarifications on terms like product line architecture and reference architecture, you also learn what kind of preconditions need to exist before product line engineering can be applied successfully.
In this Episode we're talking about Erlang with its creator Joe Armstrong. We started by looking at the history of the Erlang language and why it is so relevant today.
We then looked at Joe's approach to Concurrency Oriented Programming and its main ingredients: share nothing, lightweight concurrency and pure message passing. We also compared this to the classic shared memory approach to concurrency. We then looked at other interesting aspects of Erlang, such as its functional nature (and why this is important to concurrency) and pattern matching. Next we discussed how to implement distribution and fault tolerance, and we took a look at OTP, the "application server" for Erlang.
We concluded the conversation with a littel discussion about how Erlang was designed, it's current community as well as its future.
In this episode we talk to Galen Hunt about the Singularity research OS. Galen is the head of Microsoft's OS Research Group and, together with a team of about 30 other researches, has built Singularity.
We started our discussion by covering the basics of Singularity: why it was designed, what the goals of the project are as well as some of the architectural foundations of Singularity: software isolated processes, contract-based channels and manifest-based programs. In this context we also looked at the role of the Spec# and Sing# programming languages and the role of static analysis tools to statically verify important properties of a singularity application.
We then looked a little bit more closely at the role of the kernel and how it is different from kernels in traditional OSes.
In a second part of the discussion we looked at some of the experiments the group did based on the OS. These include compile-time reflection, using hardware protection domains, heterogenerous multiprocessing as well as the typed assembly language
We closed the conversation with a look at some of the performance characteristics of Singularity, compatibility with traditional operating systems and a brief look at how the findings from Singularity influence product development at Microsoft.
In this episode, Michael and Markus talk about software components. We first looked at a couple of attempts at defining what a component is. We then provided our own definition that will be used in the rest of the episode. We then looked at the promises of component-based development: why are components useful?
We then discussed some of the typical metadata components should specify to make them useful. We discussed to some extent typical variations in component models. The next topic was the separation of concerns between the component functionality and functionality provided by the component's execution environment (aka. container). We then compared components with other (more or less) related technologies such as OO and SOA.
We concluded the episode with the notion of architecture as language, where you use a formal DSL to describe a system's architecture. Components are the basic building block for this approach.
This episode is an interview with Dave Thomas (OTI Dave or Smalltalk Dave, not PragDave). We started our discussion with a look at the (non-)success of objects and components. We then discussed some history behine Eclipse and Dave's role in OTI. We then compared Smalltalk and Ruby and looked at the promises of small and powerful languages such as Lisp. We also discussed the role of (static) type systems and the role of tool support for languages.
We then switched gears and looked at what is necessary to scale agile development to the level of large organizations and how techniques from lean production and manufacturing as well as product management can play an important role.
In the last part of the interview we looked at the state of research today, and especially the relationship between industry and academia in this area.
We concluded the interview with Dave's opinion on what it takes to be a good developer.
In this Episode we're talking about Web Services with IBM's Olaf Zimmermann. We mainly focus on the WS- stack. We also discuss a couple of SOA foundations and architectural decisions that need to be taken when building an SOA using Web Serivces. We also briefly mention the REST vs. WS- debate.
In this Episode we're talking with Dick Gabriel on Lisp. We started by looking at artificial intelligence as the historic context of Lisp, the goals AI tried to reach, and how Lisp was supposed to help reach those.
We then discussed the language itself, starting with the Data As Program / Program As Data concept that is a foundation for Lisp. Then we discussed adding a meta-circular interpreter, programming as language development, and the blurred boundary between language and frameworks (because everything uses the same syntax). We then talked about Lisp's type system and the importance of macros to extend the language.
The next section concerned CLOS, the Common Lisp Object System and its important concepts: generic functions, multimethods, mixins, and method combination. We also briefly looked at the meta-object protocol but agreed this is a topic for a separate episode. After a discussion about the various dialects of Lisp and Scheme, we concluded the Lisp discussion by explaining why Lisp did not really catch on ("AI Winter") and Lisp's role in today's industry.
We ended the episode with a couple of details about Dick's other life as a poet and his Poem a Day effort.
Make sure you listen till the end, where we have added a song about Lisp (courtesy of Prometheus Music.)
In this episode we talk with Jeff DeLuca about Feature Driven Development (FDD). As one member of the agile methods family FDD is not so famous as Scrum or Extreme Programming but is becoming more and more popular, especially for situations where you have fixed price contracts. As the inventor of FDD Jeff gives short introduction to the method itself, talks about the basic ideas behind FDD and discusses with us how FDD relates to other members of the agile family.
In this episode Eberhard Wolff speaks with Jürgen Höller, the co-found of the Spring framework. Spring is a tremendously successful Java framework so they discuss the design of large frameworks and the issues that arise in the evolution. Jürgen explains the management of dependencies in the framework, how to structure such a framework, how to offer compatibility for the existing user base while evolving the framework and the role of metrics during development.
This episode is a conversation with Erich Gamma. We covered the four things he is known for in chronological order. We started with design patterns and the Gang-of-Four book of which he is the lead author. We then looked at JUnit, the testing framework he coauthored with Kent Beck and how it introduced unit testing to the masses. The next topic is obviously Eclipse, where Erich and his lab in Zürich is responsible for the Java Development Tooling. We also briefly discussed The Eclipse Way, the (obviously) successful process the Eclipse team uses for developing Eclipse itself. Finally, we're looking at Erich's current endeavour, the Jazz project. Jazz is a technology for collaborative software development.
This episode is about OSGi, the dynamic module system for Java. Our guests are Peter Kriens (OSGI's Technical Director) and BJ Hargrave (OSGI's CTO). We'll discuss what OSGi is all about and why and in which contexts it is useful. Additionally we are having a look at the different layers of OSGI and where and how they are used. Other questions discussed are: What means dynamicity in an OSGI environment? Where is OSGI used? What’s the future of OSGI? How does OSGI interact with existing middleware solutions? How can I run several versions of the same JAR at the same time? Where are OSGI’s problems?
In this Episode we're discussing patterns for small memory software with the authors of the like-named book Charles Weir and James Noble. We look at various aspects of the small memory problem: How can you manage memory use across a whole system? What can you do when you have run out of primary storage? How can you fit a quart of data into a pint pot of memory? How can you reduce the memory needed for your data? How do you allocate memory to store your data structures? Answers to all those questions are provided in this Episode, and of course in their book.
This is the second part of the discussion on fault tolerance with Bob Hanmer (if you didn't listen to Episode 77, which contains part one, please go back and listen now; this episode builds on that previous one!)
We start by discussing a set of error detection patterns. Among are the well-known approaches such as checksums and voting. We then look at error recovery patterns, including restart, rollback or roll forward. The next section looks at error mitigation patterns, which include shedding load and doing fresh work before stale. The last patterns section then looks at fault treatment patterns.
We conclude the episode with a small discussion about how to design systems using (these and other) patterns, and with some thoughts on why actually wrote the book.
In this Episode we discuss fault tolerance based on the new book by Bob Hanmer. This is the actually the first part of the discussion, the remainder will be published in the next episode of SE Radio.
We start by discussing some of the context for fault tolerant systems and the imperfect world assumption. We then discuss a number of terms we will need when discussing the fault tolerance patterns. We then discuss the fault tolerance mindset and connect fault tolerance to a number of related subject areas, such as software quality. We then discuss the shared context for the patterns that follow, among them the important observation that fault tolerance does not come for free!
Finally we provide an overview over the different sections covered in the book and start the detailed discussion of the patterns by looking at the Architectural Patterns section.
The next episode will discuss the remaining patterns in the book.
In this special Episode we briefly discuss the upcoming Patterns Journal with the two editors, Ralph Johnson and James Noble.
In this special Episode we briefly discuss our new website. We will migrate to our new website during the coming week. If you experience any difficulties, contact the team or temporarily go to the old site at seradio.libsyn.com.
Enterprise Architecture is already common practice in most Fortune 100 companies. As the topic is comparably young, knowledge about it is not so widespread in the Software Architects Community, who deals mostly with project architectures. In this episode Alex speaks with Wolfgang Keller who has practical experience as an enterprise architect and has written a book on the topic. He is a Partner with BusinessGlue Consulting. They are specializing in the relationship between EAM and SOA. This episode gives a rough overview what Enterprise Architecture actually is touches the standards in the field and also gives hints on the practical work of Enterprise Architects.
This episode is a conversation with Bruce Powel Douglass on real time systems. We started by discussing what real time software is, and explored the difference between hard and soft real time. We then looked at different scheduling strategies, and the meaning of terms like urgency and importance in the context of scheduling. Next was a discussion of typical architectural styles for real time systems and how architectures are described in this context. This led us to a discussion about the importance of modeling, formalisms and languages as well as the role of automatic code generation from those models. We then looked at how to model QoS aspects and the role of SysML for modeling real time systems. We then had a brief look at which programming languages are used these days for real time systems and the role of static analysis to determine various properties of those programs in advance. The last part of the discussion focused on some best practices for building real time systems, the challenges in distributed real time systems and how real time systems can be tested effectively.
This episode is a discussion with Erik Meijer on LINQ. This is a relatively technical discussion about the following topics: what is LINQ, what are the common abstractions between the different data structures one can access with LINQ, what is the relationship to established languages for querying, how does the integration into the type system of the host language work, how to specify the mapping between the language level classes and the data, and how optimizations are implemented (lazy loading, prefetching, etc.).
In this Episode I talk about the results of the listener survey and reply to some of the suggestions and criticism expressed in survey replies.
In this episode we talk with Gerard Meszaros about problems and challenges doing unit testing in real-world projects. Starting from a short discussion about the importance of automated unit testing we spend most of this episode to talk about every day problems doing unit testing and how those problems can be solved. Based on this book on xunit testing patterns, Gerard talks about his experiences with unit test smells as an analogy to code smells. He describes an impressive set of unit testing patterns to overcome those difficult testing situations and illustrates them with nice examples everybody doing unit testing will feel familiar with.
This Episode is part five in our (probably ongoing) series on service oriented architecture. In this episode we talk to Nico Josuttis, who has recently published a book on this topic. As its title "SOA in Practice" suggests, it is a very pragmatic book based on Nico's experience as architect and project lead in a number of enterprise-level projects - not all of them had been called SOA, since they at the time the term was not yet coined. The episode discusses some technical aspects of SOA (such as loose coupling, messaging and ESBs), but mainly focusses on non-technical aspects of implementing an SOA.
This episode features a discussion with Dan Grossman about an essay paper he wrote for this year's OOPSLA conference. The paper is about an analogy between garbage collection and transactional memory. In addition to seeing the beauty of the analogy, the discussion also serves as a good introduction to transactional memory (which was mentioned in the Goetz/Holmes episode) and - to some extent - to garbage collection.
This is a roundtable discussion on model-driven software develoment and product line engineering. It was recorded at the Model-Driven Development and Product Lines: Synergies and Experience conference in October 2006 in Leipzig. The panelists are: * Axel Uhl, SAP * Danilo Beuche, Pure Systems * Juha Pekka Tolvanen, MetaCase * Tom Stahl, b+m * Ruediger Schilling, Delta Software Technology
This episode features an interview with the software security expert Gary McGraw. Gary explains why this topic is so important and gives several security deficiencies examples that he found in the past. The second half of the interview is about his latest book 'Exploiting Online Games' where he explains how online games are hacked and why this is relevant to everybody, not only gamers in their 'First Life'.
This episode is an introduction to embedded system. It is an introduction in the sense that we cover many topics very briefly: upcoming episodes will provides details for many of these topics. We start by discussing what an embedded system is an what the important characteristics are. Among them is limited resources, concurrency, real time and hardware integration. We also discuss the range of embedded systems from small mirocontrollers to mobile phones to distributed real time embedded systems. We also cover the different business case for embedded systems (per unit cost) and some non-trivial developmental aspects (cross compilation debugging, heisenbugs). We close the episode by discussing some important architectural styles (time triggered, event-based, microkernels, state machines) as well as tools of the trade: languages, operating systems and middleware.
In this episode we talk about the relationship between software architecture and the business. Based on his book, Beyond Software Architecture we discuss how things such as branding, licensing, updating or different deployment scenarios influence the technical architecture of a system. We also discuss issues such as portability that add a huge amount of complexity, although from a business perspective it often does not make much sense. In the second part of the interview we discuss how the technical team and the business team can improve the way they work together. We look at some of the games (such as Buy a Feature or Give them a Hot Tub) from his new book Innovation Games, which discusses how to use collaborative play to be more creative and innovative in product creation.
In this Episode we talked about the new POSA 4 book which has recently been published. We talk to two of the authors, Kevlin Henney and Frank Buschmann (the third author, Doug Schmidt was not available - and he had also been on the podcast a couple of times :-)). The book contains a pattern language for distributed systems. It contains 114 patterns that had been published before by many different other authors. The patterns have been rewritten to form a consistent language. We basically talked through the different sections of the book, which gives a really good overview over the challenges and the solutions of building distributed systems. These sections include From Mud to Structure, Distribution Infrastructure, Event Demultiplexing and Dispatching, Interface Partitioning, Component Patitioning, Application Contrl, Concurrency, Synchronization, Object Interaction, Adaptazion and Extension, Modal Behaviour, Resource Management and finally, Database Access.
The book references several other previous works (as listed below). Interestingly, many of these referenced works and authors have also been discussed previously on the podcast. Here are the back references:
- Domain Driven Design, Eric Evans
- Messaging Patterns, Gregor Hohpe
- POSA 2 Patterns, Doug Schmidt
- Concurrency: Part 1, Part 2, Part 3 and the interview with Goetz and Holmes
- Remoting Patterns Part 1 and Part 2
- POSA3, Resource Management
In this Episode we talk about the Scala language with its creator Martin Odersky. Scala is a language that fuses object oriented and functional programming. Martin started out by providing a two-minute overview over the language, and then talked a little bit about its history. We then discussed the basics of functional programming. The main part of the episode features a discussion of some of the important features of the Scala language: * Case Classes and Pattern Matching * Multiple Inheritance and Compound Types, Traits, Mixins * Closures * Functions as types, "Function pointers", Anonymous functions * Higher Order Functions * Currying * (Sequence) Comprehensions * Generics * Type Bounds (Upper, Lower) * Static/Dynamic Typing, Type Inference * Operators * Implicits
We then talked about Scala's actors library, a highly scalable concurrency package. The last part of the episode covered some more general topics, such as where and how Scala is used today, IDE support and the user and developer community. We concluded the episode by looking at current development and next steps in Scala language evolution.
This show takes a behind-the-scenes look at compilers and their inner workings, using the Gnu compiler collection (GCC) as an example. Arno interview Morgan Deters, covering all steps from the parsing of different programming languages to machine independenet optimizations and generating processor specific binary code.
This episode features Scrum, a very popular Agile software development framework. We interview Roman Pichler, a Certified ScrumMaster Trainer and independent consultant. Roman explains the principles behind Scrum, its roles and its key practices. He also answers FAQs. This episode continues our track on software development processes discussing an additional Agile method. Roman is currently writing a book on Scrum in German that provides more in-depth information of the topics discussed in the podcast. The book will be available in autumn 2007 published by d.punkt (Heidelberg, Germany).
This episode is a discussion with Jonathan Aldrich (Assistant Professor at CMU) about static analysis. The discussion covered theory as well as practice and tools. We started with an explanation of what static analysis actually is, which kinds of errors it can find and how it is different from testing and reviews. The core challenge of such an analysis tool is to understand the semantics of the program and reduce its possible state space to make it analysable - in effect reconstructing the programmer's intent from the code. The user can "help" the tool with this challenge by using suitable annotations; also, languages could do a better job of being analysable. The conceptual discussion was concluded by looking at the principles of static analysis (termination, soundness. precision) and how this approach relates to model analysis.
The second more practical part started out with a discussion of how Microsoft successfully uses static analysis in their Windows development. We then discussed some of the tools available; these include Findbugs, Coverity, Codesonar, Clockwork, Fortify, Polyspace and Codesurfer. To conclude the discussion of tools, we discussed the commonalities and differences with architecture visualization tools as well as metrics and heuristics.
Part three of the discussion briefly looked at how to introduce static analysis tools into an organization's development process and tool chain. We concluded the discussion by looking at situations where static analysis does not work, as well as at the FLUID research project at CMU.
Variability is one of the key concerns in software product line engineering. The episode introduces the concepts of structural and non-structural (or configurative) variability. It also discusses how to find and model variability, and especially how to implement variability in the solution artifacts. Michael and Markus discuss a series of variability mechanisms that can be used with today's programming languages and technologies.
This episode is about compile-time metaprogramming, and specifically, about implementing DSLs via compile-time metaprogramming. Our guest, Laurence Tratt, illustrates the idea with his (research) programming language called Converge.
We started by talking about the importance of a custom syntax for DSL and took a brief look at the definition of DSLs by a chap called Paul Hudak. We then briefly covered the disctinction between internal and external DSLs.
More to the point of this episode, we discussed the concept of compile-time metaprogramming, and the language features necessary to achieve it: in converge, these concepts are called splice, quasi-quote and insertion. We then looked at how the Converge compiler works, and at the additional features that are required to implement DSLs based on the metaprogramming features mentioned above. Using an example, we then walked through how to implement a simple DSL.
Looking at some of the more technical details, we discussed the difference between the parse tree and the abstract syntax tree and at different kinds of parsers - specifically, the Earley parser used by Converge. In multi-stage languages (i.e. languages that execute programs and meta programs) error reporting is important, but non trivial. We discussed how this is done in Converge. We finally looked at how to integrate Converge's expression language into your DSL and how to package DSL definition for later use.
The last segment look at the process of implementing a DSL in converge and about some of the history and practical experience with Converge. Lessons learned from building Converge wrap up the episode.
In this episode we discuss sensor networks with our guest Steffen Schaefer, who is the Technical Thought Leader for Sensors & Actuator Solutions at IBM. The discussion resolves around the TREC device, which can be mounted on containers to track them on their journey over seas, railway tracks and roads. The TREC is a small embedded device developed by Steffen's employer, IBM, that has various sensors and communications channels.
In the episode we first talked about container transport in general, and then looked at how the TREC device works - specifically, it's hardware, software and power management. We then looked at the necessary backend infrastructure. The main part of the discussion covered the communication between the device and the backend, using technologies such as Zigby, GSM and satellite communications. We also looked at the middleware infrastructures used, such as the MQtt messaging tool.
We closed the episode with a little discussion of the "Internet of Things" and some discussion about embedded software devleopment in general. Note that SE Radio will feature more embedded topics in the future - an introduction to embedded development will be put online soon.
In the first episode on Refactoring we talked about the basic ideas behind refactoring and some base principles why refactoring is a key part of software engineering. Now we move on to more complicated refactorings and discuss three major situations, their problems and possible solutions: advanced refactorings in large projects that can hardly be finished in a few minutes or hours and refactoring in larger teams. Also covered are the refactoring of published APIs and how merciless refactoring could be aligned with backward compatibility of published APIs, and refactorings that affect more than just code like for example database schemas.
This episode is an interview with Frank Buschmann, one of the pioneers of the pattern movement in Europe. Michael and Frank discuss how it all began: the first conferences on patterns and the first publications by the Gang-of-Four and the POSA 1 team. Frank then elaborates on the new volumes in the Pattern-Oriented Software Architecture book series - POSA 4 and POSA 5 - and gives some examples from the books. The episode concludes with a general discussion on software design and architecture, and best practices on software development.
Michael Kircher and Markus Voelter introduce the topic of software product line engineering. They motivate when and why product lines are important to consider and what makes them so special. Further, they introduce some key terminology, such as platform, core asset, feature model, commonality, and variability.
In this episode, we're talking to Obie Fernandez about agile DSL development in Ruby. We started our discussion by defining what a DSL is, the difference between internal and external DSLs as well as the importance of the flexibly syntax of the host language in order to make DSLs worthwhile. We then looked at a couple of real world examples for DSLs, specifically, at Business Natural Languages. We then progressed to the main part of the discussions, which centered around the features of Ruby that are important for building DSLs. These include the flexible handling of parentheses, symbols, blocks as well as literal arrays and hashes. We then discussed Ruby's meta programming feautures and how they are important for building DSLs: instantiation, method_missing callback, class macros, top level functions and sandboxing. Features like eval, class_eval, instance_eval and define_method are also important for DSLs in Ruby, as well as using alias_method for simple AOP.
In this episode, Arno and Michael take a look at Design by Contract, a programming technique formalized by Bertrand Meyer. The idea is that an interface is more than method signatures - it is also about specifying the expected behavior that implementations must provide. While some languages include direct support for this style of programming, it is a useful mindset when desiging interfaces even without such language features.
In this Episode we talk about dynamic languages for statically-typed minds, or in other words: which are the interesting features people should learn when they go from a langauge such as Java or C# to a language like Python or Ruby. We used Ruby as the concrete example language.
We started the discussion about important features with the concept of dynamically changing an object's type and the idea of message passing. We then looked at the concepts of blocks and closures. Next in line is a discussion about functions that create functions as well as currying. This lead into a quick discussion about continuations. Open classes, aliasing and the relationship to AOP was next on our agenda.
We then looked considered a somewhat more engineering-oriented view and looked at the importance of testing and what are the best steps of getting from static programming to dynamic programming. Finally, we discussed a bit about the current (as of October 2006) state of dynamic languages on mainstream platforms.
In this Episode we discuss software architecture evaluation with Dragos Manolescu, an architect at Microsoft's patterns & practices group.
We start off the discussion by trying to define what software architecture evaluation is and when and you want to evaluate an architecture in the system's lifecycle. We then make sure evaluators set the expectations for the evaluation process right - it is important to understand that architecture evaluation is typically not primarily a review of the technology decisions made for the architecture.
We then discuss the kinds of notations that are useful for describing architectures, and which of these are especially helpful for the evaluator. Next we look at the core of the architecture evaluation task, namely, the integration of the various stakeholders and their views. We also discuss real reviews from reviews that are staged "for show" only.
Next in the discussion is a brief look at the tools you can use for architecture evaluation, as well as a closer look at the various methods for achitecture evalualtion proposed by the Software Engineering Institute (SEI). We conclude the discussion by outlining how architecture evaluation fits into an agile development process.
... and finally, we briefly plug the PLOPD5 book, on which Dragos, Markus and James Noble have been working recently :-)
In this Episode we are happy to talk to Grady Booch. We started off by discussing his Architecture Handbook, how it came into being, the progress, and how it will look like once it's finished. In this context we also looked at the issue of how to distinguish architecture from design. We then asked him about how "professional" software architecture is these days, as well as about the ubiquity of software product lines in industry. The next couple of minutes looked at the question of whether software development is an engineering discipline, craftsmanship or an art form, and we discussed the key qualifications of software developers. Grady then elaborated on the problems of developing in large teams as well as the potential limits of complexity we can tackle with software.
We then got back to a more technical discussion, where we looked at model-driven development, DSLs, etc. and the role of the UML in that context. Next was a discussion about scripting languages, and the current trend towards new languages. We then looked at component marketplaces and other forms of reuse, as well as the importance of OO these days and the relevance of AO. We concluded with a (small) outlook to the future.
Changeable software has been a goal of several technique in software engineering. Probably the most important is Refactoring, changing the code without changing the behaviour (or at least without breaking the tests). In this episode Eberhard talks with Martin Lippert about this technique. The episode covers a history of refactoring, a definition of code smells and how to actually do refactorings in your everyday work. Also some advanced topics - like the ROI of Refactoring or Refactoring in dynamic languages - are covered.
This Episode is a round table discussion about Ultra-Large Scale Systems. In 2006, a number of authors (among them our guests Linda Northrop, Doug Schmidt, Kevin Sullivan, and Gregor Kiczales) have produced a report that addressed the following question:
Given the issues with today's software engineering, how can we build the systems of the future that are likely to have billions of lines of code?
In this episode, our guests discuss many of the issues that arise from this kind of system and provide an overview of the research areas that should be investigated in order to tackle the challenge. If you want to get more detailed information, you can read the ULS Report (PDF).
This is another episode on concurrency. We talk to two experts in the field, Brian Goetz and David Holmes about aspects of concurrency we hadn't really covered before.
We start out by discussing liveness and safety and then continue to talk about synchronizers (latches, barriers, semaphores) as well as the importance of agreeing on protocols when developing concurrent applications. We then talked about thread confinement as a way of building thread-safe programs, as well as using functional programming and immutable data. The next set of topics covers various ways of how compilers can optimize the performance wrt. to concurrency, talking about techniques such as escape analysis as well as lock elision and coarsening. We then covered how to test concurrent programs and the consequences of the Java memory model on concurrency. We then went on to look at some more advanced topics, namely, lock-free programming and atomic variables. We also briefly discussed the idea of transactional memory.
Finally, we looked at how better language support - specifically, a more declarative style of concurrent programming as e.g. in the Fortress language - can aid in improving the quality of concurrent programs.
This is the second part of our two part discussion of the eXtreme Programming development methodology. While the first part introduced the values, principles and basic practices, this time Arno and Alex speak about the practices that set the context for an XP project and how to get started, and they discuss some FAQs they often get when introducing XP.
In this episode, Gregor Hohpe gives us a great introduction to enterprise messaging based on his EAI Patterns book. Before we started discusssing the patterns in his book, we characterized messaging and talked about the various interaction styles. We also contrasted the messaging architectural style with an RPC based approach. We then took a look at the relationship to SOA, the role of contracts and the orchestration-vs-choreography discussion. We briefly discussed the nature of pattern languages before we then went through the different section in the book. There are six main sections: channel, message, routing, transfomation, endpoint as well as management and monitoring. We discussed the core patterns for each of these sections. This should give listeners a good high-level view of message-based systems. We concluded the discussion by looking at the critical importance of systems management and monitoring.
This is the fourth and final episode on the fundamentals of Software Architecture. We talk mainly about architectural styles and patterns, as introduced in the POSA 1 Book. We also discuss a little bit the process of actually using those patterns for architecting systems.
This episode is an interview with Werner Vogels, the CTO of amazon.com. We first talked about what scalability is, and which aspects there are to scalability. We then took a brief look at the technologies used at amazon, specifically, the middleware systems and the issue of vendor lock-in. Web services, and the role of SOA was the next topic. Then we covered what a service actually is add Werner explained the term "pizza teams". Testing and Deployment was the next topic followed by a look at architectural characteristics of scalable systems, the value of simplicity and the CAP theorem. We concluded the discussion with a brief look at the future of distributed systems
This episode is an interview with Steve Vinoski. Steve works as the Chief Engineer for IONA. He's what you'd call a middleware guru, he was for example deeply involved with CORBA. So, this interview centers mainly around middleware. We begin by talking about his own history wrt. middleare and ORBs and how ORBs evolved over time. We then talked about whether coarse-grained, stateless components might be a better abstraction for distributed systems than "objects". We then covered the future of CORBA, it's use in ethe embedded space as well as the practical relevance of the POSA patterns when building ORBs. Then we switched topics and addressed the role of web services as a "middleware middleware" and the maturity of WS-* specifications. We then looked at what Steve is working on these days, which is e.g. the Advanced Message Queueing Protocol (AMQP) as well as dynamic languages. We concluded the interwiew with his view on SOA.
Designers, programmers, engineers, we must all return to programming!
Very few programmers tend to see their (sometimes rather general) difficulties as the core of the subject and as a result there is a widely held consensus as to what programming is really about. If these notes prove to be a source of recognition or to give you the appreciation that we have simply written down what you already know about the programmer's trade, some of our goals will have been reached.
This is the first of two episodes where Arno and Alex discuss eXtreme Programming in se-radio's development process track. eXtreme Programming (XP) revolutionized the way of thinking about software development methodologies and helped to make the agile movement popular. In this episode they discuss the very basics of XP, its value system, principles and the basic practices used in an XP project. The second episode will continue the introduction adding the missing practices and how to introduce XP into projects.
This episode is an interview with Guy L. Steele Jr.. Guy is a Sun Fellow and heads the Programming Language Research Group within Sun, and a generally well known "programming language guy" (see here for details). We briefly talk about Lisp and the resurgence of dynamic languages before we delve into the main topic, the Fortress programming language he is working on. Fortress is a language intended to replace Fortran as a scientific computing language. We talk about how mathematical notations, syntax extensio and built-in support for parallelism are crucial properties of such a language. We then briefly talk about potentials for compiler optimization before taking a closer look at the type system (static typing, type inference), traits and contract specification as well as first-class support for hierarchical components. We conclude the discussion with a look at automatic partitioning and distribuion of concurrent algorithms and a brief look at the future roadmap for the Fortress language.
In this episode Markus and our Guest Andy Longshaw talk about enterprise architecture. More specifically, we talk about some of the patterns in Andy Longshaw's and Paul Dyson's book Architecting Enterprise Solutions: Patterns for High-Capability Internet-based Systems. These includes things like replication, load balancing, monitoring and application management.
This is the second snippet of the SOA 2 double-episode. Eberhard and Markus continue the discussion with the issue of service reuse and a couple of development process issues. We also look at the duality between infrastructure development and application development in the context of an SOA. We then discuss the great spaghetti misunderstanding :-). We conclude this episode with a look at how to integrate BPM into the conceptual SOA framework we've built up to now, and we'll also briefly skim over a number of technologies related to SOA.
Note that this episode, as well as the last one, is based on a set of slides; these can be downloaded from here. This episode covers slides 39 through 74.
In this, as well as in the next episode Eberhard and Markus continue their discussion about SOA (the episode got too long, so we had to split it into two ... SOA 2a and SOA 2b). In this episode, we talk about the various perspectives on SOA (CBD, EAI, BPM), about fundamental requirements towards an SOA, and we discuss the role of models in defining sustainable architectures. We also discuss how a programming model based on the described approach typically looks like. We then discuss a number of issues any large-scale SOA faces (and for which the SOA paradigm does not really provide an out-of-the-box solution: In this episode we discuss data type ownership and (weak) typing of data types.
In this episode, our guest Andreas Rueping and Markus talk about documenting software. While this is a topic that many people don't like or consider fun, it is nonetheless very important. Based on his book, Agile Documentation, we talk about various aspects documenting software such as what to document, when to document, which media to use as well as specifically a number of layouting tips for nice documents.
In this third Episode on software architecture, Michael and Markus talk about the basic tools that an architect uses when architecting systems. These tools include things like separation, abstraction, compression and sharing. We also relate these tools to the quality attributes we introduced in previous archtecture episodes.
The third part of our concurrency series by Michael and Alexander discusses how to build highly scalable servers. The discussion focusses especially on event-driven servers. As possible solution patterns a reactor-based design is suggested along-side several patterns for multi-threading issues: Reader/Writers Locks, Thread Pools, and Leader/Followers.
In recent episodes we have discusses statically and dynamically typed languages and domain specific languages - topics that are much talked about in the community at the moment. In this episode we look at the foundation of programming languages : types. We explain what a type actually is, how type systems work and what polymorphism works.
SOA (Service Oriented Architecture) appears to be just another hype - after all we have been building distributed systems for quite a while now. But the real value of SOA is non-technical. In this episode Eberhard and Markus discuss the advantages and disadvantages, what SOA actually is and how it compares to other approaches that have been tried out before.
In this Episode, Arno, Bernd and Markus interview Jutta Eckstein. Jutta is a pioneer and expert on using Agile software development, specifically in larger teams. In the interview we talk about the agile manifesto, the role of personal relationships and trust in software projects, differences between agility in the small and in the large, as well as offshoring.
In this Episode, Michael and Markus continue the discussion about the fundamentals of software architecture (we're doing it without Alex, because it is really hard to find a suitable time for all of us on the phone :-)). We talk about the various quality attributes (such as performance, scalability, maintainability and many more) and how they relate to each other.
In this episode Arno and Alex talk about the basics of software development processes. They discuss why and when software development processes are needed and also why some developers don't like them. They discuss the theories behind different processes and talk about defined vs empiric processes in general. This episode is the first in a row that will later on describe specific processes like eXtreme programming or the unified process.
This is the first of a series of Episodes on Software Architecture. Alex, Michael and Markus talk about rather fundamental topics in this episode, we'll go into much more detail in subsequent episodes in that series. Topics in this episode include: * What is architecture, how is it different from design * what different kinds of architecture are there in addition to software architecture * the role of the architect, do we have one or more? * architecture in agile software development * tasks of the architect * architect vs. the technical project lead * architecture and project politics * architecture requirements, estimating, team assembling
There aren't too many good references for this general architecture discussion. You might want to take a look at Software Architecture in Practice by Len Bass, or, if you speak German, at the book Software-Architektur by Vogel, Arnold, Chugtai, Ihler, Mehlig, Neumann, Voelter and Zdun.
This is an episode with some more of your feedback. Specifically, the episode also contains a 5 minute section from Geert Bevin where he explains how Continuations are used an implemented in the Rife Framework. This is in response to a discussion about continuations and Rife in Episode 15, Future of Enterprise Java. We also have some feedback from Bill Pugh about flaws in our description about the problems of double-checked locking in Java.
In this Episode, Arno and Michael take a closer look at Exceptions and Error conditions, how to categorize them and how to deal with them. We look at the different levels of guarantee that a piece of code can provide with regard to exceptional condition and finish with a discussion of a number of best practices and their respective trade-offs.
In this Episode, we talk to Michael Stal, a Senior Principal Engineer at Siemens Corporate Technology, POSA 1 and 2 Co-Author and Editor of the german JavaSpetrum magazine. Since Michael's core focus is middlware, much of our discussion centered around that topic. Webservices and SOA, of course, have also been covered. Other topics include Java vs. .NET as well as Patterns.
In this second part of our concurrency series Michael and Alexander talk about basic patterns for concurrent programming, such as Active and Monitor Object, Scoped Locking and Futures. Further, they discuss some architectural considerations regarding the number of threads and resource usage in general. For more information, see the references for part one as well as the following links
In this episode Michael and our guest Prashant Jain talk about patterns for resource management. Efficient management of resources is critical in the execution of any kind of software. Ranging from embedded software in a mobile device to software in a large enterprise server, it is important that the resources, such as memory, threads, file handles, or network connections, are managed efficiently to allow the systems to function properly and effectively. Michael and Prashant discuss various patterns, such as Lazy Acquisition, Caching, Leasing and Evictor and explain when, why, and how to apply them for effective resource management.
This is a short episode that outlines the upcoming episodes and interviews, as well as reports on some listener feedback.
This episode provides a hands-on guided tour through a simple model-driven software project. It is based on an actual code sample (see link below) and takes a look at the typical steps of real-life code generation: prototypical implementation, defining the metamodel, reading a model into a metamodel instance, writing templates and validating the model. The example for the episode uses openArchitectureWare as a generator environment, but the overall approach is tool independent. This episode is the first in a new category "code/technology" that discusses technical concepts based on actual code. Please give feedback whether you find this format useful or not.
A very important area for Java are Enterprise Systems. With the advent of new technologies like Ruby on Rails, Java EE 5 or EJB 3 the landscape for Enterprise Systems appears to be changing a lot at the moment. In this episode Markus talks with Eberhard about what Enterprise Java actually is, why and where it is used. Based on that they discuss what the future might look like and how to make Enterprise Java shine in the future.
In this Episode we talk to Ted Neward. Since Ted is active in the .NET and Java universes, we started out by discussing some of the differences between the two platforms. The main discussion, however, focussed on new features in the C# 3.0 language. These include LINQ (language-integrated query). A very interesting discussion about extension methods, lamda expression, typing (dynamic, duck, compiler) and other language "tricks" follows. We also visited the topic of language development on the .NET and Java platforms in general, also looking at topics such as concurrency and the Scala language.
Ruby has been getting more and more attention by the developer community over the last couple of years. Nevertheless Ruby as language and as a plattform is not too widespread. Most developers don't know people who have actually done commercial Ruby projects. Therefore it is sometimes hard to judge if Ruby is just a hype topic or if Ruby can be used for serious projects today. In this episode Alexander speaks with Thomas Quas about a commercial Ruby project Thomas finished a while ago. Thomas shares his insights and practical experiences with Ruby doing a project under strong time pressure. As Thomas has many years experience doing Java projects we also do some high level comparisons between both platforms.
This is the first part of a series of Concurrency episodes. In this part Alex and Michael motivate and introduce the topic. We explain fundamental terms, such as thread, process, or mutex and dicuss typical challenges, such as deadlocks and race conditions.
In this Episode we have the pleasure of talking with Gregor Kiczales. Gregor is one of the fathers of aspect-oriented programming (AOP). Today he is a professor of computer science at the University of British Columbia. Back in his days at Xerox Parc, he and a number of other people worked on the early forms of AOP as well as on some of its forerunners, such as meta object protocols. In this interview, we talk about a number of interesting topics, such as the history of AOP, the relationship of AO to interceptors, the industry acceptance of AOP, early aspects (i.e. using AO in development phased before implementation) as well as adoption strategies for AOP.
This is the second part of the remoting infrastructures discussion started in Episode 9. We take a look at how remoting infrastructures such as CORBA, .NET Remoting or Web Services work internally. This includes the low level details of the transport layer, marshalling, client proxies as well as interceptors and asynchronous communication. At the end, Michael will explain how all this relates to CORBA and Markus will map the concepts to .NET remoting. We don't have additional links in these show notes since all the relevant links had been posted for Episode 9 already.
This Episode as well as the next one take a look at remoting infrastructures such as CORBA, .NET Remoting or Webservices. In this first part we will take a look at why remote communication is necessary in the first place, what remoting middleware can do for you as well as which other middleware technologies exist in addition to OO-RPC systems, such as messaging middleware. Finally, we conclude with a brief overview of what the broker pattern can do for us in the context of remoting middleware.
Eric Evans is the author of the well known Domain-Driven Design book. In his day job he works as a consultant and coach for his own company, Domain Language. In this interview, Eric talks about the essential building blocks of domain-driven design as well as about a set of best practices on how to address complex projects. In a third part, he elaborates on the relationship of domain-driven design and MDSD/MDA.
This week, Arno and Markus take a look at error handling at the architectural level. They discuss the different kinds of errors, the groups of people who need to know about them and proven high-level approaches. Later episodes will investigate more technical aspects of error handling, such as idioms for using exceptions or a discussion of checked vs. unchecked exceptions.
After discussing some of the more technical aspects of MDSD in the last episode, we take a look at other important topics in this one. This includes some tips on how to introduce MDSD into projects and how the development process has to be adapted for this to work, as well as a look at the return on investment for MDSD. The relationship of MDSD and Agile software development is also discussed. Finally, we take a look at offshoring in the context of MDSD.
In this Episode, Eberhard and Markus provide an introduction to Model-Driven Software Development. Since the discussion turned out to be too long, we separated things into two episodes, thus Episode 6 will be the second part of this discussion. In this first part we disucsss core concepts of MDSD, the relationship to MDA, and hint at a couple of tools.
In this Episode, Alexander and Markus talk about scripting languages. Topics include the definition of what a scripting language is, typical usage scenarios, performance issues, programming styles and IDE support. In later Episodes we will talk about more specific topics, such as dynamic typing, reflection, functional programming as well as specific languages such as Ruby.
In this episode we talk with Doug Schmidt. Doug is a professor of computer science at Vanderbilt University and a well-respected authority in the fields of middleware, patterns and model-driven development. In this interview we talk about these topics in the context of distributed, realtime embedded (DRE) systems.
Eberhard and Markus discuss the important topic of associations and dependencies in this show. While OO languages provide direct support for subtyping, most don't provide a first-class construct for other relationships between objects. The discussion elaborates on the problem and looks at various remedies, most importantly, dependency injection.
In this episode Michael and Markus talk about patterns. Starting with some of their "most used" patterns, they go into some detail about the history of patterns. They then discuss the various pattern forms as well as some misconceptions about patterns. Other topics include the domains that are covered by patterns as well as pattern languages.
This is the first episode (actually, episode zero) of software engineering radio. The episode does not contain real content, rather, Markus explains what the podcast is all about.