3 ms·

Good luck explaining the point of unit tests to technology illiterate managers - they don't understand and really they shouldn't have to.

myko 11y ago
> 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?
- rhizome31 11y ago
  My take on this is that automated tests is a developer tool and doesn't matter to them. As much as they shouldn't care which text editor we use, they shouldn't need to know that we write tests. In fact I tend to avoid as much as possible commits that only impact tests in case they would look at the SCM history and be tempted to blame tests for a delayed delivery (no "fixed the test suite" commit messages). Also I never explicitly count automated testing in my estimates, it's counted implicitly as part of normal development.
twic 11y ago
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.
andrewflnr 11y ago
"They're a way to check that nothing is broken" doesn't get through to them?
- sgift 11y ago
  Hopefully not, because it is completely wrong. They are a way to check that what you test is not broken, which is usually not even remotely the same as "nothing is broken". I have seen so many pieces of code that didn't work in the real world but had many unit tests, good test coverage and were therefore "high quality" - yeah, sure.
  - andrewflnr 11y ago
    Ok, fair point. It still seems like the potential benefit is pretty clear.
michaelmrose 11y ago
Why are they managing tech then?
zeisss 11y ago
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.
- rev_bird 11y ago
  Thank you for this -- it will be put to almost immediate use.
- rhizome31 11y ago
  Sounds good, if only I understood double accounting :-)
  - andrewflnr 11y ago
    The principle is simple. Basically your entire accounting log is always a balanced equation: sum(assets) = sum(liabilities) + sum(owner's equity). Every transaction gets recorded on both sides of this equation, so you can check for (certain kinds of) mistakes by adding up everything on both sides and seeing if it matches. This is a vast oversimplification, and possibly slightly wrong, but hopefully illuminates the connection with unit testing. :)
- kochthesecond 11y ago
  Thanks, I'm a consultant and will use this analogy in the future. I apologize to all the in-house developers, we truly try to sell in quality but it's extremely hard to convince technologically impaired managers this, especially when the budget is fixed.
wpietri 11y ago
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.

myko 11y ago

> 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?

rhizome31 11y ago
My take on this is that automated tests is a developer tool and doesn't matter to them. As much as they shouldn't care which text editor we use, they shouldn't need to know that we write tests. In fact I tend to avoid as much as possible commits that only impact tests in case they would look at the SCM history and be tempted to blame tests for a delayed delivery (no "fixed the test suite" commit messages). Also I never explicitly count automated testing in my estimates, it's counted implicitly as part of normal development.

twic 11y ago

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.

andrewflnr 11y ago

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

sgift 11y ago
Hopefully not, because it is completely wrong. They are a way to check that what you test is not broken, which is usually not even remotely the same as "nothing is broken". I have seen so many pieces of code that didn't work in the real world but had many unit tests, good test coverage and were therefore "high quality" - yeah, sure.
- andrewflnr 11y ago
  Ok, fair point. It still seems like the potential benefit is pretty clear.

michaelmrose 11y ago

Why are they managing tech then?

zeisss 11y ago

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.

rev_bird 11y ago
Thank you for this -- it will be put to almost immediate use.
rhizome31 11y ago
Sounds good, if only I understood double accounting :-)
- andrewflnr 11y ago
  The principle is simple. Basically your entire accounting log is always a balanced equation: sum(assets) = sum(liabilities) + sum(owner's equity). Every transaction gets recorded on both sides of this equation, so you can check for (certain kinds of) mistakes by adding up everything on both sides and seeing if it matches. This is a vast oversimplification, and possibly slightly wrong, but hopefully illuminates the connection with unit testing. :)
kochthesecond 11y ago
Thanks, I'm a consultant and will use this analogy in the future. I apologize to all the in-house developers, we truly try to sell in quality but it's extremely hard to convince technologically impaired managers this, especially when the budget is fixed.

wpietri 11y ago

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.