Scratching at scale, Part I

All software starts with an itch.  Sometimes that itch is practical:  "How can I easily manipulate business data as rows and columns?"  Enter Lotus 1-2-3.  Other times, not so much:  "How can I meet and hang out with other Harvard students without actually having to leave my dorm room?"  Enter Facebook.

But when folks approach me to develop software for them, the practical-vs.-frivolous distinction isn't the one that matters.  Instead, the real question boils down to whether or not the software should be built for scalability.

In I/T terms, "scale" largely translates into, "How many users does this software have to support?"  The answer to that question drives decisions such as hardware and even language/platform.  But it also drives decisions at a more fundamental level than that--and not only on the I/T side of the team.

Software usage is kind of like a democracy--people can vote.  Sometimes votes come in the form of dollars.  But even with "free" software, people vote with their feet.  That also applies to software that's mandatory--for instance, time-sheet/expense apps. at the office.  And, just like political democracies, more users translate into various "tribes" pushing and pulling at how the software is ultimately used.  True, its use can be nominally mandatory.  But if it's poorly designed (or incomplete), it will be avoided, circumvented, hacked, abused, or misused whenever possible.  Anyone looking to it to provide an accurate insight into what's going on is screwed.  (Because we all know that false metrics are worse than no metrics, riiiiiiight???)

For someone with an itch looking to build a new (or just improved) back-scratcher, it's critical to understand that the features-to-user ratio does not stay constant as the number of users rises.  There will be inflection-points along the way, and they invariably tick upward.  To wit:

1. A revolutionary back-scratcher, The ItchEraser3000, is invented.
2. A few dozen are sent to the reigning "lifestyle" taste-makers.  A handful of reviews are written, largely glowing.
3. A surge of orders triggers a mad scramble to ship a few thousand out the door before the buzz dies down.
4. Uh-oh, several are returned for the money-back guarantee because the ItchEraser3000 was designed and tested exclusively by right-handers.
5. Thanks to small manufacturing runs and the miracle of computer-aided design, a version optimised for the left-handed is made available.
6. Targeted marketing (and cultivating some of the dissatisfied clientele) lands a mention on the SouthpawsUnited Facebook group.  
7. A scramble to find a manufacturer capable of larger batches ensues as the virtuous cycle of word-of-mouth grows sales, but life is generally good.
8. The cash-flow hit from the January sales slump is exacerbated as users with upper body mobility issues return the IE3000s purchased for them by family members.
9. The hit-and-miss process of developing an ergonomic version of both the left- and right-handed ItchEraser is costly, with no word-of-mouth payoff except kudos from one or two advocacy groups.
10. The ergonomic models have slow and fitful sales, resulting in a net loss.

Software product development is no different, really.   There's the Big Idea, which never really escapes its brushes with capital-R Reality unmodified...assuming, of course, that it survives at all.  All because rarely do two demographics itch in exactly the same place.

A veteran software developer will recognise this pattern, and help her/his clients understand the implications--at least from the standpoints of system complexity and maintainability--as each new demographic appears.  

Ultimately, though, it's up to the client to understand (even if they might not actually anticipate) the afore-mentioned "inflection points," in the adoption curve, and the risks/rewards of pursuing them.  Unless the software being developed is extremely narrow in focus (and its user-base is small), dealing with those inflections requires a bit of mental gymnastics.   That's another blog post for another time.  Barring unforeseen complications, that time will be Wednesday.