Posts Tagged ‘X Custom Development to ISV’

A Developer’s Uphill Journey From Custom Development to Software Vendor – Part 3

March 12, 2009 Leave a comment

Jonathan Cogley: From Custom Development to Software ISV

February 26th 2009 | Jonathan Cogley

We concluded the previous blog in this series by revealing how using a professional graphic designer to optimize the aesthetics of your software user interface benefits the overall output. This week, we conclude the series with two more characteristics that are essential to the overall success of your software:

Stability: Design for Multiple Environments

The smart ISV knows that user experience relies on stability. A failure during the initial few minutes can cause negative first impressions and the user may give up on the product. The user may have many different software configurations and settings, making stability and testing a more challenging exercise. The Thycotic team has already encountered an amazing range of issues, especially involving internationalization. For example, language settings on the database server and web server needed to be exactly the same.

“You have to support everyone!” noted David Astle, a Secret Server developer, upon realizing the endless combinations of software and settings that our audience use. Limiting the supported configuration by setting certain system requirements may seem like a smart way to reduce quality assurance time, but it doesn’t really work. Customers will often try your software in other environments and solicit help when problems arise. Ignoring such requests, which may indicate your customers’ preferred environments and configurations, can be dangerous. Our customers quickly requested support for installing the product in a hosted web environment – something we had considered but didn’t officially support. (A thread quickly emerged on our support forums to talk through the issues.) We have also had requests to support other database platforms for our product. This was something we anticipated, and we specifically designed our product to use generic SQL wherever possible to facilitate other database platforms.

There is still a huge cost associated with expanding your supported platform: install issues; environment quirks; multiplying your quality assurance test environments; and ultimately fielding more variation in support calls. This is definitely a balancing act and something you should probably defer until you have enough customer requests to justify the cost.

Quality Assurance

Tools also play a big role in controlling the adjustment to the software vendor world. Virtualization is a must for your quality assurance environment. This allows you to easily test your product on multiple support configurations and reset as needed. It is worth the investment in time to create multiple virtual environments to represent the main configurations that you anticipate your customer will use. Use a tool to create an automated test script or even a repeatable manual test script, and then simply run through the tests on all the configurations. This approach has been especially useful for ensuring quality during the product install process, which is heavily dependent on the environment and is a miserable place to fail on the customer. For our virtualization, we use VMWare software and have found the snapshot feature to be invaluable for rerunning our tests with different builds of our software.

Unit testing tools are even more essential in ensuring high quality in the builds making it to quality assurance. The ability to run an entire regression set of unit tests-a large suite of unit tests which allow you to determine if anything will break when you make a change-was beneficial when making big changes, such as adding support for Microsoft Access as a database platform in addition to Microsoft SQL Server. The same was true when we began supporting Microsoft .NET 2.0. The ability to easily test all of the system features in an automated manner while the product is still in development is a big time and money-saver.

Other standard software development tools, such as source control, issue tracking, automated builds and development productivity enhancement tools, were as useful in the ISV world as they had been in our custom development practice. A source control platform with solid support for branching is especially useful if you need to apply fixes to multiple versions of your software in the field. Branching lets you easily separate out your release versions from your mainline of development for your next product release.

In summary, these are the main differences we experienced between the development of custom software and packaged software:



Control of Requirements

Not usually

Often more than you might like

Attention to Detail

Functionality first and last!

Endless refinement

Number of Users



Operating Environments

Usually controlled

More than you can guess




Building a product can be a rewarding experience, even when the financial rewards won’t let you live happily ever after in Bermuda, but it poses a different set of challenges than those experienced when developing custom software. Think carefully about your strengths and how you might adapt your best practices before trying your hand at packaged software development

Jonathan Cogley is the founder and CEO of Thycotic Software. Test Driven Development (TDD) is the cornerstone of the Thycotic approach to software development and the company is committed to innovate TDD on the Microsoft .NET platform with new techniques and tools. Jonathan is an active member in the developer community and speaks regularly at various .NET User Groups, conferences and code camps across the US. Jonathan is recognized by Microsoft as an MVP for C# and has also been invited to join the select group of the ASPInsiders who have interactions with the product teams at Microsoft.