Hacker News Reader

Comment by nl | Hacker News Reader

I have a personal rule, which I've shared on here before and people seem to think has some merit:

If a project is innovative in a business sense, then choose a boring technology. If it is boring in a business sense, then choose an interesting technology.

View on HN

This is similar to Intel's Tick-Tock model, where they alternate between innovating on technology or innovating on architecture.

https://www-ssl.intel.com/content/www/us/en/silicon-innovati...

Ohh so you're the guy who's responsible for writing the BI data aggregator with React... ;)

woah there, he said _interesting_ technology!

BI Data aggregators aren't innovative? ;)

And if it's innovative in a technical sense, then choose innovative technology. If it's merely innovative in a business sense, then it doesn't matter what you choose.

> If it's merely innovative in a business sense, then it doesn't matter what you choose.

The point is focus. Pick one and innovate it extremely well.

This is actually close to the opposite of my rule.

Don't you think that in some cases the innovative technology is what enables the innovative business?

I hesitate to give examples because every time I call out something as innovative, people are going to say "Are you kidding? Alan Kay was doing that in the 1700s! Charles Babbage invented object oriented functional noSQL whatevers!"

That would be an exception to the rule, sure, but bear in mind that if you're trying to innovate in both technology and business at the same time, that's a bigger leap than just one or the other, so the risks are going to be higher and it will probably take longer to get right. In other words, by all means do a project like that - but don't try to do it on a tight schedule.

Can you flesh out the reasoning behind the rule?

Taking some risk has benefits in innovation if you can afford it, but the project shouldn't have two major unkowns that can wildly affect its result.

I'm going to tweet this. Upvoted.

In addition to that, parent's advice is also crucial for the team's motivation.

If the project is boring and you choose a boring tech stack to go, the team morale will only be harder to keep up as the time flies by.

This is probably the most important reason. Programmers love challenges. Keeping it interesting/challenging will also keep your good developers from looking for other jobs.

this is actually interesting advice. I never thought of it like this.

Thats a very good advice for a lot of valid reasons and I follow the same mantra.

Well, put. I am borrowing it.

Reply on news.ycombinator.com