Top 10 tips for writing successful Software as a Service

jieforest

The case of the mysterious date translator
My colleague wrote a test case prior to coding a function that performed some date calculations and translations to display such phrases as "Last week" and "yesterday." After completing the test case, he coded the function and ran the unit test against it. Strangely, the method passed when it ran between 12:01 a.m. and 11:59 p.m. but mysteriously failed from noon to 11:59 a.m.
The big question here is, would this bug have been found if it weren't for consistent, repeatable, hourly testing? Would periodic manual testing have been able to catch it? Would the QA team have caught it? The truth of the matter is that this application could have very well been handed over to the customer with this bug still in place, potentially butchering a near 15-year relationship if the application went straight to production.


8. Tackle mountains, not molehills
The potential for performance bottlenecks is far greater with SaaS applications than with "thick" client applications that run from the desktop. Even veteran programmers will admit that when it comes to SaaS applications, sometimes performance bottlenecks are difficult to predict because of the number of variables involved. The difference between successful SaaS applications and those that fail is the way in which the development team responds to detrimental performance hits during load testing and profiling.
Generally speaking, there are only two types of performance optimizations: those that make a noticeable impact on performance and those that don't seem to have any noticeable results at all. Rarely is there anything in between. A common metaphor used in this regard is that of mountains and molehills. Nine times out of 10, developers spend the majority of time allocated to boosting performance, stomping on molehills rather than tackling gargantuan problems beating the life out of the computer's processor or memory while the application is running. The important thing to take away here is that as a programmer, you cannot see the mountain when you are too busy looking at the molehills.
The easiest way to prevent being distracted by the molehills is to profile your applications. Profiling is an important part of successful SaaS projects because it gives you the opportunity to optimize the way your application uses system resources, as shown in Figure 8. When you profile an application, you are able to see exactly which pieces of the application are taking up the most resources and implement design patterns for increased performance. For example, you may find it necessary to implement object pooling with proxies if you find a lot of object reinstantiation without the necessary garbage collection, which continuously eats up more memory for as long as you leave the application running.

Figure 8. Application profiling in Eclipse

jieforest

9. Learn from other successful SaaS projects
The simplest way to learn from other successful SaaS projects is to start by picking an SaaS program you already enjoy using. Then, find two or three competitors to the software that you picked and give them a whirl, writing down specific things that grab your attention and are related to why you do or do not like the respective application.
It is rare for an application to grab my attention with regard to usability and performance, so when it does happen, I make sure to take the time to find out why because I usually learn something from it. A task-management application grabbed my attention recently, mostly because I find this genre of applications rather dull. However, the level of usability involved with this particular SaaS application was striking.
I spent about two hours navigating the application, testing its limits and evaluating the accessibility of its multitude of features. I like applications that have an extraordinary amount of features built in, yet I expect them to still be fairly lightweight. For this reason, I am critical of UI design. If the interface is not well organized, an application with many features becomes a nightmare to use, because it's impossible to find what you are looking for half the time. My evaluation of this particular SaaS application led me to conclude that it was the unique and unconventional organization of the UI compared to other task-management applications I have installed that allowed me to enjoy working with it.

jieforest

10. Build usable prototypes
Is a prototype still a prototype if the same code used to build it is also used to create the final product?
The answer to this question is absolutely. In software development, the customer usually wants to see a proof of concept prior to investing in the development of the real thing. A prototype is nothing more than a proof of concept. Smart SaaS developers leverage the time they are provided for creating the prototype. Consider how much can be accomplished during this time:
Design and lay the architectural foundation.
Create the SaaS database schema by building a custom XML DTD, and use the XML as the prototype's data source. (The schema can be imported later into the database engine and converted to the real thing in a matter of minutes.)
Create the full-size application's organizational package, interface, and class structure, even if the files do nothing more than declare the class name and the interface it implements initially.
There are a number of advantages to this approach, but two are key to successful SaaS: You have a massive head start when the time comes to build the actual product, and conflicting design patterns and poorly designed architectures will usually show their ugly faces when the prototype is built on top of them. The necessary modifications can then be made before actual product development commences.

justforregister

nice job