My team loved to ship fast and sink later | Hacker News Reader

My team loved to ship fast and sink later

rosesecurity.dev

10 pointsr0nan6 comments

I was in a startup where the go-to answer from the CEO was "anyway in 6 months everything will be completely different, now we need to take the fastest route and change later". Turns out years later, those bad design decisions were impossible to change (because the product had been built on top of them), and the whole thing was a big house of cards.

IMHO, the good "move fast" strategy (for a founder going for the startup-ponzi-scheme) is "move fast and sell the company ASAP". If your plan is to keep it, maybe you should care about it.

I completely disagree with idea of moving fast at any cost. There's a saying in the marines (I think, maybe navy)...

"slow is smooth, smooth is fast"

It's about first getting the basics right, so you go slow, which then allows you to perform smoothly, and when you perform smoothly you can then accelerate and move quickly. This applies to software development, in my experience. I think codebases have this quality of snowballing, and the snowball can either be good or bad. At first you add code quickly, which means that your snowball will be one of complexity later. If instead you slow down at the beginning and deal with complexity early, the snowball becomes productivity later.

This is hard to explain on non-technical terms though, and it's a hard sell for business and marketing oriented people, mostly because they can't immediately connect the dots to profit (understandably, but also it's just so obvious companies hit the same problems over and over again). The business value is indeed there, after you snowball into compounded productivity because you architected an application that scales smoothly.

> This is hard to explain on non-technical terms though, and it's a hard sell for business and marketing oriented people, mostly because they can't immediately connect the dots

I think managers are usually capable pf connecting the dots. I guess the problem is that for managerial roles it is very hard to distinguish between engineers who are slow because they are careful and methodical (thus enabling future growth) and engineers who are slow because they are bad or lazy or prone to bikeshedding (thus enabling nothing). Since the cost of error here is very high, they tend to err on the side of caution,and discourage slowness altogether.

The reason that's a problem is because of how most companies structure their engineering roles. Individual contributors are the bottom part of the metaphorical pyramid. IC engineers are meant to be managed because by definition the progression of the career is to move towards doing less code and managing projects and people... that means that you will not have high level contributors that you can trust because they're all doing more management work.

In other words companies don't see the value of highly experienced code contributors, because writing code is seen as the relatively easy part of the job, and the engineers who manage people are "force multipliers", etc. But in my opinion this is just a structure that enables the 'move fast' mentality, and the 'scale by adding people' mentality, both of which can be fine but the consequence is code that breaks, is unreliable, and hard to maintain.

That’s not what the saying means.

It means when you go slowly enough, you maintain control and get the outcome you want. This allows for the highest probability of getting it right the first time, and not wasting time on fixing screwups.

It has nothing to do with going fast later. It has to do with going as fast as you can while maintaining control (generally of your weapon).

I think that still makes sense in the context I'm using. Do things carefully when building software in the beginning so that you have less issues as it scales and then you are iterating very quickly because of the lack of issues.

Reply on news.ycombinator.com