Sometimes it's a tough sell. I work for a consulting company that I think would rate as very high quality. We try to bake it into contracts and sales pitches that we work a bit slower because we don't cut corners. This isn't always appreciated by a client who's rushing to market. If you think about the old project management triangle, it's scope, budget quality and you can only have 2 out of 3. If you have a contract with fixed scope and budget, it's quality that goes. Getting a client to sign a contract with flexible scope is not easy unless you have a ton of credibility.

I always use double accounting from finances to explain tests. You don't do logic changes in one places, but in a second to double check it actually works out.

The article and this subthread talks about "unit tests", but i think it's really functional or acceptance tests that would have been valuable in these cases. I think it's entirely reasonable for product owners to have some exposure to those.

No, they really should.

The American notion of "manager" is somebody who has ultimate power over the work. The American notion of "employee" is basically "minion"; they are supposed to do whatever they're told. You see it over and over on HN, and even in this thread: developers believe they are supposed to do whatever the boss/client says, even if they know that will lead to disaster.

With power goes responsibility, so if managers want to boss people around, they must understand unit tests and all the other sustainability-oriented development practices.

The alternative, which I would prefer, is that developers start acting like professionals. E.g., like doctors or structural engineers. Those people have codes of ethics and see themselves as having a professional duty. When people ask them for something that's dangerously bad, they say no.

But until that happens, managers really should learn how to manage the stuff they're claiming authority over.

> they don't understand and really they shouldn't have to.

They shouldn't have to because they'll listen to us and allow us to write and maintain tests as we develop, right?

"They're a way to check that nothing is broken" doesn't get through to them?

Why are they managing tech then?