Dec 07 2005

Features First

Category: Business, General, IT ThoughtsJeremy Wright @ 5:35 pm

A number of folk have been responding on their blogs that features and users are more important than infrastructure requirements. Some of these have felt I was espousing spending gobs of money on infrastructure up front, which I wasn’t.

Ian Holsman says it really well in one of his comments here, though:

the point I was trying to make is that you shouldn’t worry about scaling until you need to, and for some cases that is never.

The reasoning behind not worrying about scaling is that in a lot of cases people worry about the wrong things. They will spend hours getting that code tuned just so, and have it running in 10ms less time, only not to realize that the code is only run once a day.

the other reason is some features don’t work out, for example writing the mousetrap your marketing person thinks will have people beating down the path to your door. now isn’t better to get that mousetrap up first, and see if he is right (in a day) as opposed to writing it with scalability in mind, waiting a month only to find that it isn’t used? even if he is right, you will have been validated in the day, and can then proceed to write a scalable solution while people are using the feature on the site!

you should wait until the problem occurs, and then address scalability. i’m not saying ignore scalability, just to address it when it is about to become an issue, and concentrating on growth and income generation. I’m not saying not to worry about it, just not to implement it until it is needed.

I actually agree with him. I just dont’ want companies thinking they are scalable or spending months retooling their apps just because they werent’ thinking about things up front is all :)

One Response to “Features First”

  1. Dan Ciruli says:

    I definitely disagree with Ian. He seems to imply that writing software with scalability in mind will make it much more difficult to write in the first place, and that it’s fine to totally ignore scalability while you hammer out features.

    Frequently, scalability isn’t a more difficult design choice; it’s just a different design choice. I’m talking general things like you mentioned before–being smart about your database connections, or encapsulating certain bits of code in certain classes–not fine tune optimization, like Ian mentions.

    I’m not saying you should ignore features by any means–they’re important, too. But if you’re designing your software for a user base of 2, then you’re just not planning on succeeding. If you do end up succeeding, you could end up having to rewrite your entire code base (I’ve certainly seen it happen before).

    So make the right decisions early. Plan for success.