Hacker News new | ask | show | jobs
by scarface74 2862 days ago
The one company that I worked for that did everything “right” - unit tests, paying down technical debt, code reviews, etc. was led by a manager who was originally the founder of the product that got acquired by what was then a Fortune 10 company.

After two years working on the new well tested, well written product, no one wanted the new .Net product, they stopped working on it and put everyone on the old PHP based product where there was a demand. Within 6 months after people’s vesting period elapsed, everyone (14+) developers left because no one wanted to do PHP.

Also, when he was a young hungry startup, he didn’t worry about “good practices”, but now that he was flush with cash and didn’t have to worry about going out of business, he could do things by the book.

I learned a few lessons over the years after that product and seeing how things really work - especially at smaller VC funded companies. No one cares about code quality, just growing features, acquiring customers, and the exit strategy.

It worked for Twitter....

2 comments

Most care about velocity, and doing work to support that is usually defensible.

You can keep velocity high on a badly run project for a couple years, but if your roadmap or business plan is long term, you will find that 5ings calcify before you’re ready for them. I always try to remind people that this is about the long term.

It’s also easier to grow and shrink a team when the code is Clean. But some of your coworkers won’t like the idea that they can be gotten rid of so easily. At the heart of its that’s the struggle. One or two experts on the system is enough to keep those people and their bosses fat and happy for quite a while.

Did the products do the same thing, or was the new product something entirely different that didn't have any market fit?

In other words, what's the lesson here? Speed at all costs because you quickly figure out if the product is wanted? Or speed at all costs because bugs just don't matter?

Without going into too much detail, the initial product was for the B2B market with buyers and sellers where the buyers could also be sellers. They had near total penetration on the seller’s side but they wanted to make a similar product that was buyer focused.

The lesson, for new markers that aren’t heavily regulated and the cost of bugs isn’t high (like healthcare and banking) is speed at all cost, and then once you have penetration, then start worrying about technical debt.

>The lesson, for new markers that aren’t heavily regulated and the cost of bugs isn’t high (like healthcare and banking) is speed at all cost, and then once you have penetration, then start worrying about technical debt.

Sounds like wisdom. I've been thinking along those lines myself.

I wonder what this means for correctness-focused languages (functional, with static and strong typing). Personally I'm a fan of these, but it could be that they're just not desirable in most industries. I'm assuming that these languages slow you down, but I hope they don't all do that.

Static and strong typing not only helps eliminate a whole class of bugs, there are also automated, guaranteed safe types of refactors that you can do with static, strongly typed languages.