OdeToCode IC Logo

Scalable software: a different angle

Sunday, February 22, 2004

Friday was one of those days when I didn’t get to sit at my desk till 2 in the afternoon. What was supposed to be a quick overview of upcoming requirements became an embroiled strategic planning meeting. I came out thinking: how scalable is our software?

I wasn’t thinking of scalability in the sense that Sam Gentile was recently thinking about scalability. I was thinking that given the architecture and feature set of our software, how many clients can our small startup support?

Since I am probably as clear as mud, let me give you a scenario without too many boring details. We built an ASP.NET Intranet application. The application uses Active Directory. By using AD we saved ourselves development time in building the administration areas of the application.

On Wednesday of this week, a prospective customer and his technical team call me. They don’t use AD and have no ready plans for migration. They are using NT4 and are not buying our software if it requires a move to Active Directory. Nevermind that the clock is ticking on NT4 support options.

One of our options at this point is to rip out code relying on Active Directory and build it ourselves. I don’t like this option one bit – it’s not a one time cost. There is an ongoing cost in maintenance, regression testing, deployment, end-user training, and support. It limits the ability of our company to scale up sales, because the cost per client just went up.

In a small startup company it’s difficult to approach the CEO and sales team and tell them why making a sale is a “bad thing”. The engineering team appears mean, nasty, inflexible, and unsympathetic to customer needs. Believe me, I am sympathetic to what the customer wants. One of the benefits of a small company is having hands on contact with the customer. When they get excited about something I’ve help to create I get excited too. When they want something new I want to build it for them, but I know a company has to live within it’s means.

If you build software that is difficult to install, and configure, and support, be prepared to make a living by billing time and materials. I’m sure there are application domains that have no other option, but just make sure you go in with the proper business plan. I try hard to resist customized features, or requirements that make the software more difficult. Unfortunately, in small companies it is very hard to resist cash.

Ironically, what helps in big companies can help even more in small companies where resources are tight and people wear different hats. The two biggest process related tips I can give are 1) Have a software development process in the first place, and, 2) automate ruthlessly. Use automated builds, and as much automated testing as possible. It takes more time up front, but pays dividends many times over as time goes on by leaving less to manual intervention, and therefore chance. It also keeps you scalable.