AI DevOps Podcast

Philippe Kruchten has over 35 years of software development experience. Now retired, his experience focused mostly on large technical systems such as telecommunication, defense, aerospace, and software tools. He also spent 16 years as an educator and researcher in a major Canadian engineering school.

Topics of Discussion:

[2:18] Philippe gives some of the highlights of his long career, starting first as a mechanical engineer and then traveling the world as a software engineer.

[4:26] How Philippe has seen software architecture change over time and the struggles architects still face.

[6:03] Software architects are among some of the most in-demand professions.

[7:10] What makes software architecture different from other coding?

[9:05] Discussing Building and Evaluating a Theory of Architectural Technical Debt in Software-intensive Systems and the three reasons for architectural debt.

[11:31] A major reason for architectural debt in software is not understanding the architecture due to improper documentation. So what is the proper way to document?

[17:23] Regardless of the format, each key audience needs a view specific to them, and how to document the decisions.

[21:19] Is there a best approach for harvesting or understanding the actual architecture?

[23:46] With a big architectural change, using systematic impact analysis and prototyping are ways to carefully approach the shift.

[26:48] Some unsolved issues that remain within the industry and what a good software developer looks like, then vs. now.

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

"Building and Evaluating a Theory of Architectural Technical Debt in Software-intensive Systems"

"A General Model of Software Architecture Design Derived From Five Industrial Approaches"

Software Systems Architecture

4+1 Architectural View Model

IEEE 1471

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• "I think we've made some progress. We understand the role of architecture a little bit better."— Philippe [4:59]
• "We're still hindered by the fact that architecture is hard to grasp; it's hidden out there in the software, it's not visible at the surface." — Philippe [5:05]
• "We've come a long way in making architecture a first-class citizen in a few organizations." — Philippe [5:42]
• "Architecture, for me, is the set of design decisions you have to make usually early in the life of a system that will actually condition a lot of things in terms of structure and behavior of the system." — Philippe [7:25]
• "It's not programming; although the architecture will end up being code somewhere. The act of developing a software architecture is more about decision-making and understanding the intricate network of decisions and how they relate to each other." — Philippe [7:58]
• "Not every software developer needs to be a software architect, but they need to understand what is the software architecture of the system I'm working on." — Philippe [8:45]
• "You end up being in a position of architectural technical debt not because you made the wrong decision 10 years ago, but because those decisions are not the right one in the current circumstances. Then there is architectural debt because what you did 10 years ago was just plain stupid!" — Philippe [10:38]
• "Diagrams are useful for architects to communicate to another audience." — Philippe [18:59]

Philippe: Website | Twitter | LinkedIn

Philippe Kruchten has over 35 years of software development experience. Now retired, his experience focused mostly on large technical systems such as telecommunication, defense, aerospace, and software tools. He also spent 16 years as an educator and researcher in a major Canadian engineering school.

Topics of Discussion:

[2:18] Philippe gives some of the highlights of his long career, starting first as a mechanical engineer and then traveling the world as a software engineer.

[4:26] How Philippe has seen software architecture change over time and the struggles architects still face.

[6:03] Software architects are among some of the most in-demand professions.

[7:10] What makes software architecture different from other coding?

[9:05] Discussing Building and Evaluating a Theory of Architectural Technical Debt in Software-intensive Systems and the three reasons for architectural debt.

[11:31] A major reason for architectural debt in software is not understanding the architecture due to improper documentation. So what is the proper way to document?

[17:23] Regardless of the format, each key audience needs a view specific to them, and how to document the decisions.

[21:19] Is there a best approach for harvesting or understanding the actual architecture?

[23:46] With a big architectural change, using systematic impact analysis and prototyping are ways to carefully approach the shift.

[26:48] Some unsolved issues that remain within the industry and what a good software developer looks like, then vs. now.

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

"Building and Evaluating a Theory of Architectural Technical Debt in Software-intensive Systems"

"A General Model of Software Architecture Design Derived From Five Industrial Approaches"

Software Systems Architecture

4+1 Architectural View Model

IEEE 1471

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• "I think we've made some progress. We understand the role of architecture a little bit better."— Philippe [4:59]
• "We're still hindered by the fact that architecture is hard to grasp; it's hidden out there in the software, it's not visible at the surface." — Philippe [5:05]
• "We've come a long way in making architecture a first-class citizen in a few organizations." — Philippe [5:42]
• "Architecture, for me, is the set of design decisions you have to make usually early in the life of a system that will actually condition a lot of things in terms of structure and behavior of the system." — Philippe [7:25]
• "It's not programming; although the architecture will end up being code somewhere. The act of developing a software architecture is more about decision-making and understanding the intricate network of decisions and how they relate to each other." — Philippe [7:58]
• "Not every software developer needs to be a software architect, but they need to understand what is the software architecture of the system I'm working on." — Philippe [8:45]
• "You end up being in a position of architectural technical debt not because you made the wrong decision 10 years ago, but because those decisions are not the right one in the current circumstances. Then there is architectural debt because what you did 10 years ago was just plain stupid!" — Philippe [10:38]
• "Diagrams are useful for architects to communicate to another audience." — Philippe [18:59]

Philippe: Website | Twitter | LinkedIn

Adam Tornhill is a programmer who combines degrees in engineering and psychology. He's the founder of CodeScene where he designs tools for software analysis. He's also the author of Software Design X-Rays, the best-selling book Your Code as a Crime Scene, Lisp for the Web, and Patterns in C. Adam's other interests include modern history, music, and martial arts.

Topics of Discussion:

[2:10] Adam talks about how he got his start in code metrics 25 years ago and why he's discovered that it's so hard to write good code.

[3:48] What are the other book ideas Adam has to add to his existing four?

[4:53] What motivated Adam to write Your Code as a Crime Scene and what is the premise?

[9:02] When assembling the data, relevance, as well as quality, are both important.

[10:29] Cyclomatic complexity is an old metric, as are many others, that is not quite tangible or relevant.

[11:58] Why Adam prefers to look at code health vs. code quality.

[13:26] The process is slightly different when looking at code health for existing code vs. writing new code.

[15:23] How does CodeScene aid in the pull request process?

[18:31] CodeScene integrates with your version control repository and work tracking tools to find where bugs were introduced.

[22:22] Is CodeScene meant to be a standalone tool or can it work alongside many of the other tools on the market?

[24:57] Adam's rules of thumb for those getting started in software systems.

[28:12] Why Adam's preferred method of delivering software architecture has changed over the years.

[30:36] What are the steps for implementing CodeScene into a codebase?

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

CodeScene — Free Community Edition

Adam Tornhill on Github

Software Design X-Rays

Your Code as a Crime Scene

Lisp for the Web

Patterns in C

"Code Red: The Business Impact of Code Quality"

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• "Software development and software code, in particular, are very abstract. There's no way I can really take a software system and pull it out and turn it around and inspect it for flaws." — Adam [6:34]
• "What I'm most interested in is trends; so are we moving in the right direction or the wrong direction?" — Adam [15:14]
• "My experience, from working with all of these companies, is that pull requests and code reviews, in general, are extremely valuable… but they also tend to become a bottleneck in practice." — Adam [16:10]
• "A surprise is simply one of the most expensive things you can put into a software architecture." — Adam [30:15]
• "While these mechanics are simple, information is only good when acted upon." — Adam [31:20]

Adam: Website | Twitter | LinkedIn

Adam Tornhill is a programmer who combines degrees in engineering and psychology. He's the founder of CodeScene where he designs tools for software analysis. He's also the author of Software Design X-Rays, the best-selling book Your Code as a Crime Scene, Lisp for the Web, and Patterns in C. Adam's other interests include modern history, music, and martial arts.

Topics of Discussion:

[2:10] Adam talks about how he got his start in code metrics 25 years ago and why he's discovered that it's so hard to write good code.

[3:48] What are the other book ideas Adam has to add to his existing four?

[4:53] What motivated Adam to write Your Code as a Crime Scene and what is the premise?

[9:02] When assembling the data, relevance, as well as quality, are both important.

[10:29] Cyclomatic complexity is an old metric, as are many others, that is not quite tangible or relevant.

[11:58] Why Adam prefers to look at code health vs. code quality.

[13:26] The process is slightly different when looking at code health for existing code vs. writing new code.

[15:23] How does CodeScene aid in the pull request process?

[18:31] CodeScene integrates with your version control repository and work tracking tools to find where bugs were introduced.

[22:22] Is CodeScene meant to be a standalone tool or can it work alongside many of the other tools on the market?

[24:57] Adam's rules of thumb for those getting started in software systems.

[28:12] Why Adam's preferred method of delivering software architecture has changed over the years.

[30:36] What are the steps for implementing CodeScene into a codebase?

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

CodeScene — Free Community Edition

Adam Tornhill on Github

Software Design X-Rays

Your Code as a Crime Scene

Lisp for the Web

Patterns in C

"Code Red: The Business Impact of Code Quality"

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• "Software development and software code, in particular, are very abstract. There's no way I can really take a software system and pull it out and turn it around and inspect it for flaws." — Adam [6:34]
• "What I'm most interested in is trends; so are we moving in the right direction or the wrong direction?" — Adam [15:14]
• "My experience, from working with all of these companies, is that pull requests and code reviews, in general, are extremely valuable… but they also tend to become a bottleneck in practice." — Adam [16:10]
• "A surprise is simply one of the most expensive things you can put into a software architecture." — Adam [30:15]
• "While these mechanics are simple, information is only good when acted upon." — Adam [31:20]

Adam: Website | Twitter | LinkedIn

Rod Paddock is the CTO of Dash Point Software, Inc. and the Editor in Chief of CODE Magazine! In 2001, Rod founded Dash Point Software, Inc. to develop high-quality custom software solutions. With over 30 years of experience, some of his current and past clients include Six Flags, First Premier Bank, Microsoft, Calamos Investments, The U.S. Coast Guard, and U.S. Navy. Along with developing software, Rod is a well-known author and conference speaker. Since 1995, he has given talks, training sessions, and keynotes in the U.S., Canada, and Europe. Rod was a guest way back in Episode 111.

Topics of Discussion:

[4:19] What was the state of the industry like when Rod started teaching?

[6:12] Rod talks about the event that led him to have dinner with Top Gun pilots, and a moment of celebrity fame in an elevator.

[10:11] Rod talks about Code Magazine and how it has developed over the years.

[11:01] Rod speaks about the state of remote work, and how it's giving people time back for more creativity.

[15:29] What are the important factors and Rod's process when planning for applications to live a long time?

[21:26] Rewriting applications is a lot of times harder than building from the ground up.

[23:22] There are a lot of ways to build, and that includes both planning and a little bit of luck.

[24:02] When do you know if it's time to rebuild a current application?

[26:08] You have to know where your problems and pain are, and every system has pain.

[29:34] Why is laziness a good thing for a software developer?

[36:50] People are very resilient and very resourceful, and they will figure out how to make your software do stuff you would never expect.

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

Dash Point Software, Inc.

A Philosophy of Software Design, by John Ousterhout

Software Engineering at Google: Lessons Learned from Programming Over Time, by Titus Winters, Tom Manshreck, and Hyrum Wright

Code Magazine — Use Code TADP For Free Subscription

The Mythical Man-Month: Essays on Software Engineering, by Frederick P. Brooks, Jr.

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• "I consider myself extremely fortunate in my whole career." — Rod
• "Lots of people are getting essentially 20 hours a week back, and just not from commuting, which is pretty cool." — Rod
• "Rewriting applications is a lot of times harder than building from the ground up." — Rod
• "You have to pay attention to the way you're building your applications, and that helps the longevity as well, and know the pieces that you can rip out and rebuild." — Rod
• "People are very resilient and very resourceful, and they will figure out how to make your software do stuff you never thought it was going to do." — Rod

Rod: Website | Twitter

Rod Paddock is the CTO of Dash Point Software, Inc. and the Editor in Chief of CODE Magazine! In 2001, Rod founded Dash Point Software, Inc. to develop high-quality custom software solutions. With over 30 years of experience, some of his current and past clients include Six Flags, First Premier Bank, Microsoft, Calamos Investments, The U.S. Coast Guard, and U.S. Navy. Along with developing software, Rod is a well-known author and conference speaker. Since 1995, he has given talks, training sessions, and keynotes in the U.S., Canada, and Europe. Rod was a guest way back in Episode 111.

Topics of Discussion:

[4:19] What was the state of the industry like when Rod started teaching?

[6:12] Rod talks about the event that led him to have dinner with Top Gun pilots, and a moment of celebrity fame in an elevator.

[10:11] Rod talks about Code Magazine and how it has developed over the years.

[11:01] Rod speaks about the state of remote work, and how it's giving people time back for more creativity.

[15:29] What are the important factors and Rod's process when planning for applications to live a long time?

[21:26] Rewriting applications is a lot of times harder than building from the ground up.

[23:22] There are a lot of ways to build, and that includes both planning and a little bit of luck.

[24:02] When do you know if it's time to rebuild a current application?

[26:08] You have to know where your problems and pain are, and every system has pain.

[29:34] Why is laziness a good thing for a software developer?

[36:50] People are very resilient and very resourceful, and they will figure out how to make your software do stuff you would never expect.

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

Dash Point Software, Inc.

A Philosophy of Software Design, by John Ousterhout

Software Engineering at Google: Lessons Learned from Programming Over Time, by Titus Winters, Tom Manshreck, and Hyrum Wright

Code Magazine — Use Code TADP For Free Subscription

The Mythical Man-Month: Essays on Software Engineering, by Frederick P. Brooks, Jr.

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• "I consider myself extremely fortunate in my whole career." — Rod
• "Lots of people are getting essentially 20 hours a week back, and just not from commuting, which is pretty cool." — Rod
• "Rewriting applications is a lot of times harder than building from the ground up." — Rod
• "You have to pay attention to the way you're building your applications, and that helps the longevity as well, and know the pieces that you can rip out and rebuild." — Rod
• "People are very resilient and very resourceful, and they will figure out how to make your software do stuff you never thought it was going to do." — Rod 

Rod: Website | Twitter

Udi Dahan is one of the world's foremost experts on Service-Oriented Architecture and Domain-Driven Design and is also the creator of NServiceBus; the most popular service bus for .NET. Udi joined us back on Episode 32 to discuss Microservices.

Topics of Discussion:

[2:47] Udi talks about some of the changes, and similarities, in distributed computing in the last five years as well as generational differences to approach learning.

[11:27] Udi defines what a service mesh is and when it's applicable.

[14:46] Udi discusses his concerns regarding using a service mesh and common problems encountered.

[22:28] With most of the new generation of programmers using Web service-based programming, what does Udi think they need to hear?

[27:50] Why Udi thinks the larger companies and vendors need to take more responsibility and "do more good."

[32:48] Udi shares more on NServiceBus's offerings and functionality and why developers need to learn more.

[36:36] Are there any pieces of NServiceBus that will need more than just a .NET standard support?

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

Particular Software — NServiceBus

Episode 32 — Microservices

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• "Every generation of programmers needs to relearn kind of the same points over again." — Udi [3:51]
• "We're still essentially coming up with new generations of technologies that are addressing the same category of problems." — Udi [6:16]
• "The problem is not rooted in what do they need to hear so much as who do they need to hear it from."— Udi [23:51]
• "If you know a thing, if you can help, then you should." — Udi [29:47]
• "NServiceBus essentially takes all of the problems that you never want to have, and the challenges that most people don't know that they're going to have so they don't appreciate it until they have it, and essentially prevents them from happening."— Udi [34:29]
• "That ounce of prevention is equivalent to a pound of cure." — Udi [34:46]

Udi: Website | Twitter

Udi Dahan is one of the world's foremost experts on Service-Oriented Architecture and Domain-Driven Design and is also the creator of NServiceBus; the most popular service bus for .NET. Udi joined us back on Episode 32 to discuss Microservices.

Topics of Discussion:

[2:47] Udi talks about some of the changes, and similarities, in distributed computing in the last five years as well as generational differences to approach learning.

[11:27] Udi defines what a service mesh is and when it's applicable.

[14:46] Udi discusses his concerns regarding using a service mesh and common problems encountered.

[22:28] With most of the new generation of programmers using Web service-based programming, what does Udi think they need to hear?

[27:50] Why Udi thinks the larger companies and vendors need to take more responsibility and "do more good."

[32:48] Udi shares more on NServiceBus's offerings and functionality and why developers need to learn more.

[36:36] Are there any pieces of NServiceBus that will need more than just a .NET standard support?

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

Particular Software — NServiceBus

Episode 32 — Microservices

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• "Every generation of programmers needs to relearn kind of the same points over again." — Udi [3:51]
• "We're still essentially coming up with new generations of technologies that are addressing the same category of problems." — Udi [6:16]
• "The problem is not rooted in what do they need to hear so much as who do they need to hear it from."— Udi [23:51]
• "If you know a thing, if you can help, then you should." — Udi [29:47]
• "NServiceBus essentially takes all of the problems that you never want to have, and the challenges that most people don't know that they're going to have so they don't appreciate it until they have it, and essentially prevents them from happening."— Udi [34:29]
• "That ounce of prevention is equivalent to a pound of cure." — Udi [34:46]

Udi: Website | Twitter

Scott Wlaschin is an expert on F#, author of the popular F# site fsharpforfunandprofit.com, and a board member of the F# Software Foundation. Known for his non-academic approach to functional programming, Scott is a popular speaker and has given talks at NDC, F# Exchange, DDD Europe, and other conferences around the world.

Topics of Discussion:

[2:40] Scott talks about how he got into F#, and the nonlinear path his career has taken.

[4:00] Scott walks us through the history of F#.

[6:52] What types of applications should developers be looking at F# for?

[10:55] What was Scott's inspiration behind writing Domain Modeling Made Functional?

[12:20] Domain-driven design has nothing to do with a particular language. It's a process.

[17:32] As an industry, whether it be literature or art, there's so much to be gained by observing and reading prior works of others.

[19:55] How does functional thinking impact architecture?

[20:51] In functional programming, you want everything to be deterministic.

[28:34] What are some of the examples of transcription scripts?

[31:10] In functional programming, the main thing is the function and not the object.

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

F# Software Foundation

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• [3:00] "I started learning functional programming because I sort of felt like I really knew everything there was to know about databases and all that stuff. I thought I wanted something different." — Scott
• [8:52] "It really depends on how you like to program. If you like to program in a functional style, and you want to be on .NET, then F# is perfect." — Scott
• [12:00] "Don't focus on the technology, focus on what you are actually trying to build." — Scott
• [17:32] "As an industry, whether it be literature or art, there's so much to be gained by observing and reading prior works of others." — Jeffrey

Scott: Website | Twitter

Scott Wlaschin is an expert on F#, author of the popular F# site fsharpforfunandprofit.com, and a board member of the F# Software Foundation. Known for his non-academic approach to functional programming, Scott is a popular speaker and has given talks at NDC, F# Exchange, DDD Europe, and other conferences around the world.

Topics of Discussion:

[2:40] Scott talks about how he got into F#, and the nonlinear path his career has taken.

[4:00] Scott walks us through the history of F#.

[6:52] What types of applications should developers be looking at F# for?

[10:55] What was Scott's inspiration behind writing Domain Modeling Made Functional?

[12:20] Domain-driven design has nothing to do with a particular language. It's a process.

[17:32] As an industry, whether it be literature or art, there's so much to be gained by observing and reading prior works of others.

[19:55] How does functional thinking impact architecture?

[20:51] In functional programming, you want everything to be deterministic.

[28:34] What are some of the examples of transcription scripts?

[31:10] In functional programming, the main thing is the function and not the object.

Mentioned in this Episode:

Architect Tips — New video podcast!

Azure DevOps

Clear Measure (Sponsor)

.NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon!

Jeffrey Palermo's YouTube

Jeffrey Palermo's Twitter — Follow to stay informed about future events!

F# Software Foundation

Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes.

Quotes:

• [3:00] "I started learning functional programming because I sort of felt like I really knew everything there was to know about databases and all that stuff. I thought I wanted something different." — Scott
• [8:52] "It really depends on how you like to program. If you like to program in a functional style, and you want to be on .NET, then F# is perfect." — Scott
• [12:00] "Don't focus on the technology, focus on what you are actually trying to build." — Scott
• [17:32] "As an industry, whether it be literature or art, there's so much to be gained by observing and reading prior works of others." — Jeffrey

Scott:  Website | Twitter