Hacker News Reader

Comment by ethanwillis | Hacker News Reader

faster, faster, faster. Everything is about speed. When will things be about quality?

> faster, faster, faster. Everything is about speed. When will things be about quality?

Ironically, quality is the enemy of a startup. You can only do quality once you've got Product Market Fit (very very subjective thing, i understand). The analogy is building a quality, beautiful hotel on Antarctica - it's effectively useless and no one will pay you money you need for it to survive.

Oversimplification is, test, test, test until something sticks. Once something sticks optimize it with quality.

So initially, yes, you need faster, faster, faster.

I view your analogy completely different. There is a set of problems that require excellence from the start. No one will go to your hotel in Antarctica if it’s built like a shack house and they don’t feel safe there! If you can’t achieve that kind of quality don’t even bother trying to build it.

Quality can be much better with these kinds of templates and frameworks, because the creators can make better default choices, and generally can be aware of more corner cases, compatibility goals, integration testing, and the like.

For example, Avo (https://avohq.io) and Bullet Train (https://bullettrain.co/) are IMHO higher quality than what a typical intermediate developer could accomplish in weeks of full time learning and coding.

Not even sure these kits/frameworks make things faster.

If they pick just one wrong tech (that is not the best for your use case, e.g. an over complicated ORM) then they have wasted a bunch of your time.

This is so highly dependent on the individual developer or team that it is not applicable as blanket advice.

If you know you work faster without these, then fantastic - off to the races for you. But for every one of you I’ve met in my career, I’ve met 10 of the opposite.

It’s also just a classic line of premature optimization - you will likely rewrite big chunks as you grow and scale anyway, and the sooner you accept that and just focus on getting to market the better.

It is not that I am a genius 10xer though! It is more that the traps of using someone else's code and dead ends probably take up as much time as starting from nothing. The hybrid approach is what I really use: stick the starter kit in another repo, play with it, transplant the best bits to the project, leave the stuff you hate. There are more ways to configure a NodeJS app or even front end build than there are atoms in the universe, and some don't play well with each other, so you have to get down and dirty at some point.

I also agree this is the right way to use them. In cases where I didn't do this, I always ended up with some strange bit of the stack that I didn't use and didn't understand how it worked, and it caused some problems later. But copying and pasting relevant working bits into a new repo is a good learning exercise and also gets you going quickly.

> When will things be about quality?

When you’re not a start-up. (Obviously oversimplifying. But truer than not.)

When there are consequences for poor quality (security, negligence, reliability, efficiency, etc). When engineering standards are regulated. When quality meaningfully impacts revenue. Take your pick.

Reply on news.ycombinator.com