3 ms·

I'm curious - what kind of organisational issues relating to hiring new developers would be alleviated by having some tests? Are you referring to incoming devel

I'm curious - what kind of organisational issues relating to hiring new developers would be alleviated by having some tests? Are you referring to incoming developers being put off by the perception of a legacy codebase which is horrible to work with? Just curious!

kffcc 7y ago
I like to answer your question from my experience. Your point is valid. Personally I would not join a company, as a software developer for software without tests. I would consider it if they hire me to lead their code improvement efforts, but even then no tests reflect engineering and business culture in that company (which is very hard to change). A big point I like to add is that new developers make more mistakes within a system they don't know. Having a good test suite gives young and experienced developers faster feedback about their assumptions of the system. Also unit tests act like an always up to date documentation which a developer can read to understand important assumptions about the parts of a system.
Jtsummers 7y ago
Not perception, here's what happens in projects I've been on with poor test quality (low quality tests, too few tests, sometimes essentially no tests, etc.): Experienced developers (the ones who made it) are generally fast, quick to identify the source of an issue or where to make a change. They have better than even odds of not mucking it up (discovered by users later because testing in-house is too poor to catch it). New developers are either paralyzed by uncertainty (will this really do what I want, does it have an unintended effect elsewhere that I can't detect?) or make changes and have better than even odds (much better) of mucking it up and creating a mess. Hopefully it's discovered before release, but most likely it's discovered after. One of the critical things for new developers to a project is the opportunity to make changes and see what happens, with good feedback. If you permit them to make the changes, but lack the ability to provide good feedback on the effect of those changes, then they cannot learn the system from the perspective of a developer. Along with exploratory testing, it should be possible for developers to make compilable, but arbitrary, changes and see tests fail. This lets them know the impact of a change and understand how that section of code relates to the system as a whole. That holistic view is impossible on larger projects without good testing, or more experience than you want to wait for. The importance of this will vary based on the importance of the system and its size and scope. Smaller size and scope, then they can probably learn the system well enough (say, less than 100k lines of code, depending on language). Beyond that size, the system will become a rotten mess and your customers will leave you if they have any choice.

kffcc 7y ago

I like to answer your question from my experience. Your point is valid. Personally I would not join a company, as a software developer for software without tests. I would consider it if they hire me to lead their code improvement efforts, but even then no tests reflect engineering and business culture in that company (which is very hard to change). A big point I like to add is that new developers make more mistakes within a system they don't know. Having a good test suite gives young and experienced developers faster feedback about their assumptions of the system. Also unit tests act like an always up to date documentation which a developer can read to understand important assumptions about the parts of a system.

Jtsummers 7y ago

Not perception, here's what happens in projects I've been on with poor test quality (low quality tests, too few tests, sometimes essentially no tests, etc.): Experienced developers (the ones who made it) are generally fast, quick to identify the source of an issue or where to make a change. They have better than even odds of not mucking it up (discovered by users later because testing in-house is too poor to catch it). New developers are either paralyzed by uncertainty (will this really do what I want, does it have an unintended effect elsewhere that I can't detect?) or make changes and have better than even odds (much better) of mucking it up and creating a mess. Hopefully it's discovered before release, but most likely it's discovered after. One of the critical things for new developers to a project is the opportunity to make changes and see what happens, with good feedback. If you permit them to make the changes, but lack the ability to provide good feedback on the effect of those changes, then they cannot learn the system from the perspective of a developer. Along with exploratory testing, it should be possible for developers to make compilable, but arbitrary, changes and see tests fail. This lets them know the impact of a change and understand how that section of code relates to the system as a whole. That holistic view is impossible on larger projects without good testing, or more experience than you want to wait for. The importance of this will vary based on the importance of the system and its size and scope. Smaller size and scope, then they can probably learn the system well enough (say, less than 100k lines of code, depending on language). Beyond that size, the system will become a rotten mess and your customers will leave you if they have any choice.