[oraphalous]

Again - that's a business decision that needs to be made in the context of that business. The fact that testing was forbidden isn't in itself good or bad. It depends on that business context. THe post says nothing about how that decision was made, whether it was discussed, or if it was just his absolutist ideal he imposed without consideration of the broader cost-benefit.

And I still feel the original comment doesn't give this point enough weight.

[emil-lp]

Forbidding tests is not a business decision, it's a software engineering decision, and it's a remarkably poor one at that.

[oraphalous]

Hard disagree. It's both. Choosing one way or the other comes with potential risks and rewards to the business and it's up to business leadership to choose what risks they want to take. Your job as an engineer - if you are not part of leadership is to explain those risks / rewards, and then let them make the call.

[emil-lp]

Okay, yes, that's a hard disagree.

I have an education and experience in software development. If a manager told me to make a product in an unsafe manner, I'd refuse, and if push came to shove, leave.

Leave, both because I wouldn't be able to defend my work as a professional, but also because I wouldn't work under someone who would want to dictate the manner in which I do what I do.

[basket_horse]

This is missing the point. If you’re a 2 man team it’s much more important to have code that has a couple bugs in it but allows you to quickly find your product market fit. As opposed to perfect code with no bugs that is useless.

No one is disagreeing that tests are good in a vacuum / mature product. But if your focus is building a mvp, and you’re trading off the test time with other things, it’s not always worth it.

Screw “leadership” but consider for a second that you’re the leadership.