Startup Lesson Learned: Technology Doesn’t Matter

As a developer turned sales and marketing person with a couple of products and a software company boy do I agree with this post.

I have a friend that built and sold an online accounting app for £XX millions (yep, that's two x's there) a year or so ago. He originally created the app using classic ASP, as that was all he knew at the time. After a few years of growth they started to build a .Net version of the app but it never saw the light of day. Guess why? Because they were too busy growing the company and ultimately selling it. And this is exactly the right approach. I'm pretty sure with hindsight he wouldn't have bothered with the .Net version of the app.

It's way too easy to get bogged down in using <latest trendy frameworks>, <trendiest latest NoSQL> or some other technical bullshit that doesn't actually add value for your customers. I know because I've done it and wasted far too many hours of precious development time.

So now whenever I'm reviewing the list of cards in Trello for the next sprint on our app http://www.staffsquared.com I ask myself two very simple questions:

- Will this bug fix/change/new feature add new paying customers?

- Will this bug fix/change/new feature reduce our customer attrition

If it doesn't tick one of those two boxes, it doesn't go in.

Well, that depends. I completely agree that needlessly messing around with the cool-database-of-the-week was inadvisable and a waste of time.

But sometimes it's necessary to learn something new. I'm a rails dev who's recently started what is basically a multiplayer game, and which will require many simultaneous connections. I don't know if you know Rails, but it is basically the worst possible technology to use for such a requirement.

It would be ridiculous for me to commence work on a project knowing I was using the wrong tool for the job and that I'd have to rewrite completely if we ever went above 10 or so users. So I'm learning and using something else, and I think that's the right decision.

The trick is in being able to tell when to go with the tried and tested, and when to jump into the new tech. That comes from experience, and you've just gained some :)

There are two basic types of companies: (1) technology companies and (2) companies that use technology. There is a gray area of course but you are likely either one or the other. Most companies fall into category (2) so in general your technology is entirely focused on serving the needs of the business. Pick the best technologies to serve the business now and in the future. The "cool new stuff" might be a good fit to serve the business but mostly it's not.

You can't be innovative on the full stack. But you need to be innovative somewhere, otherwise your company will fail just like your predecessors (there are predecessors who failed in your space, right?)

Know what your USP is, and use technology to achieve that. Sometimes new technology lets you do things that simply wouldn't be possible otherwise (I spend a lot of my professional life cursing Spark, but the whole business is built on dealing with a volume of data that simply couldn't be processed without it). For other companies, the technology can be your "edge"; if it's a mature market with established competitors, being more willing to push the technological envelope could be the thing that lets you offer lower prices and higher quality; a couple of my previous employers have succeeded by doing exactly that, in relatively "boring" industries.

But if you've got an innovative, experimental business model, you probably don't need innovative, experimental technology as well (and vice versa). Know which parts of your business are the innovation, and which parts are commodity.

Technology does not really matter if you are not a technology company. Most so called tech startups are not really technology companies. A technology company is a company in which the most important added value is the solution to nontrivial technical problems. You are a technology company if you create video cards, VR headsets, rendering engines, game engines, machine translation or speech recognition engines, etc... (These are difficult markets, as the bar is usually very high.) You are not really a tech company if you create a web app that serves web pages from a database however important user need you serve or however successful you are. The problem comes when people want to be technically creative at solving problems which need other kind of creativity (usually business creativity).

He used a database he didn't know how to use, switched to another one he didn't know how to use because someone said it was better, then switched back to the first one, and then switched to another database. There's a problem here, but it isn't using new technology.

Reading this post, it seems like the technology did matter. Go with the mature option that is well know, rather than wasting time messing around with the latest hipster crap.

Sometimes that latest trendy framework actually is a much better approach. Wanna know how you can tell the difference? Experience.

I used React for the first time when I started building the first version of our MVP because I was familiar with and frustrated with every other front-end approach in Javascript. Angular and Ember were bulky and slow. jQuery and vanilla JS are god damned nightmares for complex interactive applications. Because I have been writing rich client applications in Javascript for the better part of a decade I could very easily assess the pros and cons of React and realize just how great of a tool it was. The same goes for why I use Browserify and why I still use Make (and not grunt or gulp, yuk) for my builds.

The database I went with? Postgres. Redis is the only NoSQL tool in my belt and I use it as basically a sophisticated caching layer, although now that Postgres has such great support for JSON documents I might be fine without it.

I know for sure that there will be new tools in the future. Most will be new versions of an old approach but implemented poorly. A few will be much better and will have a major increase in productivity.

I agree with part of his argument - if you're figuring out the direction of your product, it's more efficient to use whatever technology you're most versed in - you don't have the time to spare on learning new things and making all the mistakes associated with that.

We had a very similar experience with FeatureMap. Started off with RavenDB, got tired of all sorts of technical problems (migrations, map/reduce, transactions, deadlocks, ...), quickly rewrote the data layer to use good ol' Entity Framework + SQL Server, and voilà, all better now.

Looking back at this it seems clear now that the way we used RavenDB (it could have been any NoSQL database) was not optimal and that most of the problems we faced were a direct consequence of our naive/simplistic approach. From a personal/technical point of view I don't regret the experience and I now have plenty of ideas about how to better leverage NoSQL databases, but from the business/customer point of view it certainly costed us.

Technology does matter. It matters if you need it to achieve a certain feature (recurrent neural nets demand a certain level of technology, for example). Competing technologies, matter less. But every decision is debt forming. So future-ready tech is better.

Are you sure?

http://www.paulgraham.com/avg.html

Technology always matters.

Luckily you have already picked one of the best available: .NET ecosystem.

Also:

"And if you’re not building something completely new and patentable not a single of your (potential) investors will ever care about the latest fancy JavaScript framework, database, or programming language you’re using."

How about Unity3D? Not new, not patentable, but Mono and C# was an ideal choice. It mattered to them, it mattered to investors.

I would not discard choosing a "new" technology (term "new" gets a little ambiguous here), especially if it's been around for a few years and preliminary research into it shows promise in regards to my project. I've seen too many companies failing projects because of "When your only tool is a hammer, every problem looks like a nail" situation.

Fully agree.

This is why on many projects I am responsible for, the team has to provide a business value for the customer for new technology.

What it means in terms of $$$ for the customer to have the project adopt technology X.

If it improves the revenue then sure, if it is only for playing with new tech, then do it at home.

This is so true but isn't limited just to your technology stack. Marketing and sales are also prime candidates for chasing the latest shiny object...but the fundamentals are fundamental for a reason and what you know best should be your first avenue of attack.

Um, the takeaway I get from the post is that Technology DOES matter, and you should make sure it fits your requirements.

If anything, do not go for the latest/shiniest thing on the market, if you are unsure it provides solid advantages on more mature, proven solutions.

Try making your experiments smaller. Lower the cost of failure. Don't stop experimenting.

I mean, If you ignore the advances in engineering and computer research of the last half century and just go with something new, different and unproven because a friend told you so, can you really blame technology?

Technology can matter, if you know how to use it. From your story it seems you guys went in blindfolded and just decided upon the technology on a hunch. That is your fault, not the technology.

I disagree fully with his assertions. Technology stack will make or break a company.

You're going to have pick new technologies, changes are happening. Are you going to roll a one page app with just JQuery? Of course not. Are you going build a 100TB datawarehouse on top of mysql? Are you going to build your infrastructure off bare metal server? Even source control has changed. How many people still use SVN?

Most important takeway from the article is keep things simple. Picking a complex technology for a simple problem will cause you pain. Both in the development environment and also in production.

While broadly the OP is fully correct, actually the statement

> Technology Doesn’t Matter

is over stated.

First, to be more clear, we need to consider what we mean by technology: In the OP, an example is some software framework -- for that, sure, especially in the context of the OP, likely such technology "doesn't matter". Why? In terms from 100,000 feet up, we're still talking, say, Turing machine equivalent so that we should still be able to get the software written without some particular framework. And, following the OP where it recommended staying with the technology the team already knew, the new technology likely will not be much or any more effective, efficient, etc., at least in the short term, for the project at hand.

But, I believe that the OP is missing an important point, one that, in my opinion (IMO), your mileage may vary (YMMV), is too often missed:

First, for context, assume that the project is to solve a problem where a good solution will be quite valuable but apparently also quite challenging technically. Or, the nature of the challenge is, say, "How the heck is it even possible to do that?".

Second, let's focus on just the technical part of the solution, that is, on the challenge:

For this focus, let's have an example where the technology very much did matter.

Ike wanted some pictures. The U-2 reconnaissance airplane was too slow and too low, and, thus, too vulnerable to being shot down, and he needed a plane that would fly higher and faster, enough of both so that it would be much more difficult to shoot down.

So, flying at 80,000+ feet at Mach 3.0+ should suffice. And, by the way, need range 2000+ miles without refueling.

A challenge: Put two really large turbojet engines in an otherwise really small airplane and can get thrust enough for Mach 3.0+, but some aerodynamics says that at such speeds the air into the engine, as it slows down to subsonic speed as needed by the compressor stage, can get so hot it will cause major parts of the engine to overheat, i.e., burn out. There was at one time at least one MIG 25 pilot who could confirm this point.

Relevant technology:

(1) There was a unit of Pratt and Whitney in Florida that considered such jet engine problems and had a bright idea: At Mach 2.5+ or so, don't really need the turbojet compressor. Instead, treat the engine just as a ram jet. So, take the input air, let it bypass the usual compressor and turbine stages, let it enter at essentially the usual afterburner stage, add fuel, and go. Bright idea. And, yes, they made it work.

(2) At Mach 3.0+, even at 80,000 feet, the friction, etc., of the air gets the surface of the airplane hot. So, need, say, stainless steel or titanium. The MIG 25 used stainless steel.

Well, at Lockheed, Kelly Johnson considered the Pratt and Whitney engine and titanium and designed and built a few dozen of the the SR-71s; Ike got his pictures; and no SR-71 was lost to enemy action.

So, the engine and the titanium were technology that very much did "matter".

And there are more examples from the past, and there may be more examples in the future, that is, where technology very much does "matter".

Not all possibly relevant technology, even for software projects, is just software frameworks, etc. as considered in the OP.

I find this argument very uncompelling. This product sounds like it never exited mvp if sql server free was to be good enough. I'll agree that at small scale there are lots of potential technologies. But it also makes me wonder what was so challenging here that they felt they had to keep swapping around. I won't speculate here.

However I disagree with the premise. At scale this absolutely matters. Different databases have vastly different design goals or cap theorem attributes. You'd better pick the right on or it'll impact your customer xp.

People who've made bad technological choices and then claiming "technology doesn't matter" just because they fucked up are about as annoying as people who always want to use the latest new shiny toys.

You just made the wrong choices at the wrong time for the wrong reasons. Period.

That doesn't say fuck all about the next guy who may have perfectly good reasons to either choose the next new bleeding edge shiny or go with tried and proven old tech.

The final sentence is the worst advice possible. Never, ever stop experimenting. Just properly separate experimenting from building.

And please stop lecturing other people because you can't keep that shit apart.