Coding With David

 Agentic coding, where AI-driven agents autonomously write, test, debug, and refactor code, represents a significant shift that could substantially impact traditional Scrum practices. Far from a distant possibility, agentic coding is already being demonstrated today. For instance, GitHub Copilot can manage entire coding workflows autonomously: Create a dedicated branch. Analyze the existing codebase and the reported issue. Develop and apply a solution. Test the solution comprehensively. Generate new unit tests. Execute all unit tests. Create a Pull Request (PR). Validate the implemented fix. Assign the PR back to a human reviewer. For developers, this represents a significant shift. For software managers, it introduces both substantial opportunities and challenges. Scrum processes, in particular, will experience significant adaptation as AI becomes integral to software development. Impacts of Agentic Coding on Scrum Practices: Scrum Framework Impact ...

  Introduction As a senior C# developer and solution architect, I've explored numerous architectural patterns throughout my career. Today, I want to share insights on a pattern that has fundamentally transformed how I structure Blazor applications: Vertical Slice Architecture (VSA). Traditional layered architectures organize code according to technical concerns—controllers, services, repositories, models. This approach has served us well for decades, but as applications grow in complexity, this horizontal organization can create significant cognitive overhead. Enter Vertical Slice Architecture—an approach that organizes code around features rather than technical layers. The Problem with Traditional Layered Architecture Most of us are familiar with the standard n-tier approach: YourApp/ ├── Controllers/ ├── Services/ ├── Repositories/ ├── Models/ └── ViewModels/ While this organization seems logical at first glance, it creates several challenges: Feature Fragmentation : Work...

As ASP.NET Core applications grow, the list of registered services in your Program.cs or Startup.cs file can quickly become unwieldy. A mature enterprise application might easily have dozens or even hundreds of service registrations, making the code difficult to maintain and understand. The Problem: Service Registration Bloat Consider this common scenario in many enterprise applications: You open your Program.cs file and see a wall of service registrations that looks something like this: builder.Services.AddScoped<IAnalyticsService, AnalyticsService>(); builder.Services.AddScoped<ICacheService, CacheService>(); builder.Services.AddScoped<IDashboardService, DashboardService>(); builder.Services.AddScoped<ReportingService>(); builder.Services.AddScoped<IReportingService, ReportingService>(); // ... 30+ more service registrations This approach has several problems: Poor readability and maintainability Difficult to understand which services belong togethe...

  Introduction When building enterprise applications in C#, efficiently managing data access is crucial for maintainability and performance. As applications grow, coordinating multiple repositories becomes increasingly complex. The Unit of Work pattern offers an elegant solution to this challenge, allowing you to simplify your service layer while maintaining a clean separation of concerns. In this post, I'll show you how to implement the Unit of Work pattern in a .NET application to coordinate multiple generic repositories. The Problem: Repository Proliferation Imagine you're working on an approval workflow system. You have several related entities: ApprovalRequest , ApprovalAction , and User . Following the repository pattern, you might create a separate repository for each: public interface IRepository<T> where T : class { Task<T> GetByIdAsync(object id); Task AddAsync(T entity); // Other CRUD operations } Your service might look like this: publ...

  If you've been working with Blazor applications for a while, you've likely encountered Razor files and C# classes that have accumulated numerous @using statements. As these applications grow in size and complexity, it's common to see components with 10 or more imports at the top of each file. This article explores best practices for organizing these statements to keep your codebase clean, maintainable, and efficient. The Challenge of Growing Using Statements As Blazor applications expand, the number of dependencies increases. Components begin to require additional namespaces for: Core framework functionality Component libraries Custom models and services Utility classes Third-party integrations Before you know it, the top third of your files is consumed by import statements, making the actual component code less immediately visible and maintainable. Three Approaches to Managing Using Statements C# and Blazor offer several mechanisms for organizing these imp...

  As Blazor continues to gain traction in the .NET ecosystem, one challenge that remains universal across web development is organizing CSS effectively. In this post, I'll share a structured approach to CSS organization in Blazor applications that promotes maintainability, reusability, and a clean separation of concerns. The Three-Tier CSS Architecture After working on numerous enterprise-scale Blazor applications, I've found that a "three-tier" CSS architecture works exceptionally well: Global CSS - Core design system elements Page-specific CSS - Layout and page-specific overrides Component-specific CSS - Isolated styles for reusable components Let's break down each tier and explore how they work together. Global CSS: Your Design System Foundation Your main CSS file should form the foundation of your application's design system, containing: A limited color palette (6 colors maximum) A controlled font selection (3 fonts maximum) Utility clas...