Test coverage alone is meaningless, you need to think about input-coversge as well, and that’s where you can spend almost an infinite amount of time. At some point you also have to ship stuff.
Test coverage alone is meaningless, you need to think about input-coversge as well, and that’s where you can spend almost an infinite amount of time. At some point you also have to ship stuff.
Wouldn’t static type checking solve most of these issues?
Isn’t that exactly the role of an architect? The point is exactly that not everyone is a cog, not everyone is exchangable and equivalent to everybody else.
I feel like the expectation that a developer can do it all is quite harmful. There are not many other disciplines where this is expected, and for good reason.
Maybe it’s better to just admit you don’t know how to properly architect a solution rather than pretend you do and create an unmaintainable mess. Maybe you shouldn’t pretend you know how to do front-end development instead of creating some monstrosity that no user actually uses due to bad UX. Maybe you shouldn’t pretend you understand security instead of introducing half a dozen sql injection vectors.
Maybe it’s time to admit that the days of the solo developer are over. It may have worked when there was no internet, no security concerns, no concurrency requirements, etc. But we expect, and deserve, better nowadays.
I think the idea is that big-name men will show up to support women and work for equality, not to creep on them.
Probably works well if you are an established company, but why would e.g. a startup pick licensing headaches over the competition? I imagine bigger companies would also rather just move to e.g. CDK or ARM if they don’t need multiple providers (at least our company started discussing this today).
What kind of “custom licensing” do you anyway think a 5-person startup would get?
The biggest problem I see is that you can suddenly become non-compliant just because Hashicorp decides to release a new service (i.e.they start competing with you, rather than the other way). It can be a huge risk for companies.
By input coverage I just mean that you test with different inputs. It doesn’t matter if you have 100% code coverage, if you only tested with the number “1”, and the code crashes if you give it a negative number.
If you can prove that your code can’t crash (e.g. using types), it’s a lot more valuable then spending time thinking about potentially problematic inputs and writing individual tests for them (there ate tools thst help with this, but they are not perfect).