Software Engineering Radio - The Podcast for Professional Software Developers

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.

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 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.

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.

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.

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.

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.

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.