Sometimes, it’s not always obvious why SAPIEN’s development team does things the way they do. Sometimes, what seems to be the simplest features take forever to make it into PrimalScript – why is that? From the inside, it’s a lot more obvious, so I thought I’d take a moment to share some of those behind-the-scenes reasons.
Let’s take Windows PowerShell as a good example. Right now, there’s an impression by many of our users that PrimalScript doesn’t support the Exchange Server 2007 Management Shell capabilities. That’s actually not true; the EMS isn’t any different from PowerShell and PrimalScript supports it just fine – including integrated help, cmdlet PrimalSense, and more. Go to www.sapien.com/support.asp and search our Knowledge Base for “Exchange” and you’ll find an article describing how to get PrimalScript to “recognize” the Exchange cmdlets (hey, did you know we had a Knowledge Base?).
However, PrimalScript does lack a user interface telling it to “add in” the Exchange cmdlets, and it doesn’t automatically search for them and “add” them just because they’re installed on your system. Why? Well, if you do what that KB article says, you’ll notice that PrimalScript can become a bit slow to start up. That’s because it has to parse over 300 additional Exchange cmdlets for their syntax, so that it can provide PrimalSense and whatnot. It’s not a horribly long time, but it is sub-optimal, and so our development team needs to make it a bit smoother. Given that a lot of the delay comes from PowerShell itself, that’s not a simple task. So, before we start adding in Exchange, System Center, and other cmdlets willy-nilly, we want to make sure it’s an acceptable experience. In the meantime, if you don’t mind it being a bit slow to start up, the KB describes how you can get your Exchange cmdlets right now.
Here’s another example: We were informed by a user that the Evolved Script Packager has some issues running scripts under alternate credentials when those credentials come from another AD domain. Turns out the problem is in some of the underlying Windows APIs that the Packager calls upon. Needless to say, fixing Windows APIs is a bit out of scope for us – so we need to turn to a different technique. Fortunately, the dev team has about three ideas that should solve the problem – but before we can implement any of them in a service release, we need to test them. We have to make sure they don’t impact performance, that they work with domain and local accounts, and that they work on Win2000, WinXP, Win2003, and heaven help us, Vista, the king of weird security issues. That kind of testing – which involves setting up virtual test environments, multiple domains, etc – takes time. And since the first test is rarely successful, we have to keep plugging away at it. We’d honestly never considered this specific kind of cross-domain authentication before so it wasn’t something we’d explicitly tested, but it’s on the list, now.
And our dev team does keep plugging away. So when you run across something that seems like it should be “easy to add” or “easy to fix,” just bear in mind that, sometimes, it isn’t. Sometimes there are underlying technologies that we just can’t modify, and sometimes just “sticking a feature in” would create a really poor experience that nobody would like. So we try to take our time. Sure, we still make mistakes – we’re just people, after all – but we really feel that takig a little extra time to make sure something’s as right as possible is a huge benefit in the end.
