It's built into the culture to ship, ship, ship. Shipped code is better than good code, or clean code, or fast code. At my last job, the C-level was fascinated by Amazon success stories. They wanted to achieve the same success, so they urged us to ship, ship, ship. Unfortunately, we were all very seasoned engineers, and we knew the nightmare that would ensue if we purposely piled on the tech debt. The part of this article that refers to "every ticket taking 4 to 5 days regardless of complexity" should be a warning sign to ANYONE attempting to model their startup after Amazon.

The message should be: You are not Amazon, and you will NOT get to Amazon scale by modeling their worst practices.

I think this culture is OK or even good to a company in start-up because you have to be quick. Once it grow into maturity those rules should be abandonned.

There are a few problems with that approach. One is that there is rarely a good time to say, "ok, we've proven that this idea works, let's now go back and do it correctly". It's a constant stream of fixes on a system that "already works". Secondly, telling management that a team was able to go fast previously, but is now going to start being slow so that things can be done correctly, is a quick way to be shown the door. This is evidenced by Amazon and that thousand line Java method that's probably existed for 10 years. Finding that time where you're mature enough to switch gears never seems to happen in practice.

I now advocate a "cut corners, cut scope, but do NOT cut quality" approach. Unit tests do not take much longer to write - but they pay dividends when it's time to refactor. I'm now back in a startup where the code was written with that "just ship it" attitude. The code is so terrible that it can take days to fix a bug. I can rewrite entire features (correctly) in that amount of time.

Shipping tech debt should be compared to the realistic alternative which is never shipping at all. The solution is not to ship slower, but to attract a better team and then retain them. They say the CEO's #1 job is recruiting and this is why. Actually more important is growing your revenue faster, if revenue compounds faster than debt then you're good!

I mean you can also ship a lil slower.

Startup founders and management types are obsessed with optimizing dev time at a day/hour granularity though in my personal experience, so it's a lost cause.

Can you really ship slower?

In the end it’s a winner takes all market, and AWS needs to out-innovate azure to win.

And as customers of AWS we’re all looking forward to the next re:invent for new features, and we’re voting with our money buying huge amounts of AWS services.

Also, as a potential employee, I would always sign with the company that has positive cashflow through customers that pay for shipped value, rather than a company with a great code base, but a bad sales track record.

> This is definitely not the worst as I know one of the leading options marketmaker has been using a giant shit mountain of MS Access/Excel VBA code to run their system since the 90s.

Only one? :)

Apparently it works though. Since both examples are described as "industry leads".