Thursday, January 7, 2010

Thoughts on navigating the SAAS sea-change

For mainstream programmers, the sea-change brought by the internet as we know it translates into trading in what was known as "DLL Hell" for the headaches of cross-browser compatibility. That trade-off is probably a net win--although, having entered this trade right at the point of cut-over, I don't consider myself entirely qualified to make that statement. But at least cross-browser compatibility is a problem that can be dealt with in purely technical terms.

But a more complicated ramification is the change from businesses transitioning from using software installed on their own servers to what's known as the Software as a Service (SAAS) model. As examples, Salesforce.com and a slew of 37Signals offerings jump to mind. In SAAS, the customer is effectively "renting" the service from the vendor. From the vendor's perspective, there's the comforting aspect of control over the environment in which the software operates. Naturally, the flip side of control is the responsibility to keep it up and running. But enough revenue can pretty much lock in as much uptime as you can stand, which in theory makes it a virtuous cycle. Again, merely a matter of technology.

Alas, that reckons without both Marketing and Management. Please understand that I'm not using either term pejoratively. Both functions can easily make or break an organization of any size. The point is that very rarely does either like to say "No" to paying customers or potentially lucrative accounts. Which is roughly when life for those who actually make the software becomes interesting.

I strongly suspect that this is another one of those things that they neglect to teach in Programmer School, but the upshot of having to be All Things To All Customers is that the process has to be actively managed. Hacking a straightforward application with IF-THENs and SELECT CASEs only goes so far--and that typically not for as long as expected. On the other end of the spectrum, resorting to over-complexity (e.g., automatically creating a new database table to link any other two tables that could possibly be related) is a poor reflex to develop. Like most things, the "solution"--a term that experience prompts me to use skeptically--almost always boils down to a balancing act. Living at either end of that spectrum is a prescription for misery...assuming that the market doesn't euthanize the company first.

That being said, one sign of a healthy organization is constant refactoring. Meaning programmers--preferably working in pairs or small teams--who aren't penalized for taking a step back to combine redundant functionality or for herding hard-coded exceptions into configuration files (or database lookups). Personally, I think the refactoring question is a excellent one to raise if you're interviewing an SAAS company--either as a potential developer or a potential customer.