Archive

Posts Tagged ‘Independent Software Vendor Challenges’

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:

Custom

Packaged

Control of Requirements

Not usually

Often more than you might like

Attention to Detail

Functionality first and last!

Endless refinement

Number of Users

Small

Huge

Operating Environments

Usually controlled

More than you can guess

Stability

Negotiable

Essential

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.

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

March 5, 2009 Leave a comment

Jonathan Cogley: From Custom Development to Software ISV

February 26th 2009 | Jonathan Cogley

We concluded our last blog post by posing a question about meeting customer requirements in an off-the-shelf software product:

So, how can we bring customers into the software development loop and meet their real world needs?

There are things you can do as an ISV (Independent Software Vendor) to bridge the gap between the development team generating requirements and somehow involving the customer.

You can come up with personas for typical users of your new software and categorize their likes, dislikes, favorite colors and even foodstuffs, but it is all fantasy until you have your first customers. Another option advocated by many vendors is an early access beta program; this helps to build a community around your product in the early stages and provides valuable feedback from people using your product. This option is still not ideal since the characteristics of a beta tester may not match the profile of your typical customer in six months time. At this point, the cynics are probably saying that this whole situation isn’t that different from custom development projects, since their user requirements can be poorly defined or championed too.

Our approach was to focus on the pain that our product solves. Secret Server is a web-based application to store passwords in an encrypted database and then securely share them with other team members (or your wife for that matter!) By delivering the core pain-relieving features, we would have a product that was genuinely useful and could then be refined and tuned based on customer feedback. This strategy put our product in our customers’ hands quickly, solved a few of their main problems, and began generating a stream of feedback to then drive requirements for the next phase. In fact, our tracking system actually prioritizes issues and features requested by our customers.

In our custom development, we always practiced what we call “just good enough.” This means giving the client just what they asked for in the shortest possible time while avoiding any over-engineering (read: technical guessing). This mentality was useful for our initial product development since we could easily have blue-skied the product into non-delivery. Focus on the pain your product solves and deliver it quickly to get early customer feedback.

Aesthetics Count!

First impressions count when the user has a choice about using your software. This impacts the aesthetics and the quality of the user experience. Gone are the developer-designed user interfaces, as they simply can’t compare to the work that a true graphics designer can produce in a few hours. The implications of this decision were huge for our development team. The developers knew that a qualified professional would beautify the interface later on, so they could ignore aesthetics and focus on the functionality and automated unit testing (test-driven development) of the software. I have seen developers spend hours tweaking a user interface on many custom development projects because no budget was available for a dedicated graphic designer. This costly exercise seldom produces remarkable results. The decision to use a professional early on benefited the overall output tremendously.

The user experience isn’t just pretty graphics, though, and the vendor should spend serious time refining the number of clicks to perform tasks, the information presented on the screen and the metaphors used in understanding the system. This difficult and time-consuming task can be justified, since the results will be spread over the many users who will try and, hopefully, use your software. Small gains in usability can yield large rewards when marketed to the masses; the economics of this attention to detail do not pan out when there are only a small number of users for your software.

Next week’s blog will explain how stability and virtualization play a vital role in quality assurance.


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.

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

February 26, 2009 Leave a comment

Jonathan Cogley: From Custom Development to Software ISV

February 26th 2009 | Jonathan Cogley

From Custom Development to Software Vendor: A Developer’s Perspective

Every software engineer dreams of the day when he can stop working on those awful Test Process Specification reports (the TPS reports made famous by Office Space) and build his ultimate product, sell millions of copies and live in the Bahamas-or at least a moderately priced condo in a major metropolitan city!

In the last quarter of 2005, Thycotic Software started on this journey.  The bulk of the company’s business was in a successful custom development consulting practice but the sights were set on building a base of product-driven revenue.  The logic leading to this decision was something like this: “We build great custom software for our clients; therefore we should be able to build a great product and sell it.”

The product veterans can stop laughing now. As we learned, there are many differences between these different worlds of software development.  Secret Server, our first off-the-shelf product, would teach us new things about building software: choosing features; support calls with the general public; and how to set new records for daily caffeine consumption.

What are the typical characteristics of custom development?

  • The software caters to a particular business need.
  • It’s time-sensitive due to a market opportunity, budget or fiscal cycle.
  • You have a limited set of users.
  • Users are frequently mandated to use the software.
  • Aesthetics are typically the lowest priority.
  • Stability is often negotiable as long as there is a workaround.
  • The deployment environment is well known and can often be controlled if necessary.

This is the typical world of the corporate developer-ugly applications with aggressive time lines, and very forgiving users.  How well do these traits relate to the world of the software vendor marketing to the public at large?  In many ways, they don’t.  Our team quickly started to notice the differences as the project got underway.

Figuring out the Customer Requirements

First, when requirements were unclear, we had no definitive customer who could give us input.  A large corporation might enlist focus groups of potential customers to understand wants and needs, but for a small team, this option is costly in both time and resources.  This forced us to generate the customer requirements internally, which basically meant guessing.

You have control of the requirements!” noted Bryant Smith, a Secret Server developer, when discussing the increased burden on the team to define the feature set. Some developers may feel empowered by this control but it is a dangerous game since the chosen features, their value, and their usability will determine your sales and ultimately the success or failure of the product.

How can we bring customers back into the loop to make these decisions easier and relevant to their real world needs?

Next week’s blog will answer this question, and reveal how aesthetics affects the quality of user experience.


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.