July 1, 2026

EXTENSIBILITY FIRST: Building .NET Systems That Survive Change with Miguel Castro [MVP]

Software doesn't become difficult to maintain because developers write bad code—it becomes difficult because it wasn't designed to evolve. In this episode of the M365 FM Podcast, Mirko Peters is joined by Microsoft MVP and veteran software architect Miguel Castro to explore why extensibility should be at the heart of every modern .NET application.

Drawing on decades of experience building enterprise platforms, cloud SDKs, AI-powered transcription systems, and automation solutions, Miguel explains how designing for change helps applications survive new business requirements, emerging technologies, and growing complexity. The discussion covers the principles behind clean architecture, modular design, dependency injection, abstractions, strategy patterns, plugin architectures, and event-driven development, with practical examples from real-world enterprise projects.

Miguel also shares where developers should invest time in architecture, how to avoid overengineering, and why extensibility is about creating flexible foundations rather than unnecessary complexity. The conversation highlights how great architecture often becomes invisible because it enables software to evolve without major rewrites.

The episode also explores the impact of AI on software development. Miguel discusses how tools like AI coding assistants can dramatically improve developer productivity while emphasizing that architectural thinking, system design, and technical leadership remain uniquely human responsibilities. AI may accelerate implementation, but it cannot replace the experience required to build resilient enterprise systems.

The episode concludes with a rapid-fire discussion covering modern .NET development, ASP.NET, extension methods, async/await, Clean Architecture vs. Vertical Slice Architecture, Azure Functions vs. containers, GraphQL vs. REST, and the technologies shaping the future of enterprise development.

To build .NET systems that survive change, prioritize extensibility first. You gain long-term stability when you embrace extensibility first as your guiding principle. Miguel Castro, featured on the M365 FM podcast, describes extensibility first as the foundation for maintainable enterprise software. Extensibility first lets you adapt your applications as business needs evolve. Extensibility first supports scalable and flexible systems. Extensibility first helps you create software that grows with your organization.

Extensibility first is not just a buzzword. You build systems that handle change and thrive.

Key Takeaways

Prioritize extensibility in your .NET projects to ensure long-term stability and adaptability.
Understand the core principles of extensibility, such as the Single Responsibility Principle and Dependency Inversion Principle, to create maintainable systems.
Adopt a modular architecture to allow independent updates and easier maintenance of your application.
Use interfaces to define clear contracts between components, reducing tight coupling and enhancing testability.
Regularly refactor your code to keep it clean and flexible, preventing technical debt from accumulating.
Implement proven design patterns like Dependency Injection and Strategy Pattern to enhance extensibility and maintainability.
Avoid overengineering by focusing on current needs and keeping your design simple and user-friendly.
Leverage tools like dependency injection frameworks and workflow engines to support extensibility in your .NET systems.

Extensibility First Mindset

Why Extensibility Matters

You need to understand why extensibility sits at the heart of .NET system design. Extensible systems let you adapt quickly when business needs shift. Miguel Castro, featured on the M365 FM podcast, explains that extensibility is essential for the sustainability and evolution of software. He says that systems built with extensibility can easily handle new requirements without needing a complete rewrite. This approach lowers maintenance costs and increases long-term business value.

One of the biggest takeaways is that architecture should make future changes easier, not harder. Great architecture often becomes invisible because it simply allows software to evolve naturally.

When you design for extensibility, you can replace or extend components instead of rebuilding everything. You see this in AI-powered transcription platforms, enterprise automation solutions, and communication SDKs. These examples show how extensibility supports growth and flexibility.

The extensibility first mindset relies on several core principles. The table below outlines these principles and their descriptions:

Principle	Description
Single Responsibility Principle (SRP)	A class should have only one reason to change, meaning it should have a single responsibility.
Open–Closed Principle (OCP)	Software entities should be open for extension but closed for modification.
Liskov Substitution Principle (LSP)	Functions using base class references should work with derived class references without knowing it.
Interface Segregation Principle (ISP)	Clients should not be forced to depend on methods they do not use.
Dependency Inversion Principle (DIP)	Depend on abstractions rather than concrete implementations.

Surviving Change

You face constant shifts in technology and business requirements. Extensible .NET systems help you survive these shifts. The discussion on the M365 FM podcast highlights that extensibility is vital for adapting to changing requirements and technologies. When you move from monolithic to modular architectures, you improve maintainability and adaptability. This shift ensures your system lasts longer and stays relevant.

Miguel Castro’s experience shows that extensibility lets you evolve your software without major disruptions. You build systems that grow with your organization and respond to new challenges. Extensibility first gives you the tools to handle change and thrive in a fast-moving environment.

Causes of Technical Debt

You often hear about technical debt in .NET projects. This debt builds up when you make choices that help you move fast but create problems for the future. If you do not address these issues, your system becomes difficult to change and maintain. You need to understand the main causes of technical debt so you can avoid them and keep your software healthy.

Here is a table that shows the most common causes of technical debt in .NET projects:

Cause of Technical Debt	Description
Time-to-Market Pressure	Teams may accept technical debt to meet deadlines or launch products quickly.
Poor Technology Decisions	Choosing tools or frameworks that do not scale or become outdated adds to technical debt.
Evolving Requirements/Misaligned Expectations	Changes in project goals or misunderstandings can lead to inefficient solutions.
Lack of Resources, Budget, and/or Time	Limited resources force teams to focus on features instead of code quality.
Insufficient Testing and/or Manual Processes	Not enough automated testing allows technical debt to grow.

Code Duplication

You see code duplication when the same logic appears in many places in your .NET system. This practice creates technical debt because you must update every copy if something changes. If you miss one spot, you introduce bugs or security risks. Code duplication also makes your system difficult to change. When you want to add a new feature or fix a problem, you spend extra time searching for all the repeated code. Over time, code duplication makes your architecture messy and hard to manage. You can reduce technical debt by writing reusable functions and keeping your code clean.

Tip: Always look for repeated patterns in your code. If you find them, refactor them into shared methods or classes.

Change Resistance

You face change resistance when your system becomes difficult to change. This happens when your code is tightly connected, or you do not use interfaces and abstractions. If you want to add a new feature, you might have to change many parts of your system. This slows you down and increases the risk of errors. Technical debt grows when you avoid making improvements because the system feels too fragile. You can fight change resistance by designing for extensibility and keeping your code modular.

Learning Curve

You also create technical debt when your code is hard to understand. If new team members struggle to learn your system, they may make mistakes or avoid making changes. A steep learning curve means your code lacks clear structure or good documentation. This makes your system difficult to change and maintain. You can help your team by following clean code principles, using clear names, and writing helpful comments. When you lower the learning curve, you make it easier to keep technical debt under control.

Designing Extensible Systems

Modular Architecture

You need a modular architecture if you want your .NET system to grow or change without a meltdown. Modular architecture breaks your application into independent modules. Each module owns its business rules, data access, and APIs. This separation gives you clear boundaries and makes your system easier to maintain.

You can add, remove, or replace modules without affecting the rest of the system.
IIS7 is a great example. It uses a modular architecture with extensibility APIs. You can extend it with custom authentication, monitoring, or load balancing.
You can use both native and managed APIs to build extensions, which gives you more flexibility.
A modular monolith organizes your code into business modules. Each module has its own domain and APIs. This reduces coupling and improves design quality.

A modular approach helps you deliver features faster. You can test and maintain each module on its own. You also lower operational complexity compared to microservices. If you want to migrate to microservices in the future, modular design makes that easier.

Tip: Modular architecture helps you design to accommodate change. You can scale your system by adding new modules as your needs grow.

Stable Contracts

Stable contracts are the backbone of extensible systems. You need to design better APIs that act as contracts between modules. These contracts define how modules communicate. If you keep your contracts stable, you can change the inside of a module without breaking other parts of your system.

Use interfaces to define contracts. Interfaces set clear expectations for how modules interact.
Keep your APIs simple and focused. Avoid adding methods that do not belong.
Document your contracts well. Good documentation helps your team understand how to use your APIs.

Stable contracts reduce risk when you update or extend your system. You can improve design quality by making sure your contracts do not change often. This practice keeps your architecture strong and your system flexible.

Clean Code Principles

You need clean code principles to build systems that last. Clean code makes your design easier to understand, test, and extend. The SOLID principles are a great place to start:

Single Responsibility Principle: Each class should do one thing. This reduces complexity and makes your code easier to change.
Open/Closed Principle: Your modules should be open for extension but closed for modification. You can add new features without changing existing code.
Liskov Substitution Principle: You should be able to use derived classes in place of base classes without problems.
Interface Segregation Principle: Use many small, client-specific interfaces. This keeps your modules independent and focused.
Dependency Inversion Principle: Depend on abstractions, not concrete implementations. This makes your code more testable and less coupled.

When you follow these principles, you design systems that are easier to maintain. You also make your architecture more robust. Clean code helps your team understand and extend your system as requirements change.

Note: Clean code and modular architecture work together. They help you build scalable, flexible systems that can adapt to new challenges.

Scalable and Flexible Systems

You build scalable and flexible systems to ensure your .NET applications survive change. Scalability means your system can handle more users or data without breaking. Flexibility means you can adapt your software to new requirements or technologies. These qualities help you respond quickly to business needs and keep your applications running smoothly.

Cloud integration changes how you approach system design. You move from rigid setups to flexible environments. You deploy updates faster and scale resources up or down as needed. This elasticity gives your system built-in resilience. You maintain high availability even when demand shifts.

A well-designed system handles real-world loads. You avoid unnecessary complexity. You focus on straightforward solutions that evolve as your needs change. You do not need to rebuild your application every time requirements shift. Instead, you extend or modify parts of your system with minimal disruption.

Microservices architecture offers another path to scalability and flexibility. You break your application into independent services. Each service handles a specific task. You deploy and update these services separately. This independence reduces bottlenecks and minimizes downtime. You gain agility and make your system more resilient to change.

Tip: You can combine modular architecture with microservices to maximize scalability and flexibility. Start with clear boundaries between modules. Move to microservices when your needs grow.

You can use several strategies to build scalable and flexible .NET systems:

Design your modules to work independently.
Use stable contracts to connect modules and services.
Leverage cloud platforms for elastic scaling.
Monitor system performance and adjust resources as needed.
Automate deployments to reduce manual errors.

The table below shows how scalability and flexibility support system resilience:

Quality	Benefit	Result
Scalability	Handles increased load	Maintains performance
Flexibility	Adapts to new requirements	Reduces downtime
Independence	Updates modules/services separately	Minimizes disruption
Elasticity	Scales resources automatically	Ensures high availability

You build systems that survive change when you focus on scalability and flexibility. You prepare your .NET applications for growth and new challenges. You create software that stands the test of time.

Layered Architecture

You build strong .NET systems when you use a layered architecture. This approach divides your application into separate layers, each with a clear responsibility. You gain many benefits from this structure:

Separation of concerns makes your code easier to understand and maintain.
Modularity and reusability let you use components across different projects.
Scalability allows you to grow parts of your system without affecting others.
Testing becomes easier because you can test each layer by itself.
Enhanced maintainability helps you update and refactor your application.
Security improves because you can add protections at different levels.

Interface Layer

The interface layer acts as the gateway for your system. It defines how other parts of your application interact. You use contracts to set clear rules for communication. These contracts often take the form of interfaces or APIs. When you keep your contracts stable, you make it easier to extend your system in the future.

Contracts

Contracts in the interface layer describe what your system expects and provides. You use interfaces to define these contracts. This practice helps you separate what your system does from how it does it. When you change the implementation, you do not break other parts of your application. You also make it easier for new features to plug into your system.

Decoupling

Decoupling means you reduce direct connections between components. The interface layer helps you achieve this by using abstractions. You can swap out parts without changing the rest of your system. The table below shows how the interface layer supports extensibility:

Aspect	Description
Loose Coupling	Components connect loosely, which increases flexibility and reduces dependencies.
Runtime Discoverability	Your system can find components at runtime, making it easier to extend.
Declarative Dependencies	You can declare what your component needs, which helps with reusability.

Tip: Use tools like MEF to discover and load components based on metadata. This approach lets you add new features without changing existing code.

Logic Layer

The logic layer contains your business rules. You keep your core logic here, separate from data and user interfaces. This separation makes your system easier to test and extend.

Business Rules

You define business rules in the logic layer. These rules control how your application behaves. When you keep business logic separate, you can change rules without touching other layers. This practice supports future changes and keeps your code clean.

Reusability

You design the logic layer for reusability. Modular design lets you use the same logic in different parts of your application. You plan for change by making your logic flexible. This approach helps you extend your system as your needs grow.

Separate responsibilities within the logic layer.
Use modular design to support future extensions.
Always think about how your logic might need to change.

Data Layer

The data layer manages how your system stores and retrieves information. You keep data access separate from business logic and interfaces. This structure makes your system more flexible and easier to maintain.

Data Access

You handle all data operations in the data layer. This includes reading, writing, and updating information. By isolating data access, you can change your storage solution without affecting other layers.

Multiple Sources

You often need to work with data from different sources. The data layer lets you connect to databases, APIs, or cloud storage. You can add or switch data sources as your needs change. This flexibility supports the long-term health of your system.

Note: When you combine extensibility and architecture layers, you create a system that adapts to new requirements and technologies.

Extensibility Patterns

You can build .NET systems that adapt to change by using proven extensibility patterns. These patterns help you add new features, swap out components, and keep your code clean. Let’s look at three of the most effective patterns: Dependency Injection, Strategy Pattern, and Composition.

Dependency Injection

Dependency injection gives you a way to build flexible and testable .NET applications. You inject dependencies into your classes instead of hard-coding them. This approach lets you swap out implementations without changing your core logic.

You can add new notification methods by creating a new class that implements the right interface. Then, inject it into your service.
You integrate new features without touching existing code. This makes your system more adaptable.
You extend functionality by registering new interfaces. You do not need to rewrite your main logic.

Tip: Dependency injection reduces tight coupling. You gain the freedom to update or replace services as your needs change.

Here are some common extensibility patterns you might use in .NET:

Pattern	Description
Providers	Design data and behavior in an abstraction. You can swap implementations at any time.
Plug-Ins	Create swappable modules that add or change features. Enhance your application without big rewrites.
Modules	Group multiple plug-ins in a single class. Centralize extensibility for better control.

Strategy Pattern

The strategy pattern helps you manage different ways to solve a problem. You define a family of algorithms, put each in its own class, and make them interchangeable. This pattern gives you several benefits:

Modular code: Break complex logic into smaller, easier-to-understand pieces.
Code reusability: Encapsulate algorithms so you can swap and reuse them.
Flexibility: Change or extend behavior without changing your code’s structure.
Testability: Test each strategy on its own for better reliability.
Decoupling: Reduce dependencies between classes. Make your code easier to maintain.
Extensibility: Add new strategies without touching existing code.

Note: The strategy pattern works well when you need to support multiple behaviors or algorithms. You can add new strategies as your business needs grow.

Composition

Composition lets you build systems by combining small, focused components. You assemble features by plugging together these components, rather than relying on deep inheritance.

How Composition Supports Extensibility
Add, update, or remove components at runtime without restarting your system.
Use plugin-based architecture to let teams develop and integrate parts independently.
Encapsulate features in self-contained plugins for easier maintenance, testing, and extension.

You gain the power to scale and adapt your .NET system. You can update parts without breaking the whole application. You also make it easier for teams to work on different features at the same time.

Tip: Choose composition when you want to keep your system flexible and ready for future changes. It helps you avoid the limits of rigid inheritance.

Avoiding Overdesign

Designing for extensibility is important, but you must also avoid overdesign. If you add too many layers or features, your .NET system can become confusing and hard to use. Overdesign often leads to wasted time and effort. You want to keep your system simple and focused.

Current Needs

You should always build for the current problem. Focus on what your users need right now. If you try to solve every possible future issue, you may create features that no one uses. This makes your code harder to understand and maintain.

High cohesion and low coupling help you keep modules focused and easy to reuse.
Separation of concerns lets you avoid mixing concerns and makes future changes easier.
Conceptual integrity ensures your system feels consistent, even if many people work on it.

Set clear goals for performance, security, and scalability. Review your architecture often to make sure it matches your business needs. Use best practices for .NET development to keep your code clean and efficient.

Tip: Start simple. Add complexity only when you see a real need.

Future Flexibility

You want your system to handle future changes, but you should not guess every possible requirement. Plan for flexibility by making your code modular and easy to extend. Use interfaces and abstractions where they make sense.

Assign different concerns to different modules.
Keep your modules independent so you can update them without breaking the rest of your system.
Make sure your system stays consistent as it grows.

Regular architecture reviews help you adjust your design as your needs change. This approach lets you stay flexible without adding unnecessary complexity.

Overengineering Signs

Watch for signs that you are overengineering your .NET project. Common signs include too much code complexity, extra layers, and patterns that do not solve real problems. You might see teams creating abstractions for situations that never happen. This makes your system hard to understand and slows down development.

Some warning signs include:

Creating too many abstract, reusable mechanisms
Applying the DRY principle when it does not help
Ignoring the KISS (Keep It Simple, Stupid) and YAGNI (You Aren't Gonna Need It) principles

Overdesign can also lead to user overload. Too many warnings or options can confuse users. Good design should reduce risks through clear structure and usability, not just by adding more warnings.

Note: Focus on solving real problems. Keep your design simple and easy to use.

Extensibility-First Steps

Start with Interfaces

You should always begin your .NET projects by defining interfaces. Interfaces set clear expectations for how different parts of your system interact. When you program to interfaces, you reduce the chance that changes in one part will break another. This approach lowers the frequency of co-changes between components. Protected pairs often show co-change ratios under 10%. You gain better testability because you can create mock versions of your interfaces. This makes unit testing easier and faster. You do not need to rely on real dependencies during tests.

Standardized interfaces also help your system scale. Loose coupling lets you add new features or swap out components without major rewrites. This is important in large systems and microservices. You can see the benefits in many enterprise projects. Teams that start with interfaces find it easier to adapt when requirements change.

Tip: Define interfaces before you write any implementation. This practice keeps your architecture flexible and future-proof.

Interfaces reduce tight coupling.
Interfaces improve testability with mocks.
Interfaces support scalability in large systems.

Use Design Patterns

You should use design patterns to solve common problems in .NET development. Design patterns give you proven solutions for building clean and modular code. They help you address architectural challenges without reinventing the wheel. When you use patterns, you make your code easier to read and maintain. You also reduce complexity and avoid repeating logic.

Design patterns promote scalability and extensibility. They let you add new features with less risk. Teams that use patterns share a common vocabulary, which improves communication and speeds up development. Some of the most effective patterns for extensible .NET systems include:

Singleton
Factory
Strategy
Observer
Decorator
Builder

You can use these patterns to organize your code and handle changes smoothly. For example, the Strategy pattern lets you swap algorithms without changing the rest of your code. The Factory pattern helps you create objects in a flexible way. Each pattern addresses a specific challenge and makes your system more robust.

Note: Design patterns are not just for experts. You can start small and add more as your system grows.

Modular, Testable Code

You need a modular approach if you want your .NET system to survive change. Modular code means you break your application into small, focused parts. Each module handles a single responsibility. This makes your system easier to understand and update. You can swap modules in and out without affecting the whole application.

A pipeline mentality helps you design for adaptability. You build your system so that you can replace components without breaking the overall structure. Clients value this flexibility. They can request quick changes after delivery, and you can respond without major rewrites.

Testable code is another key to extensibility. When you write small, independent modules, you can test each one on its own. This practice catches bugs early and keeps your system reliable. You also save time during maintenance.

Modular design allows for easy changes.
A pipeline mentality supports component swapping.
Testable code increases reliability and speeds up delivery.

Tip: Review your code often. Refactor modules that grow too large or complex. This keeps your system healthy and ready for new challenges.

Refactor Regularly

You need to make refactoring a regular part of your development process. Refactoring means improving your code without changing what it does. This practice keeps your .NET system clean, flexible, and ready for change. When you refactor often, you prevent your code from becoming tangled and hard to manage.

You should not wait for problems to appear before you refactor. Small, frequent improvements help you avoid technical debt. You spot issues early and fix them before they grow. This habit supports extensibility because clean code is easier to extend and maintain.

Tip: Schedule time for refactoring during each sprint or development cycle. Treat it as a core activity, not an afterthought.

Why Refactoring Matters

Refactoring helps you keep your codebase healthy. You remove duplication, simplify logic, and improve naming. These changes make your code easier to read and understand. When your code is clear, you can add new features with less risk.

Here are some key benefits of regular refactoring:

Improved readability: Clean code is easier for you and your team to understand.
Reduced bugs: Simple, well-structured code has fewer hidden problems.
Faster onboarding: New team members learn the system quickly.
Easier testing: Smaller, focused modules are easier to test.
Better extensibility: You can add or change features without breaking existing code.

How to Refactor Effectively

You can follow a simple process to refactor your .NET code:

Identify code smells: Look for signs like long methods, duplicate code, or unclear names.
Write tests: Make sure you have tests that cover the code you want to change.
Make small changes: Refactor in small steps. Test after each change.
Review and repeat: Check your work and look for more areas to improve.

Note: Automated tools like Visual Studio’s refactoring features can help you make safe changes quickly.

Common Refactoring Techniques

You can use many techniques to improve your code. Here are a few examples:

Technique	Description
Extract Method	Move part of a large method into a new one
Rename Variable	Give variables clear, meaningful names
Inline Variable	Replace a variable with its value
Replace Magic Number	Use named constants instead of numbers
Simplify Conditionals	Make complex logic easier to follow

You do not need to refactor everything at once. Focus on the most important areas first. Over time, your codebase will become stronger and more adaptable.

Remember: Regular refactoring is your best tool for keeping your .NET system extensible and healthy. Make it a habit, and your software will stand the test of time.

Real-World Examples

Extensible System Case Study

You can see the power of extensibility-first thinking in real-world .NET projects. Many organizations have built flexible solutions that adapt to new needs and technologies. The table below shows how different industries use extensible systems to solve complex problems:

Use Case	Description
Manufacturing Automation	A .NET-heavy manufacturing firm integrated ERP, IoT, and HR processes using FlowWright with deep backend control.
Banking Compliance	A financial institution built workflows for KYC/AML document validation, utilizing document AI and real-time dashboards.
SaaS Workflow Embedding	An ISV embedded FlowWright into their SaaS product, managing workflows per tenant with .NET backends.

In manufacturing, you can connect ERP, IoT, and HR systems using a single extensible system. This approach lets you automate processes and respond quickly to changes in production or staffing. In banking, you can build workflows that handle compliance checks and document validation. These workflows use AI to review documents and update dashboards in real time. For SaaS providers, embedding a workflow engine allows you to manage each tenant’s needs without rewriting your core application.

Tip: When you design for extensibility, you make it easier to add new features, connect to new services, and support future growth.

Common Pitfalls

You may face challenges when building for extensibility. One common pitfall is overcomplicating your design. If you add too many layers or abstractions, your code becomes hard to understand and maintain. Another mistake is ignoring clear boundaries between modules. When modules depend too much on each other, you lose flexibility and make future changes harder.

You might also forget to document your interfaces and contracts. Without good documentation, your team struggles to extend or update the system. Skipping regular refactoring can lead to tangled code that resists change. You should watch for these pitfalls and address them early.

Avoid unnecessary complexity.
Keep modules independent.
Document your contracts and interfaces.
Refactor often to keep your code clean.

Tools for Extensibility

You have many tools that help you build extensible .NET systems. Dependency injection frameworks like Microsoft.Extensions.DependencyInjection or Autofac let you swap out components easily. You can use plugin frameworks such as MEF (Managed Extensibility Framework) to load new features at runtime. Workflow engines like FlowWright or Windows Workflow Foundation help you design flexible business processes.

Version control systems, such as Git, support branching and merging, which makes it easier to manage changes. Automated testing tools like xUnit or NUnit help you catch problems early and keep your system reliable. Code analysis tools, such as SonarQube or Visual Studio analyzers, help you spot issues before they become technical debt.

Note: Choose tools that fit your team’s skills and your project’s needs. The right tools make it easier to build, test, and maintain an extensible system.

You gain lasting benefits when you adopt extensibility-first thinking in your .NET projects. Scalable and flexible systems help you respond to new demands and keep your software strong. Miguel Castro’s advice encourages you to keep learning and improving your architecture.

Take action: define clear interfaces, use proven design patterns, and refactor your code often.
You build software that grows with your business and stands up to change.

FAQ

What does "extensibility first" mean in .NET development?

You design your .NET system to support future changes. You plan for growth from the start. This approach helps you add features, swap components, and adapt to new requirements without major rewrites.

How do interfaces help with extensibility?

You use interfaces to define clear contracts. Interfaces let you swap implementations easily. This practice reduces tight coupling and makes your code more flexible and testable.

Why should you avoid overengineering when designing for extensibility?

You keep your system simple and focused. Overengineering adds unnecessary complexity. You solve real problems instead of guessing every possible future need.

Which design patterns support extensibility in .NET?

You benefit from patterns like Dependency Injection, Strategy, Factory, and Observer. These patterns help you organize code, add features, and keep your system flexible.

How does modular architecture improve maintainability?

You break your application into independent modules. Each module handles a specific responsibility. This structure makes updates, testing, and scaling easier.

What tools can you use to build extensible .NET systems?

You can use tools like Microsoft.Extensions.DependencyInjection, Autofac, MEF, and workflow engines. These tools help you manage dependencies, load plugins, and automate business processes.

How often should you refactor your code for extensibility?

You should refactor regularly. Frequent, small improvements keep your code clean and adaptable. This habit prevents technical debt and supports long-term growth.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

1
00:00:00,000 --> 00:00:03,380
Yeah, welcome back to the podcast.

2
00:00:03,380 --> 00:00:06,580
Today we are joining by someone who has spent

3
00:00:06,580 --> 00:00:10,620
decade with solving the kinds of software problems

4
00:00:10,620 --> 00:00:14,180
that most developers only encounter once or twice

5
00:00:14,180 --> 00:00:16,060
in a career.

6
00:00:16,060 --> 00:00:20,160
Miguel Castro is his new dot-net engineer,

7
00:00:20,160 --> 00:00:22,180
software architect, ConsulTown,

8
00:00:22,180 --> 00:00:23,980
at International Conference Speaker,

9
00:00:23,980 --> 00:00:26,660
and one of Microsoft's most respective morrisons

10
00:00:26,660 --> 00:00:28,460
in application architecture

11
00:00:28,460 --> 00:00:31,820
and invincibility design through his career.

12
00:00:31,820 --> 00:00:35,460
He built communication platform, cloud SDKs,

13
00:00:35,460 --> 00:00:39,060
AI powered voice transcription systems,

14
00:00:39,060 --> 00:00:42,020
automation platforms and enterprise applications

15
00:00:42,020 --> 00:00:44,180
that have powered business for years,

16
00:00:44,180 --> 00:00:46,380
especially is simply writing code.

17
00:00:46,380 --> 00:00:49,220
It's designing systems that continue working

18
00:00:49,220 --> 00:00:51,660
as requirement evolved technologies,

19
00:00:51,660 --> 00:00:54,420
change and business grow.

20
00:00:54,420 --> 00:00:57,940
If you ever wonder why some enterprise applications

21
00:00:57,940 --> 00:01:00,100
become impossible to maintain,

22
00:01:00,100 --> 00:01:04,700
while other seems to evolve affordously today's conversation

23
00:01:04,700 --> 00:01:06,100
is for you.

24
00:01:06,100 --> 00:01:10,340
We explore extensibility software architecture,

25
00:01:10,340 --> 00:01:13,300
Azure AI automation, the weather approach,

26
00:01:13,300 --> 00:01:17,020
the clean design and what great architecture is often

27
00:01:17,020 --> 00:01:18,020
invisible.

28
00:01:18,020 --> 00:01:20,500
Miguel, welcome to the show.

29
00:01:20,500 --> 00:01:21,340
Thank you, thank you.

30
00:01:21,340 --> 00:01:22,340
How could it be here?

31
00:01:22,340 --> 00:01:23,420
Thanks for having me.

32
00:01:23,420 --> 00:01:24,180
Yeah.

33
00:01:26,140 --> 00:01:31,140
Where did your journey into software development begin?

34
00:01:31,140 --> 00:01:33,580
Oh boy.

35
00:01:33,580 --> 00:01:36,180
That would give away how old I am, wouldn't it?

36
00:01:36,180 --> 00:01:38,620
I don't know.

37
00:01:38,620 --> 00:01:40,020
I don't know if we want to give away my age,

38
00:01:40,020 --> 00:01:41,140
but you have not.

39
00:01:41,140 --> 00:01:43,740
I got, I mean, I don't want to turn it

40
00:01:43,740 --> 00:01:45,900
into a really long story,

41
00:01:45,900 --> 00:01:47,740
though I do enjoy talking about it,

42
00:01:47,740 --> 00:01:50,500
but I've been programming since I was 12.

43
00:01:50,500 --> 00:01:53,380
So back in the days of,

44
00:01:53,380 --> 00:01:56,660
I mean, my first computer was a radio shak, TRS80,

45
00:01:56,660 --> 00:02:00,220
and then I went into a Atari 800 and then Apple

46
00:02:00,220 --> 00:02:03,300
and I come from those days, you know what I mean?

47
00:02:03,300 --> 00:02:11,140
What, or what attract you to adopt that?

48
00:02:11,140 --> 00:02:14,060
Well, I've been in the Microsoft spaces

49
00:02:14,060 --> 00:02:15,220
for a very long time.

50
00:02:15,220 --> 00:02:19,180
I moved into the Microsoft spaces with VB,

51
00:02:19,180 --> 00:02:22,140
like most programmers do actually.

52
00:02:22,140 --> 00:02:24,380
When VB1 first came out a long time ago,

53
00:02:24,380 --> 00:02:28,700
I was just fascinated by the idea of drag and drop

54
00:02:28,700 --> 00:02:32,060
GUI design and putting events behind it,

55
00:02:32,060 --> 00:02:35,100
which was back then it was something new, of course.

56
00:02:35,100 --> 00:02:39,940
And it just became fascinating and I got into it

57
00:02:39,940 --> 00:02:41,940
like a lot of people that are listening right now,

58
00:02:41,940 --> 00:02:43,820
you know, you get into it as a hobby first

59
00:02:43,820 --> 00:02:45,060
and then it turns into a career.

60
00:02:45,060 --> 00:02:48,180
Now, I was already doing computer programming

61
00:02:48,180 --> 00:02:53,180
outside of the Microsoft arena from '86 all the way to,

62
00:02:53,180 --> 00:02:59,540
I would guess '90, '89, '90, just before Microsoft entered

63
00:02:59,540 --> 00:03:02,020
the VB spaces.

64
00:03:02,020 --> 00:03:06,540
And so I was in new to programming and logic and stuff like that.

65
00:03:06,540 --> 00:03:09,980
But that was my gateway from my old world

66
00:03:09,980 --> 00:03:13,860
into the world of Microsoft and I've been in that world

67
00:03:13,860 --> 00:03:16,820
since then, I've never gone another direction.

68
00:03:16,820 --> 00:03:20,300
So I've progressed through the same way Microsoft has progressed

69
00:03:20,300 --> 00:03:21,620
this products.

70
00:03:21,620 --> 00:03:24,540
I've, my career has progressed parallel

71
00:03:24,540 --> 00:03:27,140
with all the products that Microsoft kept releasing.

72
00:03:27,140 --> 00:03:32,580
>> Yeah, you stay a long time in enterprise software development.

73
00:03:32,580 --> 00:03:37,340
What is the difference from your starting and today?

74
00:03:37,340 --> 00:03:44,180
>> Well, we got a new competitor to deal with, of course,

75
00:03:44,180 --> 00:03:47,140
and it's got no face, unfortunately.

76
00:03:47,140 --> 00:03:49,660
I'm talking about AI, of course.

77
00:03:49,660 --> 00:03:54,540
That's the primary reason today, like really currently today.

78
00:03:54,540 --> 00:03:58,500
But just over the years, you know,

79
00:03:58,500 --> 00:03:59,820
I would have to give that a lot of thought.

80
00:03:59,820 --> 00:04:04,500
Over the years, paradigms and software engineering techniques

81
00:04:04,500 --> 00:04:09,500
have just changed constantly as new technologies come out,

82
00:04:10,500 --> 00:04:15,460
new ways of doing things are brought into play.

83
00:04:15,460 --> 00:04:19,740
So it's ever evolving, it always has been.

84
00:04:19,740 --> 00:04:27,820
I mean, I come from a time where something as simple as functions

85
00:04:27,820 --> 00:04:30,220
and subroutines were not around.

86
00:04:30,220 --> 00:04:32,060
Everything was top to bottom programming.

87
00:04:32,060 --> 00:04:37,300
And that, of course, changed radically as languages evolved

88
00:04:37,300 --> 00:04:38,980
to introduce more modularity.

89
00:04:40,220 --> 00:04:43,620
And I just followed things along.

90
00:04:43,620 --> 00:04:48,620
And it's almost hard to remember how I was designing systems

91
00:04:48,620 --> 00:04:51,140
back then or applications.

92
00:04:51,140 --> 00:04:54,460
It is hard to remember, not just because I'm older,

93
00:04:54,460 --> 00:04:57,220
but and I'm sure a lot of developers out there

94
00:04:57,220 --> 00:05:01,180
will agree with the statement that no,

95
00:05:01,180 --> 00:05:05,980
you don't design a system or an application the same way

96
00:05:05,980 --> 00:05:07,220
every single time.

97
00:05:07,220 --> 00:05:11,100
As soon as you finish it, you immediately think of things

98
00:05:11,100 --> 00:05:13,940
that you would have done differently or better.

99
00:05:13,940 --> 00:05:17,940
And then you say that for the next application, you know?

100
00:05:17,940 --> 00:05:22,500
- Yeah, and what, what actually makes it,

101
00:05:22,500 --> 00:05:25,980
makes for you a great software architecture?

102
00:05:25,980 --> 00:05:26,820
- Say again.

103
00:05:26,820 --> 00:05:31,660
- What actually makes a great software architecture for you?

104
00:05:31,660 --> 00:05:34,260
What, when we think in modern times?

105
00:05:34,260 --> 00:05:38,060
Well, pretty much the topic that we're talking about today

106
00:05:38,060 --> 00:05:39,020
is the main one.

107
00:05:39,020 --> 00:05:41,740
I mean, there's other important topics.

108
00:05:41,740 --> 00:05:43,580
I mean, when you get into larger systems

109
00:05:43,580 --> 00:05:46,180
and you gotta do service to composition

110
00:05:46,180 --> 00:05:50,100
and break things apart in smaller portions

111
00:05:50,100 --> 00:05:53,540
and, you know, with the introduction of microservices and stuff,

112
00:05:53,540 --> 00:05:57,140
those are all things that are important in designing a system,

113
00:05:57,140 --> 00:06:00,860
but the extensibility aspect of it,

114
00:06:00,860 --> 00:06:03,300
to me is it's near and dear to my heart.

115
00:06:03,300 --> 00:06:06,500
It's something that I got fascinated by

116
00:06:06,500 --> 00:06:08,820
and I'm more than willing to tell you when in a minute,

117
00:06:08,820 --> 00:06:12,340
but I got fascinated by when I first got introduced to that

118
00:06:12,340 --> 00:06:16,820
concept of plugins and modularity and stuff like that.

119
00:06:16,820 --> 00:06:21,820
And I think that is, to me, that's the foundation

120
00:06:21,820 --> 00:06:23,940
for a really well-architected system

121
00:06:23,940 --> 00:06:27,900
because once things are extensible, they become maintainable,

122
00:06:27,900 --> 00:06:29,340
they become readable.

123
00:06:29,340 --> 00:06:30,180
You know what I mean?

124
00:06:30,180 --> 00:06:32,100
There's a lot of words that end with able

125
00:06:32,100 --> 00:06:35,900
that follow along, so it's kind of at the top of my list.

126
00:06:35,900 --> 00:06:41,820
- One thing a little bit about.net to develop on, okay?

127
00:06:41,820 --> 00:06:47,820
I can see three-year, three parts, three parts,

128
00:06:47,820 --> 00:06:53,540
I don't know, three different kinds of developers.

129
00:06:53,540 --> 00:06:57,220
Yeah, there is one, one they say, okay,

130
00:06:57,220 --> 00:07:01,700
we are the.net developers, we develop something that's work.

131
00:07:01,700 --> 00:07:06,700
And there is all the other team, I say, tips, yeah.

132
00:07:06,700 --> 00:07:10,820
Writing a clean code team and designing a good system team.

133
00:07:10,820 --> 00:07:15,860
What is the different between writing clean code

134
00:07:15,860 --> 00:07:17,380
and designing a good system?

135
00:07:17,380 --> 00:07:21,700
- One right on top of the other.

136
00:07:21,700 --> 00:07:23,020
I don't think you can write clean code

137
00:07:23,020 --> 00:07:25,580
without designing a good system first.

138
00:07:25,580 --> 00:07:29,260
I mean, to me, systems are made up of parts of components,

139
00:07:29,260 --> 00:07:32,820
which fits well into the world of AI today

140
00:07:32,820 --> 00:07:36,780
because you can actually spawn off some of that kind of writing

141
00:07:36,780 --> 00:07:41,420
to AI agents, but the,

142
00:07:41,420 --> 00:07:44,860
and I don't think AI agents actually write clean code

143
00:07:44,860 --> 00:07:45,860
to be honest with you.

144
00:07:45,860 --> 00:07:49,980
But that's the, I'm not sure if I understand

145
00:07:49,980 --> 00:07:51,620
the question entirely.

146
00:07:51,620 --> 00:07:57,300
The difference between, repeat the question again for a second.

147
00:07:57,300 --> 00:07:58,140
- Yeah.

148
00:07:58,140 --> 00:08:00,540
What's the difference between writing clean code

149
00:08:00,540 --> 00:08:02,260
and designing a good system?

150
00:08:02,260 --> 00:08:09,460
- Yeah, you can, you can design a system without writing any code.

151
00:08:09,460 --> 00:08:13,540
I mean, to me, the design part of a, of a project is,

152
00:08:13,540 --> 00:08:15,540
you know, architecture and design kind of in,

153
00:08:15,540 --> 00:08:17,460
they blend in together.

154
00:08:17,460 --> 00:08:20,700
I do all that before I eating write any code.

155
00:08:20,700 --> 00:08:24,620
I want to, I want to break it apart as much as I can

156
00:08:25,540 --> 00:08:29,620
into the proper layers and components and sections

157
00:08:29,620 --> 00:08:33,340
and things like that before I even write any code.

158
00:08:33,340 --> 00:08:37,340
That allows me to, when I get to the point of writing code,

159
00:08:37,340 --> 00:08:41,380
I'm writing smaller pieces which allow you to maintain clean,

160
00:08:41,380 --> 00:08:45,420
you know, a clean style much easier than if you're just,

161
00:08:45,420 --> 00:08:47,580
if you jump right into a system without proper design

162
00:08:47,580 --> 00:08:51,060
without architecture, everybody out listening is gonna agree.

163
00:08:51,060 --> 00:08:53,060
You can start coding right away.

164
00:08:53,060 --> 00:08:56,700
And without a proper design, your code's not gonna end up clean.

165
00:08:56,700 --> 00:08:57,740
I don't care how good you are.

166
00:08:57,740 --> 00:08:59,820
It's just not gonna work out that way.

167
00:08:59,820 --> 00:09:02,220
So, so the two things do have to,

168
00:09:02,220 --> 00:09:05,140
you know, it's gotta be a chicken before the egg or whatever

169
00:09:05,140 --> 00:09:07,700
that that saying is, you know, it's gotta,

170
00:09:07,700 --> 00:09:09,420
you gotta, you gotta, you gotta,

171
00:09:09,420 --> 00:09:13,060
you're a crawl before you walk is a better analogy.

172
00:09:13,060 --> 00:09:16,100
You know, do your, do your design and architecture first

173
00:09:16,100 --> 00:09:17,940
and then you can start,

174
00:09:17,940 --> 00:09:21,540
then it been writing, writing good code is gonna be easier.

175
00:09:21,540 --> 00:09:24,620
Now, of course, the, the, the, the, the, the, the,

176
00:09:24,620 --> 00:09:27,020
clean code is a very subjective term.

177
00:09:27,020 --> 00:09:29,900
What maybe being to me is not gonna be clean to you.

178
00:09:29,900 --> 00:09:31,780
There are, there are certain objective things

179
00:09:31,780 --> 00:09:35,060
that are yes or no, this is clean or this is not,

180
00:09:35,060 --> 00:09:38,180
but, but it all comes down to style too.

181
00:09:38,180 --> 00:09:40,660
And programmers are very personal with their style

182
00:09:40,660 --> 00:09:42,420
and with the way they write code

183
00:09:42,420 --> 00:09:44,540
and what they consider clean code.

184
00:09:44,540 --> 00:09:47,500
And not to say that one is wrong, one is right,

185
00:09:47,500 --> 00:09:50,460
but it can become a very argumentative topic.

186
00:09:51,300 --> 00:09:54,620
When you talk one program to another, you know what I'm saying?

187
00:09:54,620 --> 00:09:59,740
- Yeah, this is interesting.

188
00:09:59,740 --> 00:10:04,740
And I think a little bit about enterprise projects.

189
00:10:04,740 --> 00:10:10,140
What's the reason why they become difficult to maintain?

190
00:10:10,140 --> 00:10:16,460
- Oh, probably, if I had to nail,

191
00:10:16,460 --> 00:10:17,780
I mean, I'm sure there are many reasons

192
00:10:17,780 --> 00:10:19,420
and everybody's got their own reasons for it.

193
00:10:19,420 --> 00:10:22,420
But if I had to nail one thing, it's probably

194
00:10:22,420 --> 00:10:25,660
that they're not designed in a way that allows

195
00:10:25,660 --> 00:10:30,740
enhancement and modification later in an easy way.

196
00:10:30,740 --> 00:10:33,500
And that's where the topic of extensibility comes in.

197
00:10:33,500 --> 00:10:38,100
At least this has been my experience in my career.

198
00:10:38,100 --> 00:10:40,300
When I encounter a system that is,

199
00:10:40,300 --> 00:10:44,780
that is tough to enhance and tough to maintain and modify,

200
00:10:46,060 --> 00:10:49,740
I don't throw my hands up in here and give up,

201
00:10:49,740 --> 00:10:52,540
but I'll throw my hands up in here and curse somebody out.

202
00:10:52,540 --> 00:10:58,820
- And let me ask this a little bit different,

203
00:10:58,820 --> 00:11:02,700
but when you're joining existing project,

204
00:11:02,700 --> 00:11:06,180
what are the first warning signals

205
00:11:06,180 --> 00:11:09,420
that the architecture is in trouble?

206
00:11:09,420 --> 00:11:15,700
- Okay, the system does this that and the other.

207
00:11:15,700 --> 00:11:17,500
I don't like this part of it.

208
00:11:17,500 --> 00:11:21,420
What do I have to do to change this one little part of it?

209
00:11:21,420 --> 00:11:22,820
That's a pretty general question,

210
00:11:22,820 --> 00:11:27,380
but that question I think is how I would nail your,

211
00:11:27,380 --> 00:11:29,220
the question is just ask me.

212
00:11:29,220 --> 00:11:31,860
It's, again, a looting to extensibility.

213
00:11:31,860 --> 00:11:36,660
If I find that it's just a pain in the ass to change something,

214
00:11:36,660 --> 00:11:38,060
if the answer that I get is,

215
00:11:38,060 --> 00:11:40,460
"Oh, we would have to rewrite all of that."

216
00:11:40,460 --> 00:11:43,260
That already raises a red flag on how this was designed

217
00:11:43,260 --> 00:11:44,700
and architected to begin with.

218
00:11:45,660 --> 00:11:52,660
- Yeah, I think a lot of companies think development,

219
00:11:52,660 --> 00:11:56,740
it's a project.

220
00:11:56,740 --> 00:12:01,140
And I think in a little bit about

221
00:12:01,140 --> 00:12:04,660
can an architecture ever be finished?

222
00:12:04,660 --> 00:12:08,020
So there's just something, what's make a project?

223
00:12:08,020 --> 00:12:12,740
- Say repeat that again?

224
00:12:12,740 --> 00:12:16,460
- Yeah, I think a little bit about companies.

225
00:12:16,460 --> 00:12:19,500
And companies are doing development

226
00:12:19,500 --> 00:12:22,300
and they treat it as a project.

227
00:12:22,300 --> 00:12:27,980
Can a chic texture ever be finished?

228
00:12:27,980 --> 00:12:32,180
So is it right thinking or is there wrong thinking

229
00:12:32,180 --> 00:12:33,660
that's of the development of them?

230
00:12:33,660 --> 00:12:34,780
- Yes, yes and no.

231
00:12:34,780 --> 00:12:37,700
And that's always the tough question because

232
00:12:37,700 --> 00:12:41,220
there is such a thing as over-architecting,

233
00:12:41,220 --> 00:12:45,460
but in my opinion, in my experience through my career,

234
00:12:45,460 --> 00:12:47,700
everybody approaches it differently, like I said,

235
00:12:47,700 --> 00:12:50,620
it's a very personal way of doing things,

236
00:12:50,620 --> 00:12:55,620
but in my career architecture can evolve as well.

237
00:12:55,620 --> 00:12:59,660
I mean, you need to get a design and architecture

238
00:12:59,660 --> 00:13:03,060
of a software system to a certain point

239
00:13:03,060 --> 00:13:04,740
to get started on the coding,

240
00:13:04,740 --> 00:13:07,060
but that doesn't mean that you have to have the architecture

241
00:13:07,060 --> 00:13:11,180
and the design 100% done in order to start writing for it.

242
00:13:11,180 --> 00:13:14,540
But a certain part of the architecture,

243
00:13:14,540 --> 00:13:16,740
how components are connected together

244
00:13:16,740 --> 00:13:18,700
and how things can be plugged in later,

245
00:13:18,700 --> 00:13:21,420
again, alluding to extensibility.

246
00:13:21,420 --> 00:13:25,420
I personally like to get that part done out of the way.

247
00:13:25,420 --> 00:13:28,340
And then as I start writing components for it,

248
00:13:28,340 --> 00:13:33,340
then as I start writing components for it,

249
00:13:33,340 --> 00:13:35,780
I may go back and revisit the architecture

250
00:13:35,780 --> 00:13:38,820
and there's nothing wrong with revisiting.

251
00:13:40,420 --> 00:13:43,700
If you do it step by, it's more of an agile way of doing it.

252
00:13:43,700 --> 00:13:44,540
You know what I mean?

253
00:13:44,540 --> 00:13:47,780
Architecture's revisited just like component development is.

254
00:13:47,780 --> 00:13:54,060
- Yeah, I think a little bit about,

255
00:13:54,060 --> 00:13:58,940
so I'm more the 80% guy.

256
00:13:58,940 --> 00:14:02,020
I do the NBP and then I leave the project

257
00:14:02,020 --> 00:14:07,020
and let's do the 20% that's really take the 100% of time.

258
00:14:09,540 --> 00:14:13,540
But how do you balance business deadlines against

259
00:14:13,540 --> 00:14:15,900
technical excellence?

260
00:14:15,900 --> 00:14:20,580
- How do I balance business again, say say that again?

261
00:14:20,580 --> 00:14:25,580
- Yeah, business deadlines against technical excellence.

262
00:14:25,580 --> 00:14:29,380
- Well then I'm sorry, my phone kept going off

263
00:14:29,380 --> 00:14:31,140
and I didn't, I'm gonna have to ask you

264
00:14:31,140 --> 00:14:32,540
to repeat that one more time.

265
00:14:32,540 --> 00:14:34,180
- Yeah, yeah, no problem.

266
00:14:34,180 --> 00:14:38,940
How do you balance business deadlines against technical excellence?

267
00:14:38,940 --> 00:14:42,420
- Ha, ha, ha, deadlines, huh?

268
00:14:42,420 --> 00:14:44,220
I hate deadlines, I don't like deadlines.

269
00:14:44,220 --> 00:14:46,740
- I work well with deadlines.

270
00:14:46,740 --> 00:14:47,580
I mean, I do all right.

271
00:14:47,580 --> 00:14:52,260
It's, you know, that's gonna be a case by case thing, man.

272
00:14:52,260 --> 00:14:55,460
It's gonna not only depend on what kind of architecture

273
00:14:55,460 --> 00:14:57,020
and design you put together,

274
00:14:57,020 --> 00:15:02,100
but it's gonna depend on the quality

275
00:15:02,100 --> 00:15:07,100
of your development staff and also the type of companies

276
00:15:07,820 --> 00:15:09,820
you work, people you work for.

277
00:15:09,820 --> 00:15:14,660
I've worked for all types of bosses.

278
00:15:14,660 --> 00:15:16,980
Most of them have been very, very good,

279
00:15:16,980 --> 00:15:19,660
but I remember I was working for a company

280
00:15:19,660 --> 00:15:23,820
when I was living in Jersey that came around and told me

281
00:15:23,820 --> 00:15:27,420
that they were a very date oriented shop.

282
00:15:27,420 --> 00:15:29,740
Okay, I was, what exactly does that mean?

283
00:15:29,740 --> 00:15:33,140
That means when we see something we need to write,

284
00:15:33,140 --> 00:15:35,900
we set a date first just to when it needs to be done.

285
00:15:35,900 --> 00:15:38,340
And everything is based on that.

286
00:15:38,340 --> 00:15:40,660
Okay, well, I don't know anything about the system yet.

287
00:15:40,660 --> 00:15:42,900
I don't know what to design, what target,

288
00:15:42,900 --> 00:15:47,140
how do all I know is that you want this by this date?

289
00:15:47,140 --> 00:15:48,500
That's all I know.

290
00:15:48,500 --> 00:15:49,700
Well, that's just the way we work.

291
00:15:49,700 --> 00:15:51,100
That was the answer I got.

292
00:15:51,100 --> 00:15:56,100
So I can see excellence coming out of a project like that.

293
00:15:56,100 --> 00:15:59,660
It's just, it's a very case by case thing.

294
00:15:59,660 --> 00:16:04,860
I'm not sure if that answers your question.

295
00:16:04,860 --> 00:16:09,860
Yeah, I am also not the design fan.

296
00:16:09,860 --> 00:16:16,380
Yeah, because, yeah, you got the MVP and then you have,

297
00:16:16,380 --> 00:16:20,460
it's running, but yeah, it's, but you know what,

298
00:16:20,460 --> 00:16:24,140
that's where having extensibility in mind comes

299
00:16:24,140 --> 00:16:28,900
very important because when I architect something,

300
00:16:28,900 --> 00:16:30,620
when I design, I notice I keep putting the word

301
00:16:30,620 --> 00:16:32,780
architect to design kind of together,

302
00:16:32,780 --> 00:16:35,300
just to me, they're almost intertwined.

303
00:16:35,300 --> 00:16:37,820
But when I architect the system,

304
00:16:37,820 --> 00:16:42,820
I always have extensibility and modularity at the forefront

305
00:16:42,820 --> 00:16:45,540
because as I do that,

306
00:16:45,540 --> 00:16:48,100
I can start writing things right away.

307
00:16:48,100 --> 00:16:51,580
And if I start writing parts of it right away,

308
00:16:51,580 --> 00:16:56,060
I can deliver in an agile way.

309
00:16:56,060 --> 00:16:58,300
I can deliver in pieces, you know what I mean?

310
00:16:58,300 --> 00:17:00,540
You don't have to wait until the system is 100%

311
00:17:00,540 --> 00:17:03,620
and deliver it.

312
00:17:03,620 --> 00:17:06,820
The essence of agile itself means you're constantly going back

313
00:17:06,820 --> 00:17:10,580
and changing and refactoring and stuff like that,

314
00:17:10,580 --> 00:17:12,500
both from a development perspective,

315
00:17:12,500 --> 00:17:13,980
a business perspective.

316
00:17:13,980 --> 00:17:20,060
So I don't, I think that deliveries and dates

317
00:17:20,060 --> 00:17:25,140
are much better managed when things are broken apart

318
00:17:25,140 --> 00:17:27,780
into stages, stages of delivery,

319
00:17:27,780 --> 00:17:29,500
just like we have stages of development.

320
00:17:30,500 --> 00:17:33,500
You know, in your case, you said you work on

321
00:17:33,500 --> 00:17:36,340
minimum viable products first, right?

322
00:17:36,340 --> 00:17:38,740
That's the way you attack the product.

323
00:17:38,740 --> 00:17:39,580
That's fine.

324
00:17:39,580 --> 00:17:43,980
That to me is more of a proof of concept than anything else.

325
00:17:43,980 --> 00:17:48,980
I don't, and I don't like to take a proof of concept product

326
00:17:48,980 --> 00:17:52,700
or delivery and turn it into the product.

327
00:17:52,700 --> 00:17:54,620
I literally keep that as a proof of concept.

328
00:17:54,620 --> 00:17:57,660
It's a very quick and dirty thing that I would put together

329
00:17:57,660 --> 00:18:00,980
just to show the technologies and the functionalities

330
00:18:00,980 --> 00:18:03,260
that would be available in a full blown system.

331
00:18:03,260 --> 00:18:05,820
You understand what I mean?

332
00:18:05,820 --> 00:18:06,660
Yeah.

333
00:18:06,660 --> 00:18:07,900
It's dangerous.

334
00:18:07,900 --> 00:18:11,380
I mean, I'm not criticizing you in any way, of course.

335
00:18:11,380 --> 00:18:13,740
MVP, an MVP is definitely necessary.

336
00:18:13,740 --> 00:18:16,340
A minimum viable product is totally necessary

337
00:18:16,340 --> 00:18:18,980
in a lot of shots, like totally get that.

338
00:18:18,980 --> 00:18:20,740
But I do feel you got to be careful

339
00:18:20,740 --> 00:18:23,780
because I can't tell you how many times it's happened to me

340
00:18:23,780 --> 00:18:28,460
that I deliver an MVP or a POC, a proof of concept product.

341
00:18:28,460 --> 00:18:31,860
And the boss says, oh, well, that's very close to what we need.

342
00:18:31,860 --> 00:18:33,220
So that means you can get the rent done

343
00:18:33,220 --> 00:18:35,220
in just a couple of weeks, right?

344
00:18:35,220 --> 00:18:36,860
No, it doesn't work that way.

345
00:18:36,860 --> 00:18:39,500
This is literally just a proof of concept.

346
00:18:39,500 --> 00:18:40,940
It just happens to look really good.

347
00:18:40,940 --> 00:18:43,780
So, don't mistake it for a polished, finished product

348
00:18:43,780 --> 00:18:44,580
because it's not.

349
00:18:44,580 --> 00:18:48,060
I think especially in enterprise,

350
00:18:48,060 --> 00:18:50,060
and you have also other publics,

351
00:18:50,060 --> 00:18:51,620
like security and so on.

352
00:18:51,620 --> 00:18:53,140
Oh, God.

353
00:18:53,140 --> 00:18:55,460
And this is something you do.

354
00:18:55,460 --> 00:19:00,980
It's like I called like a click dummy.

355
00:19:00,980 --> 00:19:09,460
And yeah, the guys or the sea level or the day they don't understand

356
00:19:09,460 --> 00:19:13,460
what happened and why do is it looks so fine

357
00:19:13,460 --> 00:19:15,940
and do is a little bit of work.

358
00:19:15,940 --> 00:19:19,540
But yeah, there's a lot of other stuff you have to do.

359
00:19:19,540 --> 00:19:20,540
How so?

360
00:19:20,540 --> 00:19:24,700
Yeah, there's one of the biggest misconceptions.

361
00:19:24,700 --> 00:19:31,860
Yeah, the leadership have on software architecture.

362
00:19:31,860 --> 00:19:36,340
But what is the biggest misconceptions the developers

363
00:19:36,340 --> 00:19:41,460
have about software architecture from their perspective?

364
00:19:41,460 --> 00:19:45,540
The biggest misconceptions developers have about architecture?

365
00:19:45,540 --> 00:19:53,140
I'm not really sure, never given a question like that, any kind of thought.

366
00:19:53,140 --> 00:19:59,300
I mean, I'm inclined to immediately say every,

367
00:19:59,300 --> 00:20:01,780
it's going to be different for everybody.

368
00:20:01,780 --> 00:20:09,540
I mean, my personal one, I don't know if it's a misconception.

369
00:20:09,540 --> 00:20:14,060
I mean, I have a pretty good idea of what I want in an architecture,

370
00:20:14,060 --> 00:20:17,260
what I want to see.

371
00:20:17,260 --> 00:20:19,020
A lot of times, I just don't see that.

372
00:20:19,020 --> 00:20:23,700
So I'm not sure if I understand the root of the question

373
00:20:23,700 --> 00:20:25,940
or how to properly answer it.

374
00:20:25,940 --> 00:20:28,340
Yeah, then it's OK.

375
00:20:28,340 --> 00:20:37,060
I think a little bit about, yeah, I see, I have more to do with the leadership.

376
00:20:37,060 --> 00:20:42,900
And I understand what misconceptions they have.

377
00:20:42,900 --> 00:20:46,900
Yeah, so I think it's called also be possible to develop ourselves

378
00:20:46,900 --> 00:20:52,500
some, yeah, misconceptions about software architecture, but, yeah,

379
00:20:52,500 --> 00:20:55,980
were not that that is fine.

380
00:20:55,980 --> 00:20:59,420
Well, I think when you're, when your team of architects,

381
00:20:59,420 --> 00:21:04,580
or when your architects is completely disconnected from the developers,

382
00:21:04,580 --> 00:21:08,460
when it's not the same person, see, I'm used to doing all the work myself.

383
00:21:08,460 --> 00:21:11,660
I've been a one-man shop for a very, very long time.

384
00:21:11,660 --> 00:21:14,700
And I kind of like it that way.

385
00:21:14,700 --> 00:21:17,820
But I mean, I have worked on teams before.

386
00:21:17,820 --> 00:21:22,660
I've never worked on a team where the architecture is that separated

387
00:21:22,660 --> 00:21:26,780
from the development, enough to cause any kind of misconceptions.

388
00:21:26,780 --> 00:21:32,340
But I think I can see that happening if those two sides are very, very separated,

389
00:21:32,340 --> 00:21:36,900
because there's a lot of people that think that architecture is completely separated

390
00:21:36,900 --> 00:21:39,020
from the technology and it's not.

391
00:21:39,020 --> 00:21:43,500
It's decoupled from the technology quite a bit, but it's not entirely separated.

392
00:21:43,500 --> 00:21:48,380
And I think there can be a big disconnect when you've got a team of architects

393
00:21:48,380 --> 00:21:57,820
or an architect that designs something that the tech stack that is going to be used to write it

394
00:21:57,820 --> 00:22:01,580
may not be able to handle, you know what I mean?

395
00:22:01,580 --> 00:22:07,300
Or maybe the staff or the skill level of the development staff

396
00:22:07,300 --> 00:22:09,740
think that'd be able to handle.

397
00:22:09,740 --> 00:22:13,460
And I think that could introduce clashes and misconceptions and things like that.

398
00:22:13,460 --> 00:22:18,940
I think those two sides really need to stay in close communication as close as possible

399
00:22:18,940 --> 00:22:21,540
if they are not the same person.

400
00:22:21,540 --> 00:22:24,220
In my case, it's always been the same person.

401
00:22:24,220 --> 00:22:28,940
Or somebody that I've worked very, very closely with and continue will continue to work closely

402
00:22:28,940 --> 00:22:31,100
with on an ongoing basis.

403
00:22:31,100 --> 00:22:41,340
That communication line needs to be maintained open during the entire time.

404
00:22:41,340 --> 00:22:48,420
I have a look a little bit about your publications and your writings.

405
00:22:48,420 --> 00:22:53,020
And there's one topic also we have in the headline.

406
00:22:53,020 --> 00:22:56,900
It's extensive extensibility.

407
00:22:56,900 --> 00:23:05,220
Why has extensibility become, I say one of your favorite, architectural, the topics?

408
00:23:05,220 --> 00:23:09,300
Okay, so that's where the real, real nerd in me comes out, right?

409
00:23:09,300 --> 00:23:16,620
Because when I got started in .NET, this is obviously back in .NET 1.0.

410
00:23:16,620 --> 00:23:21,420
And I was fascinated by the way web forms worked.

411
00:23:21,420 --> 00:23:26,540
Now before that, I was doing classic ASP, classic ASP development using Microsoft Transaction

412
00:23:26,540 --> 00:23:28,900
Server as the object broker.

413
00:23:28,900 --> 00:23:33,220
And then of course, a lot of eb6 components in the background.

414
00:23:33,220 --> 00:23:38,740
And a classic ASP's got bbScript built into it or JavaScript built into it.

415
00:23:38,740 --> 00:23:44,420
And that's how you generate the HTML within it or make it as dynamic as we were able to

416
00:23:44,420 --> 00:23:46,420
make it back then.

417
00:23:46,420 --> 00:23:53,260
This was obviously before the days of XMLHTPP later to be known as Ajax.

418
00:23:53,260 --> 00:24:00,260
But when I got started in web forms, which was the web platform that ASP.NET offered at

419
00:24:00,260 --> 00:24:03,660
that time, the only one.

420
00:24:03,660 --> 00:24:10,780
I took to it with a lot of, I liked it, I liked it quite a bit.

421
00:24:10,780 --> 00:24:17,340
I took to the concept of writing web controls quite easily and I was fascinated by it.

422
00:24:17,340 --> 00:24:22,020
That became a topic that I did a lot of speaking about and a lot of writing about is writing

423
00:24:22,020 --> 00:24:23,820
custom web controls.

424
00:24:23,820 --> 00:24:31,620
And web controls are a point of extensibility because they're modular pieces of a web site

425
00:24:31,620 --> 00:24:33,820
or web page.

426
00:24:33,820 --> 00:24:38,060
Web controls don't have to be something as small as a text box and a label and a button.

427
00:24:38,060 --> 00:24:43,420
I was writing web controls that were full blown components, like little mini forms that

428
00:24:43,420 --> 00:24:47,780
can be plug and played into multiple different forms.

429
00:24:47,780 --> 00:24:51,300
And I found that fun, fascinating and fun.

430
00:24:51,300 --> 00:24:54,900
And then later came ASP.NET.

431
00:24:54,900 --> 00:24:56,660
NBC.

432
00:24:56,660 --> 00:25:02,620
And I was very curious as to how that was going to differ.

433
00:25:02,620 --> 00:25:04,700
And that was easy to learn.

434
00:25:04,700 --> 00:25:07,860
I was a seasoned programmer by then.

435
00:25:07,860 --> 00:25:15,300
I started researching and looking into exactly how that worked because it wrote on top of ASP.NET.

436
00:25:15,300 --> 00:25:16,300
Right?

437
00:25:16,300 --> 00:25:21,460
Now at that point, I got a very clear understanding that ASP.NET does not equal web forms.

438
00:25:21,460 --> 00:25:27,140
ASP.NET is the architecture and the framework on top of web forms.

439
00:25:27,140 --> 00:25:33,420
And when I started digging around and re-reversing engineering, a lot of the stuff in web forms and

440
00:25:33,420 --> 00:25:37,540
how web forms and NBC worked.

441
00:25:37,540 --> 00:25:47,400
It became very apparent that ASP.NET is the underlying architecture on both web forms and

442
00:25:47,400 --> 00:25:48,400
ASP.NET.

443
00:25:48,400 --> 00:25:50,440
I mean, I mean, I mean, I mean, NBC.

444
00:25:50,440 --> 00:25:59,300
So then I researched until case how exactly does ASP.NET take a request, a URL and turn it into

445
00:25:59,300 --> 00:26:02,540
the eventual output, which is just a bunch of HTML, right?

446
00:26:02,540 --> 00:26:06,700
There's a lot of things in the middle there.

447
00:26:06,700 --> 00:26:13,220
And that's where I learned the concept of a pipeline and plugging things into a pipeline.

448
00:26:13,220 --> 00:26:22,020
And in reverse engineering and reading and learning a lot about this stuff, I learned exactly

449
00:26:22,020 --> 00:26:31,940
how a request is step by step turned into a web page in web forms.

450
00:26:31,940 --> 00:26:40,820
And then I learned how that happens in NBC and all that happens on the same pipeline, on

451
00:26:40,820 --> 00:26:44,340
the same real railroad track, if you will, right?

452
00:26:44,340 --> 00:26:54,460
And all Microsoft did was unplug some of the parts that turn a request into from a web

453
00:26:54,460 --> 00:27:02,860
form into HTML and plug in other things to handle the request and turn it into a web page using

454
00:27:02,860 --> 00:27:05,780
an NBC kind of architecture.

455
00:27:05,780 --> 00:27:11,700
And that, lining out how that worked was one of the most fascinating and enlightening moments

456
00:27:11,700 --> 00:27:13,500
that I had.

457
00:27:13,500 --> 00:27:19,020
I learned how to write HTTP modules and HTTP handlers and all that kind of stuff.

458
00:27:19,020 --> 00:27:25,140
And it just fascinated me and I just really got into how would I apply this same kind of

459
00:27:25,140 --> 00:27:32,180
technique, the same kind of architecture to another system, to something I can, if I'm

460
00:27:32,180 --> 00:27:36,620
designing something for a client, for a customer, that was always doing consulting.

461
00:27:36,620 --> 00:27:39,020
And I got, that's how I got into it.

462
00:27:39,020 --> 00:27:45,340
And to this day, that's how I approach systems, you know, can I, maybe not literally a backbone

463
00:27:45,340 --> 00:27:51,540
like ASP.net, but a backbone and pipeline kind of, kind of mentality.

464
00:27:51,540 --> 00:27:55,900
How can I design the system where, you know, everything has to go from point A to point

465
00:27:55,900 --> 00:28:03,020
Z. So to get from point A to point Z, what, what steps do I take and can I make these steps

466
00:28:03,020 --> 00:28:09,280
where I can remove one and put in another one, change the way something works, looks or

467
00:28:09,280 --> 00:28:18,280
behaves later on. And that's a very broad description, but I think you make it the point, you

468
00:28:18,280 --> 00:28:19,280
know what I mean?

469
00:28:19,280 --> 00:28:25,960
Writing modular stuff like that were, were if a client, to me, it became incredibly important

470
00:28:25,960 --> 00:28:31,960
after a delivery because I saw a client like the system I delivered.

471
00:28:31,960 --> 00:28:34,480
They have no idea how things work behind the cutters, of course.

472
00:28:34,480 --> 00:28:35,480
They never do.

473
00:28:35,480 --> 00:28:37,120
But then they said, oh, this is very cool.

474
00:28:37,120 --> 00:28:40,960
But this little piece right here, can we change this to do this?

475
00:28:40,960 --> 00:28:44,920
And then I would turn around and have a change like that very, very quickly.

476
00:28:44,920 --> 00:28:47,040
And of course, they would be very happy.

477
00:28:47,040 --> 00:28:50,960
And the work was easier for me because it would literally be just unplugging one part that

478
00:28:50,960 --> 00:28:55,960
I did and putting in something else and not changing any of the underlying architecture

479
00:28:55,960 --> 00:29:00,760
or frameworks that orchestrates the entire thing.

480
00:29:00,760 --> 00:29:06,400
And that, you know, that turned into just a really love for designing the extensible software.

481
00:29:06,400 --> 00:29:12,240
And I got into different kinds of extensibility patterns in, in, I even, I did a plural side

482
00:29:12,240 --> 00:29:17,560
course on developing extensible software where I go over several different patterns and,

483
00:29:17,560 --> 00:29:19,200
and give examples in everything.

484
00:29:19,200 --> 00:29:23,800
And it just, it became a really cool way of writing systems because it not only was cool

485
00:29:23,800 --> 00:29:30,280
to deliver it and see the clients happy that I was able to deliver in minimal time and

486
00:29:30,280 --> 00:29:34,320
make changes in minimal time, but it was, it was rewarding for me.

487
00:29:34,320 --> 00:29:38,520
It actually bettered the way I write code and the way I architect it back to the clean code

488
00:29:38,520 --> 00:29:39,920
that you were talking about.

489
00:29:39,920 --> 00:29:45,120
I found myself writing cleaner code because now it was managing smaller parts of code.

490
00:29:45,120 --> 00:29:51,360
It's always easy to go clean when you're managing small, you know, and, and, and we'll just,

491
00:29:51,360 --> 00:29:54,120
it just, it just, I kept evolving, evolving from there.

492
00:29:54,120 --> 00:29:56,960
And that's just the way that I do things today.

493
00:29:56,960 --> 00:30:07,200
Yeah, this was, was really, really good, really good overview.

494
00:30:07,200 --> 00:30:13,200
When you have to, to, to, expand the ability designed to explain in simple words as I told

495
00:30:13,200 --> 00:30:19,160
you, 12 year old boy, or girl, how will you explain it?

496
00:30:19,160 --> 00:30:29,320
Oh, boy, yeah, that's like, that's like asking JTPT to, to, to, to, to write the, show me the,

497
00:30:29,320 --> 00:30:33,400
the US declaration of independence or five year old can understand it, right?

498
00:30:33,400 --> 00:30:35,760
Oh, no, but it took it to a good question.

499
00:30:35,760 --> 00:30:41,600
I never really thought about it like that because I'm used to talking to developers, not

500
00:30:41,600 --> 00:30:48,440
five year olds, but, but it's all, I mean, if I, if I, if I can change it, if I can introduce

501
00:30:48,440 --> 00:30:55,040
them to that world using analogies that they understand, I guess it would be building blocks.

502
00:30:55,040 --> 00:31:00,760
I give them building blocks, you know, build, build a castle out of these building blocks.

503
00:31:00,760 --> 00:31:02,600
They would build a castle for me.

504
00:31:02,600 --> 00:31:06,520
And then I say, well, I don't, I don't like the top, the tower of that castle because the

505
00:31:06,520 --> 00:31:08,480
princess can't come out of the window.

506
00:31:08,480 --> 00:31:11,520
Um, change that, change that, the top of that tower.

507
00:31:11,520 --> 00:31:14,240
Well, they don't got to rewrite the entire, redo the entire castle.

508
00:31:14,240 --> 00:31:19,000
They just got to take the tower off and put a different kind of tower on it.

509
00:31:19,000 --> 00:31:20,000
You know what I mean?

510
00:31:20,000 --> 00:31:21,000
Yeah.

511
00:31:21,000 --> 00:31:25,280
So that would be the best analogy I can give to, to a little, yeah.

512
00:31:25,280 --> 00:31:32,640
I, I, I, I love bricks and, uh, yeah, I understand the, uh, with my 12 year old mind.

513
00:31:32,640 --> 00:31:36,840
In my, I'm, I'm a, I'm a big, I'm a big Lego fan.

514
00:31:36,840 --> 00:31:38,120
I build a lot of Legos.

515
00:31:38,120 --> 00:31:40,480
So in my world, that would be the equivalent of Lego, right?

516
00:31:40,480 --> 00:31:43,400
I don't like the way this, the front of this building comes out.

517
00:31:43,400 --> 00:31:46,160
And I'm plugging and put something else on there.

518
00:31:46,160 --> 00:31:47,160
Yeah.

519
00:31:47,160 --> 00:31:48,160
Yeah.

520
00:31:48,160 --> 00:31:49,160
Yeah.

521
00:31:49,160 --> 00:31:52,640
Uh, Lego is also, uh, it's also a great topic.

522
00:31:52,640 --> 00:31:54,160
But, but yeah.

523
00:31:54,160 --> 00:31:55,840
Um, it'll get me started, man.

524
00:31:55,840 --> 00:31:57,160
I can talk about Legos all day.

525
00:31:57,160 --> 00:32:02,840
Guarantee that a woman will never talk to me again, of course.

526
00:32:02,840 --> 00:32:03,840
Yeah.

527
00:32:03,840 --> 00:32:04,840
Yeah.

528
00:32:04,840 --> 00:32:12,040
I have, by another, not, not Lego, but also bricks, uh, uh, uh, star destroyer for two

529
00:32:12,040 --> 00:32:17,640
weeks, my, my girlfriend also, not so willing to, to talk to me

530
00:32:17,640 --> 00:32:22,920
actually, um, if she's, we'll package with 20,000 bricks, but yeah.

531
00:32:22,920 --> 00:32:23,920
Yeah.

532
00:32:23,920 --> 00:32:24,920
Yeah.

533
00:32:24,920 --> 00:32:29,400
The, the, the, it's, uh, yeah, when you, when you get a nerd, you get a nerd.

534
00:32:29,400 --> 00:32:30,400
Yeah.

535
00:32:30,400 --> 00:32:38,640
Um, when, when, uh, shoulders develop a design for extension and, and

536
00:32:38,640 --> 00:32:47,800
they're also, uh, cases when they should do it not or they should yet.

537
00:32:47,800 --> 00:32:52,800
I, I understood when she developed a design for, uh, repeat that again.

538
00:32:52,800 --> 00:32:54,360
Wanna make sure I get what you call it?

539
00:32:54,360 --> 00:32:58,880
Well, when she, when she'll develop our design for extensions and when

540
00:32:58,880 --> 00:33:04,040
she, they shouldn't, when they don't do it.

541
00:33:04,040 --> 00:33:11,280
Um, I think that the size of the system is probably the best way to answer that

542
00:33:11,280 --> 00:33:12,280
question.

543
00:33:12,280 --> 00:33:17,640
You're not gonna, the more, the more the, the more time you spend on

544
00:33:17,640 --> 00:33:22,280
archord, when you design something for modularity and extensibility, it's gonna

545
00:33:22,280 --> 00:33:25,800
take a little more time and make no mistake about that.

546
00:33:25,800 --> 00:33:29,840
So if you want, if the system that you're eventually needing to deliver is

547
00:33:29,840 --> 00:33:35,120
very, very small, it's a quick and dirty application, you don't need to, it

548
00:33:35,120 --> 00:33:40,000
would be overengineering to, to go through through all the, all the, the,

549
00:33:40,000 --> 00:33:43,840
the thought, the thought process of how would I modularize this and make it

550
00:33:43,840 --> 00:33:44,840
extensible?

551
00:33:44,840 --> 00:33:47,600
Um, it's small enough where it'd be easy to maintain.

552
00:33:47,600 --> 00:33:52,480
I think the size of the system is very relevant as, as, as, as, as it's, as

553
00:33:52,480 --> 00:33:56,080
it's clear that what has to be delivered is a large scale system.

554
00:33:56,080 --> 00:34:01,040
Um, then, then it becomes more important and then, you know, the minute you

555
00:34:01,040 --> 00:34:06,160
ask yourself the questions, okay, where do you see this changing in the future or

556
00:34:06,160 --> 00:34:08,840
being enhanced in the future?

557
00:34:08,840 --> 00:34:13,680
If there are several answers to that question, that's a give away that we need to

558
00:34:13,680 --> 00:34:17,520
put some thought into making sure this is a well designed, extensible and

559
00:34:17,520 --> 00:34:19,040
modular system.

560
00:34:19,040 --> 00:34:25,040
Um, now you may not always get the honest answer to that question, because I'm sure

561
00:34:25,040 --> 00:34:31,040
a lot of developers out there having countered given a task by a boss and

562
00:34:31,040 --> 00:34:34,880
them saying, and if they ask, well, what about this case here?

563
00:34:34,880 --> 00:34:39,040
And then the answer is, I don't worry about that it only happens once a year.

564
00:34:39,040 --> 00:34:42,320
Well, to me, when something happens once a year, I got to count for it like if it

565
00:34:42,320 --> 00:34:43,360
happens every week.

566
00:34:43,360 --> 00:34:47,280
That's just the way I, I, I refuse to leave something out because it only

567
00:34:47,280 --> 00:34:50,160
happens once a year, because that once a year is going to be a pain in the

568
00:34:50,160 --> 00:34:55,120
ass when that comes back.

569
00:34:55,120 --> 00:34:58,080
And if there's a lot of those things like that, then, then the modular and

570
00:34:58,080 --> 00:35:02,160
extensible design needs to be considered as early in the game as possible.

571
00:35:02,160 --> 00:35:07,040
So it's very relevant to, it's very, it's very related to the size of the

572
00:35:07,040 --> 00:35:10,320
system that you're putting together.

573
00:35:10,320 --> 00:35:16,000
Or, or, let me add to that, or what is the, what is the potential of this system,

574
00:35:16,000 --> 00:35:19,760
which is now very small, is just a little application right now, where do you

575
00:35:19,760 --> 00:35:22,480
see these, what do you see this going in the future?

576
00:35:22,480 --> 00:35:26,480
And again, the honesty of the answer is going to be very relevant because most of

577
00:35:26,480 --> 00:35:29,440
the time, you're not going to get an honest answer from a, from a boss because

578
00:35:29,440 --> 00:35:31,280
they just wanted to live it quickly.

579
00:35:31,280 --> 00:35:34,640
But, you know, when they come back and say, or over that system, you designed

580
00:35:34,640 --> 00:35:39,760
six months ago, that little application, you know, the, the, the, the, the people

581
00:35:39,760 --> 00:35:42,720
that I gave to like it, they want to turn into this, this, and that.

582
00:35:42,720 --> 00:35:45,680
And now all of a sudden it just became something big.

583
00:35:45,680 --> 00:35:48,400
So those are the questions that, that, that I tend to ask.

584
00:35:48,400 --> 00:35:52,080
And like I said, I don't always get an honest response to it.

585
00:35:52,080 --> 00:35:55,840
Yeah. You say design patterns.

586
00:35:55,840 --> 00:36:04,320
So which design patterns do you really most and which patterns are, I say, overused?

587
00:36:04,320 --> 00:36:13,360
Overused. Well, as far as the, the first part of that question, the design patterns that,

588
00:36:13,360 --> 00:36:20,320
to me, in my design, in my type of, of development, most of the extensibility

589
00:36:20,320 --> 00:36:27,600
designs that I do all stem from a strategy pattern or something similar to the

590
00:36:27,600 --> 00:36:30,640
strategy pattern or something that is derived from it.

591
00:36:30,640 --> 00:36:36,240
To me, the strategy pattern is at the heart of embracing abstractions.

592
00:36:36,240 --> 00:36:39,760
The whole point of extensibility is to be able to plug one thing in and, and

593
00:36:39,760 --> 00:36:45,120
plug in another, plug in another one. And that kind of plug in mentality is only going

594
00:36:45,120 --> 00:36:49,840
to work if the backbone that you're plugging into is going to have the same

595
00:36:49,840 --> 00:36:54,400
interface, the same way of talking to an old component as it does to a new

596
00:36:54,400 --> 00:36:59,200
component. And that's abstraction. And that's at the heart of the strategy pattern.

597
00:36:59,200 --> 00:37:01,680
That's, to me, that's at the heart of extensibility.

598
00:37:01,680 --> 00:37:06,480
Everything from there can, everything can progress from there.

599
00:37:06,480 --> 00:37:11,200
There are other patterns like the chain of responsibility pattern, which is kind of at the, at the,

600
00:37:11,200 --> 00:37:17,600
the heart of that combined with strategy is at the heart of, of what I call the event,

601
00:37:17,600 --> 00:37:23,600
the external events pattern. A lot of people are probably questioning what the hell

602
00:37:23,600 --> 00:37:26,640
that I just mean by external events. Let me put it in a way that, that,

603
00:37:26,640 --> 00:37:42,880
that, that developers can't understand because it's a pattern that I actually love and I use quite a bit. It's not really one of the 23 golf patterns, but it's the exact same pattern that ASP.NET uses when it writes, when it gives you HTTP modules.

604
00:37:42,880 --> 00:37:56,560
So the pattern, for those of you listening, if you're familiar with IH-GDP module and how to write an HTTP module, that's pretty much at the heart of how ASP.NET turns a request.

605
00:37:56,560 --> 00:38:06,160
Into a series of a bunch of HTML, whether it's in web forms or whether it's in NBC or whether it's in API.

606
00:38:06,160 --> 00:38:15,680
You know, web, web API is the exact same pipeline as NBC and web forms. It starts with the request.

607
00:38:15,680 --> 00:38:19,280
The only difference is that it's delivering JSON data instead of HTML.

608
00:38:20,080 --> 00:38:35,040
So the different points on the railroad track are very different, but the interface behind the scenes is going to be the same. Well, you know, I can, I can turn, I can give you a mini, a mini ASP.NET framework example.

609
00:38:35,040 --> 00:38:50,000
I can, I can deliver a mini one. It would be useless because of course I'd be rewriting the re-reabending the wheel, but I can, I can do a mini one to show you how something like that would work by using the same pattern that Microsoft use, which is the HTTP module pattern.

610
00:38:50,000 --> 00:38:59,680
One of my favorite patterns. And I tend to use that quite a bit. The latest system that I just delivered to to my last customer, use that extensively.

611
00:38:59,680 --> 00:39:08,560
You know, if you wanted to write, if you wanted to write a plug-in for this system, here is the interface and the events.

612
00:39:08,560 --> 00:39:18,960
And these are the kind of, these are the events you can tap into. And I call it the external event pattern because the host, the backbone system is going to be.

613
00:39:19,760 --> 00:39:32,240
Checking for events subscriber and calling an event, but the writing of that event comes from a plug-in that you add later in a different assembly, not from hard wired.

614
00:39:32,240 --> 00:39:38,880
Very strongly coupled event. It's a very loosely coupled thing, which is why I tend to call it the external events.

615
00:39:38,880 --> 00:39:48,880
But that's that the, which, which that is a strategy pattern. Those are the main ones that I base things on.

616
00:39:49,280 --> 00:39:56,480
Everything is based on abstraction. When it comes to extensibility and plug-ins and modules, it's all based on abstraction.

617
00:39:56,480 --> 00:40:04,480
If you're not familiar, I mean, if you're not comfortable with the concept of abstraction, it's something that you need to get comfortable with.

618
00:40:04,480 --> 00:40:11,360
Anybody that has done developer dependency injection understands abstraction very well because it's at the root of that.

619
00:40:13,760 --> 00:40:28,720
Awesome. Yeah, we have a lot of buzzwords now, but can you a little bit, X, Barsport, what's the wrong word? But we have plug-ins, events, dependency injections and also interface.

620
00:40:28,720 --> 00:40:31,040
How did all this work together?

621
00:40:33,600 --> 00:40:47,680
Well, I mean, that'll depend on what you're putting together really. I mean, dependency injection is based on the whole concept of abstraction, which in the world of dot net abstractions mean interfaces.

622
00:40:47,680 --> 00:40:51,680
They mean interfaces and abstract classes too, but primarily interfaces.

623
00:40:51,680 --> 00:41:03,120
So that's how DI works together with interfaces. It's based on that. It's at its very root.

624
00:41:03,120 --> 00:41:21,200
Same thing with plug-ins. If I'm going to write a plug-in, I have to embrace the abstraction because my main system is going to be calling a plug-in and the whole idea of an extensible plug-in is that it doesn't know what that plug-in is going to do.

625
00:41:21,200 --> 00:41:32,080
It just knows what it has available to do. The method in the properties that it has available to it and what the implementation behind the scenes is, it has no idea.

626
00:41:33,040 --> 00:41:44,880
That's at the very heart of doing modularity and extensibility. I think I might have answered your question or might have gone off on a different tangent.

627
00:41:44,880 --> 00:41:47,680
You tell me, did I address that properly?

628
00:41:47,680 --> 00:41:51,520
Yeah, really, really good.

629
00:41:51,520 --> 00:42:05,520
I think a little bit about extensibility. Can you share an example where extensibility is safe and entry product?

630
00:42:05,520 --> 00:42:12,320
Yeah, let me see if I can think of a good one just recent.

631
00:42:12,320 --> 00:42:21,920
One that's fresh in my head from the last system that I did. Let's see.

632
00:42:21,920 --> 00:42:31,280
Okay, you mentioned, and my intro, you mentioned the transcriber system that I wrote. I wrote it just to do live transcriptions.

633
00:42:31,280 --> 00:42:36,000
Live transcriptions from phone calls in a call center.

634
00:42:36,000 --> 00:42:43,760
Literally, as the phone call is happening, they see the live transcription on the screen. We've all seen that on Zoom, Google Meet.

635
00:42:43,760 --> 00:42:46,800
They all have transcription, live transcription built into it.

636
00:42:46,800 --> 00:42:54,800
But I had to do it on a custom system because this client had their own UI, their own that they used to manage the call center.

637
00:42:54,800 --> 00:43:01,280
It wasn't using anybody else's UI that had built in transcription.

638
00:43:01,280 --> 00:43:07,040
I had to do this myself and this was before AI was even around, to be honest with you.

639
00:43:07,040 --> 00:43:12,640
I learned how to use Microsoft's cognitive services to do a transcription.

640
00:43:12,640 --> 00:43:16,080
I wrote a transcription system that worked beautifully.

641
00:43:16,080 --> 00:43:24,560
As it was used, let me correct that. As I was writing it, I tried to think ahead.

642
00:43:24,560 --> 00:43:28,560
Now, I went with this customer for 15 years, just one client.

643
00:43:28,560 --> 00:43:39,760
So I got to know them very, very, excuse me. I got to know them very well and was able to always anticipate what I think they may be asking for in the future.

644
00:43:39,760 --> 00:43:43,680
Which, you normally, a lot of people can't do that with short-term customers.

645
00:43:43,680 --> 00:43:48,880
But I was with them, including myself, but I was with them for long enough where I kind of knew how they think.

646
00:43:48,880 --> 00:43:57,120
And I was writing the system and a lot of things popped into my mind that as the transcription is coming through

647
00:43:57,120 --> 00:44:08,000
and the customer service agent is watching this happen and seeing the transcription between their customer and their own voice.

648
00:44:08,000 --> 00:44:15,280
I can see different things being asked for to make their job significantly simpler.

649
00:44:15,280 --> 00:44:24,560
The two that came to mind, the first one that came to mind is the ability to search the knowledge base, the company's knowledge base.

650
00:44:24,560 --> 00:44:32,800
And I knew that would eventually come up because in talking to some of the agents, they told me that that's actually one of the processes they use.

651
00:44:32,800 --> 00:44:39,040
As they're talking to a customer, they're on another monitor searching the knowledge base, the company knowledge base,

652
00:44:39,040 --> 00:44:44,000
to see if that customer's problem has come up in the past and is there an immediate solution.

653
00:44:44,000 --> 00:44:45,920
So that was one thing.

654
00:44:45,920 --> 00:44:53,520
Later on, when AI came into play, we got the ability to use CHGPT.

655
00:44:53,520 --> 00:44:56,080
And I learned how to use the CHGPT API.

656
00:44:56,080 --> 00:44:57,520
So think about it.

657
00:44:57,520 --> 00:45:01,600
You got two things now that can share the abstraction.

658
00:45:01,600 --> 00:45:04,480
So I think this is actually a pretty decent example.

659
00:45:04,480 --> 00:45:09,840
You got a conversation from a, you got two conversations, two streams.

660
00:45:09,840 --> 00:45:12,120
You got the agent and you got the customer, right?

661
00:45:12,120 --> 00:45:18,200
Now I'm only interested in the customer conversation for the purposes of the answer to your question.

662
00:45:18,200 --> 00:45:22,560
So I got the customer explaining things over the phone and I'm transcribing this.

663
00:45:22,560 --> 00:45:24,640
So I have this in writing.

664
00:45:24,640 --> 00:45:31,800
So I want to take this now and automatically send it somewhere for some kind of processing.

665
00:45:31,800 --> 00:45:35,920
Now think of, think of how abstract I just worded that.

666
00:45:35,920 --> 00:45:40,480
Okay. I want to send this transcript or would you send it to or whatever.

667
00:45:40,480 --> 00:45:44,240
Part of this transcript, I want to send it somewhere for processing.

668
00:45:44,240 --> 00:45:49,840
And I want to have results of that processing come back so the agent can see it on another monitor

669
00:45:49,840 --> 00:45:52,080
or somewhere else on the screen.

670
00:45:52,080 --> 00:46:01,200
Well, that very abstract description is what I took into consideration when I was designing

671
00:46:01,200 --> 00:46:04,240
and writing the transcription system.

672
00:46:04,240 --> 00:46:11,240
Because later, much later, I was able to, to, what I did is that I put in a hook, in

673
00:46:11,240 --> 00:46:18,080
extensibility terms, we say hooks, I put in a hook so that I can put a plug in at this

674
00:46:18,080 --> 00:46:19,080
point later.

675
00:46:19,080 --> 00:46:24,840
It's time that a, that a sentence or a couple of sentences came in on the customer stream.

676
00:46:24,840 --> 00:46:31,400
I would take the words of that sentence, the text and I would, I would very abstractly

677
00:46:31,400 --> 00:46:33,160
send that out somewhere.

678
00:46:33,160 --> 00:46:36,800
Now I didn't have any somewhere to send it out to, but that's what I was coding for.

679
00:46:36,800 --> 00:46:38,200
I'm in an abstract way.

680
00:46:38,200 --> 00:46:43,400
I'm sending that part of the conversation somewhere that later on, I'm going to plug what that

681
00:46:43,400 --> 00:46:44,840
somewhere is.

682
00:46:44,840 --> 00:46:48,360
And I delivered the transcription system and it worked very nicely.

683
00:46:48,360 --> 00:46:53,320
Sure, shit, the, can I say that?

684
00:46:53,320 --> 00:46:59,080
Sure as hell, the customer came back, that my boss came back with, you know, how do we get

685
00:46:59,080 --> 00:47:04,400
the, the, the, the FAQ, the frequently asked questions, the knowledge base involved in

686
00:47:04,400 --> 00:47:05,400
this.

687
00:47:05,400 --> 00:47:06,560
And I knew that was going to come up.

688
00:47:06,560 --> 00:47:11,440
So the first use that I had for that hook, that plug in point, that, that's all that hook

689
00:47:11,440 --> 00:47:16,920
is, is a plug in point, an extensibility point is I took those, that, that text that was

690
00:47:16,920 --> 00:47:22,960
coming little by little from the customer and I send it to the knowledge base and see what

691
00:47:22,960 --> 00:47:24,080
comes back.

692
00:47:24,080 --> 00:47:29,280
And if something came back, then I displayed it on the screen and the agent side, the customer

693
00:47:29,280 --> 00:47:35,840
service agent side, customer service representative, but the customer actually did not just the agent

694
00:47:35,840 --> 00:47:36,840
did.

695
00:47:36,840 --> 00:47:43,000
So the agent was able to read, it results from a knowledge base in real time as the customer

696
00:47:43,000 --> 00:47:51,800
was speaking to them because of a plug in point that I, that I set aside ahead of time so

697
00:47:51,800 --> 00:47:55,600
that I can use for the knowledge base search later on.

698
00:47:55,600 --> 00:48:04,320
Later, I modified, or I added another extensibility plug in where I would send the customer text

699
00:48:04,320 --> 00:48:08,440
to chat GP and turn it into a question of source and see what comes back.

700
00:48:08,440 --> 00:48:13,880
So that's, that's kind of a rough overview on, on how I am, how I did implement it, something

701
00:48:13,880 --> 00:48:18,160
like that into one of my systems, but it worked out really, really well.

702
00:48:18,160 --> 00:48:21,160
And you know, you put, you put a switch behind it, you can turn it off and on, right?

703
00:48:21,160 --> 00:48:26,640
So if, if the agent doesn't want to, doesn't want to, doesn't care about the knowledge base,

704
00:48:26,640 --> 00:48:29,920
they don't want, they don't want to see all this stuff come back.

705
00:48:29,920 --> 00:48:31,400
They just click it off.

706
00:48:31,400 --> 00:48:38,000
And now I'm no longer sending the text over, but I can turn it back on anytime.

707
00:48:38,000 --> 00:48:40,000
Does that make sense?

708
00:48:40,000 --> 00:48:46,200
Yeah, it's made it makes, it's a really, really good explaining.

709
00:48:46,200 --> 00:48:50,920
I want also a little bit talk about enterprise platforms.

710
00:48:50,920 --> 00:48:55,720
You are designing SDKs, communication platforms, automation systems.

711
00:48:55,720 --> 00:49:00,960
What, what do these projects begin?

712
00:49:00,960 --> 00:49:05,120
Where do the projects begin?

713
00:49:05,120 --> 00:49:09,000
Actually from a bad dream that the boss had.

714
00:49:09,000 --> 00:49:11,720
No, seriously, I mean, that's how it works, right?

715
00:49:11,720 --> 00:49:16,520
I can't tell you how many things I've done for my, my customer over the 15 years that I've

716
00:49:16,520 --> 00:49:21,320
been with them, where I get approached with, you know, hey, this occurred to me last night.

717
00:49:21,320 --> 00:49:23,720
I thought about doing this in the nest.

718
00:49:23,720 --> 00:49:26,760
I'm not sure how we can do this, but it would be very, very cool.

719
00:49:26,760 --> 00:49:29,040
So figure out a way to do it.

720
00:49:29,040 --> 00:49:31,200
And it was, it was a great job because of that.

721
00:49:31,200 --> 00:49:40,560
I was given a lot of freedom, a lot of leeway, but how to repeat the original question again.

722
00:49:40,560 --> 00:49:50,800
I want to make sure I, yeah, where do you start with or how do projects begin?

723
00:49:50,800 --> 00:49:58,960
This was my questions from, from that dreams from, from your, what, well, obviously the,

724
00:49:58,960 --> 00:50:01,680
the main question is, what exactly are you looking for?

725
00:50:01,680 --> 00:50:10,000
But the one that I always, I twist that question into what do you envision doing when this is done

726
00:50:10,000 --> 00:50:12,520
and delivered and working perfectly?

727
00:50:12,520 --> 00:50:14,520
What is your, what is your vision?

728
00:50:14,520 --> 00:50:21,240
You know, I, if, if the customer can tell me, I'd like to be able to come in and do this

729
00:50:21,240 --> 00:50:22,960
and have this return to me.

730
00:50:22,960 --> 00:50:25,800
And this is the ideal situation.

731
00:50:25,800 --> 00:50:30,240
That, that's, that's a primary thing because I dig deeper from that point.

732
00:50:30,240 --> 00:50:38,260
I don't like to, I don't like to start any kind of application design or architecture without

733
00:50:38,260 --> 00:50:46,760
knowing what the, the desired result from a customer's perspective is, because that can,

734
00:50:46,760 --> 00:50:49,200
that can lead to mistakes.

735
00:50:49,200 --> 00:50:57,360
The latest thing that I did for my, for my company was automate a series of manual accounting

736
00:50:57,360 --> 00:51:02,200
processes that would occur at 430 in the morning.

737
00:51:02,200 --> 00:51:04,160
And they were all done manually.

738
00:51:04,160 --> 00:51:10,840
And it would have to be done that early because it has to be done when bank information on

739
00:51:10,840 --> 00:51:16,000
credit cards and checks comes in and has to be done by a certain time.

740
00:51:16,000 --> 00:51:19,080
So that was the time that they would do it at 430 in the morning.

741
00:51:19,080 --> 00:51:22,200
And they were looking for a way to, to automate this.

742
00:51:22,200 --> 00:51:27,160
So I asked that question, what do you, you know, what do you envision in an ideal situation?

743
00:51:27,160 --> 00:51:29,320
What, what are you looking to happen?

744
00:51:29,320 --> 00:51:34,680
Obviously, the first answer was, we don't want to get up at 430 in the morning anymore.

745
00:51:34,680 --> 00:51:42,400
So now, okay, now let me, let me walk, walk me through what the manual process is.

746
00:51:42,400 --> 00:51:46,800
And that's actually very key when I design something, especially when I'm doing automation.

747
00:51:46,800 --> 00:51:51,960
Look me in detail as much as you can, what the manual process to doing this.

748
00:51:51,960 --> 00:51:55,320
So I can get a good understanding on how I'm going to automate it.

749
00:51:55,320 --> 00:52:02,000
If, if something can be done manually, more often than not, I can have it done automatically.

750
00:52:02,000 --> 00:52:06,360
It's, it's, I know, I know that's very vague and it's very broad.

751
00:52:06,360 --> 00:52:12,640
But that's at the end's essence of what I, what I ask when I'm getting ready to design

752
00:52:12,640 --> 00:52:14,320
a new project.

753
00:52:14,320 --> 00:52:19,280
What are you looking for? What is your ideal outcome of what you would like to see when

754
00:52:19,280 --> 00:52:20,280
all this is done?

755
00:52:20,280 --> 00:52:24,840
If this was done tomorrow, how do you envision yourself using it?

756
00:52:24,840 --> 00:52:29,000
And then now walk me through how do you do it now?

757
00:52:29,000 --> 00:52:35,400
Because that will allow me to isolate possible ways that you could be doing it better.

758
00:52:35,400 --> 00:52:39,840
Not to tell somebody how to do their job when it's outside the realm of computers, but,

759
00:52:39,840 --> 00:52:43,760
but it, it, it helps me understand things step by step.

760
00:52:43,760 --> 00:52:49,240
So then when I go into automating it, I know exactly what I'm getting into and what, what,

761
00:52:49,240 --> 00:52:51,920
what, what things I have to look for.

762
00:52:51,920 --> 00:52:56,120
You know, a good, a good analogy to this that's not in the world of, of.net.

763
00:52:56,120 --> 00:53:03,400
And, and I deal with this all the time is I, I have a Tesla and my Tesla here in the States

764
00:53:03,400 --> 00:53:05,160
were allowed to use full self drive.

765
00:53:05,160 --> 00:53:10,360
I know that you in Stockholm or not, which, which, you have no idea what you're missing

766
00:53:10,360 --> 00:53:12,600
then because you get, you get it.

767
00:53:12,600 --> 00:53:15,040
It's like, I have a chauffeur.

768
00:53:15,040 --> 00:53:16,840
Yeah, it's true.

769
00:53:16,840 --> 00:53:23,720
But, you know, you always, people that get into my car and they, and they, they, they get

770
00:53:23,720 --> 00:53:27,440
fascinated by how well this works and they ask me how it works.

771
00:53:27,440 --> 00:53:31,680
Now, I can't tell you exactly how full self drive works step by step, but I can, I can,

772
00:53:31,680 --> 00:53:34,280
I can generalize how I would approach it.

773
00:53:34,280 --> 00:53:38,560
Now, I'm in nowhere near qualified to write something like, like, a, like a, a, a, a, a, a,

774
00:53:38,560 --> 00:53:42,280
a full self drive for, for a vehicle that's going to go out on the road.

775
00:53:42,280 --> 00:53:47,000
But think about it when you're, when you're doing something when you're, when you're driving,

776
00:53:47,000 --> 00:53:54,360
you know, you got to get from here to there and what decision tree are you going to undertake?

777
00:53:54,360 --> 00:53:57,360
What decision point are you going to undertake to get from here to there?

778
00:53:57,360 --> 00:53:59,560
How, like, I just changed lanes.

779
00:53:59,560 --> 00:54:01,040
What made me change that lane?

780
00:54:01,040 --> 00:54:05,240
Well, I looked to my left and I noticed it was clear and it was clear up ahead of me

781
00:54:05,240 --> 00:54:06,560
so I changed left.

782
00:54:06,560 --> 00:54:08,400
Okay, right, that down.

783
00:54:08,400 --> 00:54:11,800
That's what an automated system is going to do.

784
00:54:11,800 --> 00:54:14,320
You know, I, that, that, I stopped at that red light.

785
00:54:14,320 --> 00:54:15,760
Why did I stop at that red light?

786
00:54:15,760 --> 00:54:19,640
Well, because I saw the light and it turned red and I stopped because I know that's the

787
00:54:19,640 --> 00:54:20,640
law.

788
00:54:20,640 --> 00:54:21,840
Well, I write that down.

789
00:54:21,840 --> 00:54:23,880
That's what my automation system is going to do.

790
00:54:23,880 --> 00:54:26,720
And that's in a very, very simplistic way.

791
00:54:26,720 --> 00:54:30,840
What a full self drive system like Tesla or Waymo or any of those are doing.

792
00:54:30,840 --> 00:54:36,600
They're making decisions, you know, based on the, the possible, the, based on what, what

793
00:54:36,600 --> 00:54:38,360
do they got to do to make that decision?

794
00:54:38,360 --> 00:54:43,680
You got to look around and see what's around and then take it from there step by step.

795
00:54:43,680 --> 00:54:48,600
Obviously, we look at one direction at a time where a car like mine looks at nine different

796
00:54:48,600 --> 00:54:49,600
directions at a time.

797
00:54:49,600 --> 00:54:51,720
So things are done much faster.

798
00:54:51,720 --> 00:54:56,040
But, but that, that kind of decision making, you know, what, what does, what will it take

799
00:54:56,040 --> 00:55:01,280
to get from A to Z in your system and your system or whatever?

800
00:55:01,280 --> 00:55:06,400
Give me as much detail as you can so that I can try to design at that point or duplicate

801
00:55:06,400 --> 00:55:09,440
from there in a more automated fashion.

802
00:55:09,440 --> 00:55:13,360
And that's, that's typically my approach to something.

803
00:55:13,360 --> 00:55:17,400
Some client like that, a lot of people do not, they're like, well, why do I got to spend

804
00:55:17,400 --> 00:55:18,400
this amount of time with you?

805
00:55:18,400 --> 00:55:19,960
That's what we hired you for.

806
00:55:19,960 --> 00:55:24,480
Well, no, you really want me to take this into my own hands and decide how you're going

807
00:55:24,480 --> 00:55:25,640
to do it.

808
00:55:25,640 --> 00:55:29,440
The whole point of you hiring me is that I want to do it the way you want, you know what

809
00:55:29,440 --> 00:55:30,440
I mean?

810
00:55:30,440 --> 00:55:35,320
I'll write it the way I want, but I want the outcome, the, the end game to be what you

811
00:55:35,320 --> 00:55:37,320
are looking for.

812
00:55:37,320 --> 00:55:40,400
Yeah, awesome.

813
00:55:40,400 --> 00:55:45,640
So for this, this was really, really, really great session.

814
00:55:45,640 --> 00:55:52,280
And I think we have to do another session because for another topics.

815
00:55:52,280 --> 00:55:54,920
This was really, really, I really enjoy it.

816
00:55:54,920 --> 00:55:59,280
And let's jump into the rapid fire round.

817
00:55:59,280 --> 00:56:03,040
I only give you short questions and you give a short answer.

818
00:56:03,040 --> 00:56:04,040
Okay.

819
00:56:04,040 --> 00:56:05,040
All right.

820
00:56:05,040 --> 00:56:09,720
I just want to make sure that everybody out there knows that I have no idea what you're

821
00:56:09,720 --> 00:56:11,720
going to say.

822
00:56:11,720 --> 00:56:15,560
No, no, however, you're going to completely, you're going to completely take me by surprise

823
00:56:15,560 --> 00:56:16,560
here.

824
00:56:16,560 --> 00:56:19,080
And I know I'm not going to like it, but go ahead.

825
00:56:19,080 --> 00:56:21,800
Rest or graph QL.

826
00:56:21,800 --> 00:56:23,320
Say that again.

827
00:56:23,320 --> 00:56:25,800
Rest or graph QL.

828
00:56:25,800 --> 00:56:29,640
I would say rest because I am not a graph QL person.

829
00:56:29,640 --> 00:56:32,040
I've had minimum exposure to graph QL.

830
00:56:32,040 --> 00:56:35,880
It's cool.

831
00:56:35,880 --> 00:56:38,720
I kind of bring back memories of the old O data days.

832
00:56:38,720 --> 00:56:41,920
Remember, O data.

833
00:56:41,920 --> 00:56:44,880
In rest, we have O data in Microsoft.

834
00:56:44,880 --> 00:56:49,800
Graph QL reminds me of that because you can do queering and everything right from a request.

835
00:56:49,800 --> 00:56:54,880
But I'm much more comfortable in standard rest.

836
00:56:54,880 --> 00:56:58,000
As most that net people are, I believe.

837
00:56:58,000 --> 00:57:02,600
The clean architecture or vertical slice.

838
00:57:02,600 --> 00:57:04,320
Say that again.

839
00:57:04,320 --> 00:57:06,880
Clean architecture or vertical slice.

840
00:57:06,880 --> 00:57:10,720
I don't think the two are mutually exclusive.

841
00:57:10,720 --> 00:57:14,320
I think a clean architecture can result in many vertical slices.

842
00:57:14,320 --> 00:57:15,320
Okay.

843
00:57:15,320 --> 00:57:19,880
As a function or containers.

844
00:57:19,880 --> 00:57:21,920
Functions or containers.

845
00:57:21,920 --> 00:57:24,920
Or you said as your functions.

846
00:57:24,920 --> 00:57:25,920
Yeah.

847
00:57:25,920 --> 00:57:27,640
I'll come to complete a different things though.

848
00:57:27,640 --> 00:57:30,920
I mean, containers can contain full blown apps.

849
00:57:30,920 --> 00:57:32,400
Azure functions are just that.

850
00:57:32,400 --> 00:57:40,360
They're smaller functions to do whether it's a job of a microservice or an even smaller job

851
00:57:40,360 --> 00:57:41,360
in that.

852
00:57:41,360 --> 00:57:48,960
A C# feature you call live about.

853
00:57:48,960 --> 00:57:53,880
A C# feature I cannot live without.

854
00:57:53,880 --> 00:58:00,200
I can't believe that I'm going to say this because I didn't feel this way at the beginning, but

855
00:58:00,200 --> 00:58:10,440
I've gotten very, very accustomed to making async code much easier because I used to be

856
00:58:10,440 --> 00:58:14,240
a big user of the begin and pattern in the old days.

857
00:58:14,240 --> 00:58:18,920
My very first magazine article was written about the begin and pattern.

858
00:58:18,920 --> 00:58:22,400
And of course, async await replaced all of that.

859
00:58:22,400 --> 00:58:26,880
And at first, I was trying to figure out, okay, is this being overused?

860
00:58:26,880 --> 00:58:28,720
Am I using it in the right place?

861
00:58:28,720 --> 00:58:33,120
And now most most things that I do are going to be a sync enabled in one way or another.

862
00:58:33,120 --> 00:58:37,520
So if I have to give you one answer, it would probably be that without getting it more

863
00:58:37,520 --> 00:58:40,520
quiet.

864
00:58:40,520 --> 00:58:41,520
Most underrated.

865
00:58:41,520 --> 00:58:43,520
That feature.

866
00:58:43,520 --> 00:58:44,520
Most underrated.

867
00:58:44,520 --> 00:58:45,520
Yeah.

868
00:58:45,520 --> 00:58:46,520
Most.

869
00:58:46,520 --> 00:58:47,520
Most of the read.

870
00:58:47,520 --> 00:58:58,240
And that feature extension methods.

871
00:58:58,240 --> 00:58:59,240
Okay.

872
00:58:59,240 --> 00:59:00,240
Tap source spaces.

873
00:59:00,240 --> 00:59:03,760
We'll see that again.

874
00:59:03,760 --> 00:59:06,520
Depths or spaces.

875
00:59:06,520 --> 00:59:07,520
What's the first word?

876
00:59:07,520 --> 00:59:08,520
I heard spaces.

877
00:59:08,520 --> 00:59:09,520
What's the word?

878
00:59:09,520 --> 00:59:11,720
Depths or spaces.

879
00:59:11,720 --> 00:59:12,720
Taps TPS.

880
00:59:12,720 --> 00:59:13,720
Yeah.

881
00:59:13,720 --> 00:59:16,800
I'm not sure I know what that is.

882
00:59:16,800 --> 00:59:18,800
Okay.

883
00:59:18,800 --> 00:59:21,480
That movie.

884
00:59:21,480 --> 00:59:24,480
What's your favorite drink when you're coding?

885
00:59:24,480 --> 00:59:25,960
My favorite what?

886
00:59:25,960 --> 00:59:30,160
Favorite drink when you're coding coffee and the drink.

887
00:59:30,160 --> 00:59:35,760
Actually, I have it right in front of me right now.

888
00:59:35,760 --> 00:59:42,960
The only soda I drink is, I don't drink anything with Asperatee in it.

889
00:59:42,960 --> 00:59:51,120
So I drink a diet soda from a company here in the states called Zavia, which is sweetened

890
00:59:51,120 --> 00:59:55,560
with a natural herb sweetened called Stavia.

891
00:59:55,560 --> 01:00:00,600
I don't know how popular that is overseas, but that's what I'm that in water to be honest

892
01:00:00,600 --> 01:00:01,600
with you.

893
01:00:01,600 --> 01:00:05,280
I'm a one cup of coffee per day person.

894
01:00:05,280 --> 01:00:06,880
I've never been a huge coffee drinker.

895
01:00:06,880 --> 01:00:10,400
I drink it because I have a physical addiction to caffeine and I'll get a headache if

896
01:00:10,400 --> 01:00:13,680
I don't have one cup a day.

897
01:00:13,680 --> 01:00:18,000
I coding yes or no.

898
01:00:18,000 --> 01:00:22,120
Now I'm going to say yes and I don't know how controversy that answer is going to be.

899
01:00:22,120 --> 01:00:23,880
Can I elaborate on that answer a little bit?

900
01:00:23,880 --> 01:00:25,840
Can you do more detail?

901
01:00:25,840 --> 01:00:33,000
So I was one of those that at the beginning was not really worried that AI is going to

902
01:00:33,000 --> 01:00:38,320
replace my job because I've been doing this for 40 years.

903
01:00:38,320 --> 01:00:41,880
But it's just gotten really, really good, really, really good.

904
01:00:41,880 --> 01:00:47,480
And I've now taken the stance that, you know, if you can't, if you can't beat it, join

905
01:00:47,480 --> 01:00:48,480
it, right?

906
01:00:48,480 --> 01:00:51,680
I don't fight with AI anymore, but I use it.

907
01:00:51,680 --> 01:00:53,280
I use it extensively.

908
01:00:53,280 --> 01:01:00,240
And I think that AI still can't fully design or architect the system based on client requirements

909
01:01:00,240 --> 01:01:03,560
of the way I could or the way a human can.

910
01:01:03,560 --> 01:01:08,360
But once you've got all that architecture, things that we spoke of during the last hour

911
01:01:08,360 --> 01:01:16,160
out of the way, doing the component part of it, the small pieces of it, I have no problem

912
01:01:16,160 --> 01:01:20,720
farming that out to AI just in the interest of getting it done quickly.

913
01:01:20,720 --> 01:01:27,080
I try to keep the, I try to keep the requests of AI that are going to be code oriented

914
01:01:27,080 --> 01:01:31,560
as small as possible because it maintain, it keeps things maintainable and it gives

915
01:01:31,560 --> 01:01:35,760
me less to check over because I still have to check a lot of stuff over.

916
01:01:35,760 --> 01:01:39,360
I find AI making a lot of mistakes here and there.

917
01:01:39,360 --> 01:01:41,480
So I still want to check it over.

918
01:01:41,480 --> 01:01:45,800
But if I can put components together quickly, I'm all for it.

919
01:01:45,800 --> 01:01:48,040
Who wouldn't be all for it?

920
01:01:48,040 --> 01:01:53,120
I think you'd be a fool to fight that and to do it yourself because once a client, once

921
01:01:53,120 --> 01:01:58,360
a customer or a company catch wind of the fact that I could have done this a lot faster,

922
01:01:58,360 --> 01:02:01,520
they're going to question why I took the slow route.

923
01:02:01,520 --> 01:02:03,640
And I don't want that to come into question.

924
01:02:03,640 --> 01:02:05,760
So I'm for it now.

925
01:02:05,760 --> 01:02:10,360
If it's done the right way, if it's used the right way, I am in favor of it.

926
01:02:10,360 --> 01:02:11,360
Awesome.

927
01:02:11,360 --> 01:02:17,200
Yeah, then I say, we go, thank you so much for joining me today.

928
01:02:17,200 --> 01:02:22,720
I think, yeah, I had so much more questions, but we are a little bit running out of time.

929
01:02:22,720 --> 01:02:31,460
But I think it was extreme good overview, especially once the topic about great architect

930
01:02:31,460 --> 01:02:33,460
architecture and accessibility.

931
01:02:33,460 --> 01:02:36,460
Access, it's not errors.

932
01:02:36,460 --> 01:02:38,300
It's so hot today.

933
01:02:38,300 --> 01:02:39,300
Yeah.

934
01:02:39,300 --> 01:02:47,060
So I would say thank you and all the, yeah, all the listeners find your links and info

935
01:02:47,060 --> 01:02:51,100
in the show notes and yeah, have a great day.

936
01:02:51,100 --> 01:02:55,500
Let me just give one last piece of information for those that are listening.

937
01:02:55,500 --> 01:03:00,480
I did a plural side course called Developing Extensible Software that I think of all the

938
01:03:00,480 --> 01:03:02,100
courses that I did.

939
01:03:02,100 --> 01:03:04,840
It's the one that is most relevant today.

940
01:03:04,840 --> 01:03:11,280
In the plural site in their infinite wisdom, and I use that very sarcastically, has retired

941
01:03:11,280 --> 01:03:12,280
the course.

942
01:03:12,280 --> 01:03:16,080
They've retired all my courses because they feel that they're dated.

943
01:03:16,080 --> 01:03:20,920
This particular course, I don't feel it's dated because it's architecture based.

944
01:03:20,920 --> 01:03:22,620
So how could it be dated?

945
01:03:22,620 --> 01:03:26,320
But even retired courses are still available on plural site.

946
01:03:26,320 --> 01:03:29,040
They just don't come up in the immediate list.

947
01:03:29,040 --> 01:03:33,460
But if anybody has a plural site subscription in the search my name, the course you're looking

948
01:03:33,460 --> 01:03:36,300
for is called Developing Extensible Software.

949
01:03:36,300 --> 01:03:37,700
And I think you'll find it quite enjoyable.

950
01:03:37,700 --> 01:03:39,760
It was a lot of fun to put together.

951
01:03:39,760 --> 01:03:44,040
And it will, it will give you a lot of details into the stuff that we've talked about today.

952
01:03:44,040 --> 01:03:45,040
Yeah.

953
01:03:45,040 --> 01:03:46,040
Awesome.

954
01:03:46,040 --> 01:03:47,040
Yeah.

955
01:03:47,040 --> 01:03:52,520
Then normally I give you the last words.

956
01:03:52,520 --> 01:03:55,320
Those are my last words, man.

957
01:03:55,320 --> 01:03:56,800
Thank you everybody for listening.

958
01:03:56,800 --> 01:03:57,800
Yeah.

959
01:03:57,800 --> 01:04:02,920
Thank you so much for spending your time with me and yeah, have a great rest day.

960
01:04:02,920 --> 01:04:03,920
Thank you.

961
01:04:03,920 --> 01:04:04,920
You got it.

962
01:04:04,920 --> 01:04:05,240
Bye.

963
01:04:05,240 --> 01:04:15,240
[BLANK_AUDIO]

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.

Miguel Castro

Software Engineer

Senior .NET Software Engineer specializing in application architecture and extensible software design. Proven success in designing scalable and extensible solutions that enhance developer productivity. Proficient on the Microsoft stack and
Microsoft Azure.

Provided consulting services to multiple companies concurrently over several years.

For the past 14 years I've been consulting with a client's R&D department and have been in charge of many special projects.

I am the problem-solving go-to guy. Products I designed and developed are a communications-agnostic platform to send and received information in any number of media (SMS, Email, Teams, etc.), a live voice transcriber that showed a current agent-to-customer conversation on their machine and also performed real-time KB or AI actions on it, an SDK handling all the interaction between the company's customer software and the cloud-centric call center provider API, and a full automation suite on the companies AR tasks that converted many manual processes into fully automated processes. There were many more projects over the years. If the company can dream it, it typically came to me.

Driving innovation and automation has been central to my professional career. I focus on creating scalable, extensible solutions that align with business needs. Collaborating with multiple teams, I deliver impactful results by applying my expertise to solve complex challenges and have had the privilege of collaborating with people from various backgrounds, teams, and areas of expertise,…Read More