The road to extensibility
summary
Argues that extensibility has three concrete axes — functionality, target, protocol — and shows failures from real PowerShell tools: inventory scripts that balloon into monster modules, hundreds if not thousands of AD checks that break when Server 2025 adds functional level 10, and modules that accidentally expose destructive actions via poorly chosen names. Demonstrates remedies: prefer modules when you can, use dynamic parameters, enforce early and late dependency checks, emit consistent logs and HTML reports, trap and export errors, and split atomic functions for maintainable extension.
AI-written summary · about
chapters (14)
- 0:00Tool extensibility introduction
- 2:54Tools become unmaintainable
- 8:39Planning versus practical development
- 10:45Environmental changes break tools
- 14:42Packaging tools for others
- 18:46Naming pitfalls in tools
- 22:01Handling user input safely
- 26:05Dynamic parameters for usability
- 31:11Output design for extensibility
- 36:11Managing script dependencies
- 40:00Atomic functions for functionality
- 43:13Error handling for exceptions
- 45:44Splitting functionality for collaboration
- 46:05Ten questions before new tool
related talks
19mExtensibility as a Product
30mExtensible Python: Robustness Through Addition
46mFrom Script to Tool: Building Robust, Meaningful Tools with PowerShell
01h 37mMore Game Breaking PowerShell
52mPowerShell Module Design Rules (and When to Bend Them)
01h 45mWriting Award Winning PowerShell Functions and Script Modules
43mPowerShell Tooling
47mThe Human Side of PowerShell Scripting