Startup pivots - technology angle

This is what I've seen throughout my career as a typical [successful] startup lifecycle:

1. Build a product really fast - focus on experience, hopefully decent app code, basic persistence abstraction, monolithic database to keep things fast & simple.

2. If the product takes off, rapidly add features, variations for markets/segments, etc. Code grows more complex & tangled, resulting in greater brittleness and more bugs, database backend shows signs of strain.

3. Increase in number of users leads to business placing greater value on  availability and scalability, as well as performance, graceful degradation and similar matters.

Depending on the length of the the ramp up between stages 2 & 3, and the quality of tech design decisions at stage 1 despite pressure to get things out the door as fast as possible, techies at this point will be looking at a pile of technical debt sized somewhere between a molehill and a mountain.

What to do? Business still requires new features and capabilities to be added at the rapid clip. The more you build on the old without investing into refactoring or rewriting, the more the technical debt compounds (just like financial debt), increasing the tension between improving the internals vs the user-facing features.

Hopefully, as some money is now being made, reinvestment in improving technology platform is possible: break up the monolithic database (hopefully not too much logic is in the DB layer - stored procedures, etc.), try to break up increasingly tangled codebase, attempt to separate operations demanding synchronous, strong consistency guarantees from those that can be intermediated by async events. Words like SOA and EDA start to bounce around. If the business demands availability levels that require multiple datacenters, CAP theorem comes into play, eventual consistency strategies become critical, etc., etc.

In the meantime, some of the self-made components & modules may now have equivalent (or better) counterparts available as open-source or commercial software.

And it's at this point that investment in architecture, with focus on decomposition and encapsulation, as well as build/buy analysis unbiased by who wrote original in-house modules, becomes critical.

One often hears the term 'pivot' in startup parlance these days, usually referring to change in business model or product vision. I think the above illustrates that technology-wise, startups also have to execute one or more pivots to avoid being bound by the initial technical decisions that, just like business and product decisions, can rarely support the business forever.

Should we perhaps place greater emphasis on technology pivots? I think so.

iPhone as a platform

Following Apple's announcement of iPhones 5C and especially 5S, there's been much discussion about the merits of their various features and components.

Some have regretted that Apple didn't come out with any new 'whiz bang' features. Others questioned M7 motion co-processor in 5S or outright called it a gimmick.

I think such arguments reveal a superficial understanding of Apple's strategy. A few years back, everyone in the Internet industry couldn't stop talking about 'platforms'. Unsurprisingly, despite the hype, few companies actually figured out how to make money on their 'platform'.

Now, I think Apple has figured out how to both create a hardware+software platform AND make money on it - this is the entire iOS ecosystem.

So when Apple introduces new capability to its platform - whether it's 64-bit A7, or low-power-consumption M7 - it's not about what those things do by themselves, it's what they enable millions of developers to do. That's what happened with adding accelerometer, compass and other capabilities in the past.

Finally, from my own experience with various apps that attempt to track your activity (like the number of steps you've made) throughout the day, they consume way too much power to run all the time, reducing battery life unacceptably. M7 should be an awesome soltuion for that. Also, most avid joggers I know use their iPhones as fitness trackers and media players in one and are thrilled about the prospect of not having to recharge their iPhones more often.

Code maintenance & oil changes

Efficient organizations are typically KPI/metric-driven to a significant degree. Technology investments have to be translatable into business benefits, typically within 1 year horizon.

However, all code rots, with cruft and technical debt gradually accumulating within the codebase, necessitating refactoring and other maintenance that is bound to consume time and scarce resources. How can one demonstrate the necessity of such investment against competing priorities?

An analogy that comes to mind is engine oil changes. We spend time and money on them even though there's no direct, near-term proof that they are necessary. We essentially believe in their necessity because the experts tell us so. If we wait until the car starts showing signs of trouble, then it is probably too late and the repair will be far more expensive than an oil change.

So while managing technical debt is important, it is difficult to attach metrics to it that reliably demonstrate near-term benefits to business. Allocation of sufficient resources for it is then essentially a matter of trust between business and technology organizations.