When developing an application, we gather the requirements, we create the use case scenarios, we go through endless cycles for feature releases and we pat ourselves on the back when we meet the original requirements we set ourselves months or even years ago.  And with a bit of luck we keep the bug tracker at bay with regular updates.

But are we doing enough for our clients?

The unspoken requirements

Do all our clients want to utilise our application in the same way?  When you think about it, it might seem obvious at first to state that with the market research, the client workshops, the focus groups, the beta trials, that we know what our clients want.  And as developers we know the most efficient way for a user to get from point A to point B.  So obviously our clients all want to use our “perfect” application in the exact way our user stories say they will.

So what happens when the client wants to get to point C?  Do they come to us and ask us to re-write the user interface (UI) to allow them to do it, or do they keep quiet accepting the limitations and instead jump through hoops to go from A to B and B to C, whether it be through our application or via a client written solution.  If we really look deeply into it, we generally find that the latter is a much more likely in the real world.

Providing for the power users

Those clients that want to do more than our uses cases allow for aren’t bad, or wrong, or misunderstanding the value of our product.  Nor should they be seen as being outside our core strategy to provide for.  But providing a solution for their every whim would expend far too much time and resource to get approval.

But maybe a middleground can be met with both sides giving a bit in order to make our applications usable beyond the user stories in to ways in which we could have never imagined, becoming more valuable, increasing user satisfaction and ultimately improving the bottom line.

Power to the people!

So what (in my humble opinion) does this middleground look like?  Well it is based on the concept of open extensibility, which at its core involved providing Application Programmable Interface’s (API’s) as part of the core package.  We already do that, I hear your cry as you point at your JSON enabled web API and the associated documentation that goes with it.

The thing is that is a serialized version of those ever so rich objects that your program utilises which whilst your application has the capability to deserialize them for real use again, the humble power user is left with the shell of an object to pick scraps of data from.  The problem becomes much worse for thick client applications (rather than web apps).

Instead the real value comes when we provide these users with access to the rich object set that we as developers have access to ourselves, but without making our closed source application an open source free for all.

How are we solving this?

The majority of applications we work on are based on the .Net framework (primarily C# and VB.net), so wouldn’t it be great if there already existing a programming environment that was available that worked on the .Net framework?

There is, its called Microsoft PowerShell and is currently in its fifth generation.  Its roots hark back to the humble command prompt (command.exe and cmd.exe) of yesteryear but with Microsoft rebooting it based on something to rival bash in the linux world.  Microsoft themselves have gone to great lengths to make the majority of their core products able to be controlled from with a PowerShell environment, providing an administrator to control these products in a way that was all but impossible before.

But the real advantage of PowerShell is its extensibility, more impressive than just creating a script to solve a solution, is to create a reusable CmdLet (command-let) that can undertake the task at hand as well as any future task that right now we can’t even imagine.

Because it is based on the same .Net Framework you can easily expose your rich objects in a PowerShell CmdLet and allow a user to manipulate them in ways that you wouldn’t have even considered.  The concept of a pipeline means that filtering, grouping, batch processing and outputting can all take place both in a scripted manner or piece by piece in a user session.

But it goes beyond that, PowerShell supports easy ways to implement multithreading and remoting allowing a user the opportunity to create a process to utilise your application in a manner never considered before.

Perhaps once considered something on the fringes, this way of working will soon become a key principle in why customers stick with your product over your competitors.

For more information on how we can help you in situations like this please contact us for more details.