While I like your argument from principle, I still think it's missing a critical point. There's an even higher set of principles which can be applied which integrate several higher values and motivations such that it easily resolves the many explicit and implicit conflicts which appear within your post.
An implied conflict you're trying to resolve within your article is between time spent assuming a software component is sufficiently trustworthy versus demonstrating it's actually trustworthy with an (automatable) battery of tests. This same conflict occurs even more strongly in dynamically typed languages (like JavaScript and Python). And the ambiguity you point out is resolved by attempting to identify a threshold at which you ought test a POJO getter (and possibly also its setter mate[s]).
So, if we step back and talk about a couple of higher values, some of which you mention in passing, we can start to evaluate and appreciate other possibly more effective solution pathways. Pathways which clearly and succinctly identify precisely when, where, and how much to write the tests.
The first higher value is "willpower". It is the Software Engineer's (including any developer, programmer, data scientist, etc.) HIGHEST and MOST SCARCE value. It is also THE system constraint. And as we know from ToC (the Theory of Constraints by Eliyahu Goldratt), this means we must strive to subordinate ALL activities such that they maximize the value of the time spent on THE system constraint.
Willpower?!? Yes. It is the EXTREMELY SCARCE SINGLE THREADED resource utilized to evaluate and then produce both the POJO and the accompanying automated tests. So, every second ineffectively and/or inefficiently utilized, or worse, generates irritation, frustration, and/or resistance, is a precious second not being spent on other higher value activities. That second is gone forever. And, it is quite literally the basis of the reason you observe the seemingly irrational feuds about code formatting, the "best" code editor, the proper way to use "null, etc.. And that leads us into the second higher value...
Writing code for fast readability later to facilitate EASIER REASONING AND REFACTORING is the highest goal, and not for other much lower priority concerns (like fewer characters, fewer lines, fewer classes, some probably irrelevant execution optimization, some seemingly clever trick, etc.). As you mention in your article, the code is read many MANY more times than it is ever written. It follows, then, that we focus on optimizing the primary constraint (willpower) of coders that follow us later. And that is their reading AND RAPID UNDERSTANDING of said code
Once you understand and appreciate why these two values ought to be amongst the highest values when evaluating which software engineering principles to use, the POJO testing discussion magically transforms into a whole different exploration. And then finding the "where to test threshold" becomes an easy call. It also vastly reduces the resistance to producing needed POJOs because the testing burden and maintenance is substantially reduced (if not eliminated.
So, how do we translate that into actual thinking and action? What are some examples which are derived from and illuminate the effective use of these new higher value distinctions?
Oops, I've run out of time. If you're at all curious, hit me up (jim dot oflaherty dot jr at gmail dot com) and let me know. I'd be happy to write you back about it. Even here as another comment, if you like. It's too much work to write more without knowing it is anticipated.
BTW, I'm deeply passionate about software engineering, psychology, and ToC, just in case that did't come through loud enough, LOL!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I like your argument from principle, I still think it's missing a critical point. There's an even higher set of principles which can be applied which integrate several higher values and motivations such that it easily resolves the many explicit and implicit conflicts which appear within your post.
An implied conflict you're trying to resolve within your article is between time spent assuming a software component is sufficiently trustworthy versus demonstrating it's actually trustworthy with an (automatable) battery of tests. This same conflict occurs even more strongly in dynamically typed languages (like JavaScript and Python). And the ambiguity you point out is resolved by attempting to identify a threshold at which you ought test a POJO getter (and possibly also its setter mate[s]).
So, if we step back and talk about a couple of higher values, some of which you mention in passing, we can start to evaluate and appreciate other possibly more effective solution pathways. Pathways which clearly and succinctly identify precisely when, where, and how much to write the tests.
The first higher value is "willpower". It is the Software Engineer's (including any developer, programmer, data scientist, etc.) HIGHEST and MOST SCARCE value. It is also THE system constraint. And as we know from ToC (the Theory of Constraints by Eliyahu Goldratt), this means we must strive to subordinate ALL activities such that they maximize the value of the time spent on THE system constraint.
Willpower?!? Yes. It is the EXTREMELY SCARCE SINGLE THREADED resource utilized to evaluate and then produce both the POJO and the accompanying automated tests. So, every second ineffectively and/or inefficiently utilized, or worse, generates irritation, frustration, and/or resistance, is a precious second not being spent on other higher value activities. That second is gone forever. And, it is quite literally the basis of the reason you observe the seemingly irrational feuds about code formatting, the "best" code editor, the proper way to use "null, etc.. And that leads us into the second higher value...
Writing code for fast readability later to facilitate EASIER REASONING AND REFACTORING is the highest goal, and not for other much lower priority concerns (like fewer characters, fewer lines, fewer classes, some probably irrelevant execution optimization, some seemingly clever trick, etc.). As you mention in your article, the code is read many MANY more times than it is ever written. It follows, then, that we focus on optimizing the primary constraint (willpower) of coders that follow us later. And that is their reading AND RAPID UNDERSTANDING of said code
Once you understand and appreciate why these two values ought to be amongst the highest values when evaluating which software engineering principles to use, the POJO testing discussion magically transforms into a whole different exploration. And then finding the "where to test threshold" becomes an easy call. It also vastly reduces the resistance to producing needed POJOs because the testing burden and maintenance is substantially reduced (if not eliminated.
So, how do we translate that into actual thinking and action? What are some examples which are derived from and illuminate the effective use of these new higher value distinctions?
Oops, I've run out of time. If you're at all curious, hit me up (jim dot oflaherty dot jr at gmail dot com) and let me know. I'd be happy to write you back about it. Even here as another comment, if you like. It's too much work to write more without knowing it is anticipated.
BTW, I'm deeply passionate about software engineering, psychology, and ToC, just in case that did't come through loud enough, LOL!