Developers: How to Save Money and Release Faster with PowerShell

I use a fictional Volunteer Coordination System (VCS) in much of my work as an example.  It’s a small application based on the need to coordinate volunteers at conferences.  I was a volunteer coordinator for some large conferences, and while (I think) I was successful, it was a lot of manual work.

Hence the idea to provide some assistance with an application.  The goal of the application is to help volunteer coordinators to ensure adequate coverage of all the various requirements the conference managers have, and to help volunteers optimize their conference experience, between balancing their work requirements and their desire to attend sessions. 

The Short Version

Building a graphical user interface is more complex than building a PowerShell cmdlet.  If you build the System Administrator and User Administrator tasks as cmdlets, you save the effort required to build and test graphical user interfaces for those tasks.  Your PowerShell-friendly system administrators will love you for considering their perspective, and you’ve delivered faster because of the reduced effort on the project.

How do I know cmdlets are less expensive than graphical user interfaces?  You save time by avoiding most (but not all) user interaction design effort, and by reducing the test effort.  If you write your cmdlets using a test-driven development style, then you can promote all those automated tests that helped you work out the cmdlet interface as regression tests with minimal effort.  To do the same thing with a graphical user interface, you will need at least another tool to help with the automation, the tests will be harder to maintain, and on top of that, you will probably still need the expertise of an exploratory tester to give you feedback on the user experience.

How many functions could I divert to cmdlets? This will depend on the application target domain.  In the example below, 9 of 28 user tasks might be candidates for building as cmdlets.  This could mean that you’ve saved the effort required to build 9 screens, or more, depending on the desired user interaction. Seems worthy from my perspective.

What if I built cmdlets for all the functionality and then layered the graphical user interface on top of them as needed?  By Jove, I think you get the point.  That’s a great idea.  You’ve saved testing time since you can use simple PowerShell scripts to test all the domain functionality without the GUI (bypass testing).  This reduces the scope of the testing that occurs outside the GUI and helps you to respond to changes later on in the project.  And, it leaves you room to adapt to the user’s needs, just in case they decide later they need a GUI for one or more of their tasks.  In the meantime, you’ve deferred the development of that GUI to as late as is responsible (ideally).

The Long Version

Consider the functionality of this application based on a breakdown by user type (or persona).  Some of these have some business rules behind them, some of them are aspects of CRUD (create, read, update, delete).  Some of the functionality is required before the conference, some of it is required after the conference.

Conference Manager, focused more on the conference program than on logistics

  • Add Conference
  • Remove Conference
  • Add Conference Session
  • Remove Conference Session
  • Set Volunteer Work Requirement

Volunteer Coordinator, focused more on conference logistics than on the program

  • Add Volunteer Role
  • Remove Volunteer Role
  • Screen Applicant
  • Hire Volunteer
  • Drop Volunteer
  • Add Work Shift
  • Remove Work Shift
  • Check Coverage
  • Assess Volunteers Against Volunteer Work Requirement
  • Approve Work Shift Trade
  • Notify Volunteer
  • Broadcast Notify Volunteers

Applicant, will work for conference fee waiver

  • Apply for Volunteer Position
  • Accept Volunteer Position Offer

Volunteer, wants to maximize conference experience

  • View Volunteer Role Description
  • Sign Up for Work Shift
  • Block off Time to Attend Conference Session
  • Initiate Work Shift Trade
  • Accept Work Shift Trade
  • Decline Work Shift After Having Signed Up
  • View Personal Conference Schedule
  • Assess Self Against Volunteer Work Requirement
  • Notify Volunteer Coordinator

There might be more.  As a scope definition, that’s plenty of detail.  Certainly more than the goal description, so it’s a start.  Strong verbs, strong nouns, makes for a reasonable model of the desired functionality.  There’s some ambiguity since the business rules are not modeled, however, for the most part, it seems clear what the intended functionality is.

Solution Concept #1: All functionality is exposed via the web browser.

To build this solution, you first do a couple of architectural spikes to set the high-level design, and then, armed with the feedback you got from those spikes, you plan a number of releases and iterations that ultimately deliver the desired functionality.  For each of the above, the tasks would be something like, ordered in any which way you feel comfortable, but in any case, refactoring as you go:

  • Elaborate requirements by identifying acceptance tests
  • Create the user interface storyboard (say using balsamiq)
  • Verify and validate the user interface storyboard against usability, branding objectives
  • Automate acceptance tests (excluding GUI)
  • Automate selected acceptance tests for regression suite (including GUI)
  • Build the presentation layer (user interface objects and tests)
  • Build the business services layer (process and control objects, entities, and tests)
  • Build the data services layer (database and tests)
  • Verify and validate the functionality (exploratory testing using the GUI)

Of course, these are arbitrary.  Maybe your list is longer.  I’m also excluding the logistics around source code management and version control.

Solution Concept #2: User administration functionality is exposed via PowerShell cmdlets, remainder exposed via web browser

To build this solution, you would first make a decision whether or not the user task would be considered “administration”.  To make this decision, the greatest factors are the user persona, the frequency and timing of the usage of the functionality, and how well the functionality maps to a graphical user interface.

I posit that all the Conference Manager tasks are administrative.  They won’t be run very often, do not require a lot of information to be typed in, and are performed by a role that aligns pretty well with my definition of “administrator”.  That saves 5 web forms.

I posit that some of the Volunteer Coordinator tasks are administrative, and I would break it down based on when the task is most likely to be needed.  Everything that is typically run before the conference is administrative, everything typically run during the conference  is not.  That saves 4 web forms.

For the tasks that are exposed by graphical user interface, the development tasks from solution concept #1 would apply.  For those based on cmdlets, the development tasks are as follows:

  • Elaborate the requirements by identifying acceptance tests
  • Automate the acceptance tests by writing PowerShell scripts
  • Build the presentation layer (the command interface and snap-in)
  • Build the business services layer (process and control objects, entities, and tests)
  • Build the data services layer (database and tests)
  • Verify and validate the functionality (exploratory testing using the PowerShell console)

This feels like a simpler list of development tasks.  Depending on the target architecture, this could also mean one less programming language and one less third party library (for example, no javascript and no jQuery) for these functions.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s