About software development, I have a lot of unpopular views about testing.
- You should try to write as few tests as needed (and focus on getting as much value as possible out of each test case).
- Only write unit tests for logic that is either: 1. Too complex to reason about or 2. Very old and hasn't changed in a very long time (like 1 year or more) and you want to lock it down.
- For TDD; integration tests are the best.
Also, I have unpopular views about statically typed languages; I'm not a big fan of them. I spent many years working with statically typed languages in a professional setting (in fact, my first language was statically typed) so I have a deep understanding of the pros and cons of each one so I feel very strongly that dynamically typed is better in terms of productivity (both for initial development and also refactoring).
Basically I'm against the corporate approach of software development. I'm particularly against all software development approaches which aim to treat engineers as disposable and untrustworthy entities.
It's obvious why executives don't like this type of thinking but it's surprising to me why engineers themselves also often disagree with it.
I think a big take away is that what works for one person may not work for the other.
I have worked with both types and untyped languages and I really don't like untyped languages. But I have seen plenty of smart people who love untyped languages and do great work so I have concluded that people just are different and have different needs. And ideally the workplace should accommodate these differences.
Same for open space. Some love it, some hate it. So ideally people should have a choice.
> I spent many years working with statically typed languages in a professional setting (in fact, my first language was statically typed) so I have a deep understanding of the pros and cons of each one
There are a lot of statically typed languages, many with completely different paradigms, so I admit to considerable scepticism of your claim.
For a lot of projects, a small number of carefully chosen integration test cases can give you a large amount of coverage. Unit tests are often a problem for refactoring because they discourage you from making necessary changes (since updating unit tests is hard work, it incentivizes developers to limit the scope of the refactoring).
The reason why typed languages are slower to refactor is simply because they just take more time to think about. For example, it takes time to discuss and agree on types with your team members; what they should be called and whether or not we should combine some interfaces into a single interface...
This is not as unpopular as what reading about productivity and process from blogs or books by people who sell canned methodologies will make you think. Thinking retrospectively I think more than half of the projects I've worked in practiced agile in a way more akin to your views than to what you are complaining about "everyone does".
It's also not too different to what old books like Fowler's refactoring or the Working With Legacy Code book say, or what modern books like Philosophy of Software Design say.
- You should try to write as few tests as needed (and focus on getting as much value as possible out of each test case).
- Only write unit tests for logic that is either: 1. Too complex to reason about or 2. Very old and hasn't changed in a very long time (like 1 year or more) and you want to lock it down.
- For TDD; integration tests are the best.
Also, I have unpopular views about statically typed languages; I'm not a big fan of them. I spent many years working with statically typed languages in a professional setting (in fact, my first language was statically typed) so I have a deep understanding of the pros and cons of each one so I feel very strongly that dynamically typed is better in terms of productivity (both for initial development and also refactoring).
Basically I'm against the corporate approach of software development. I'm particularly against all software development approaches which aim to treat engineers as disposable and untrustworthy entities.
It's obvious why executives don't like this type of thinking but it's surprising to me why engineers themselves also often disagree with it.