In the second to last paragraph, the above has "Activities that
might be postponed include ... tackling compiler ... warnings."
And changing the compiler is not part of software development?
Q&D such as changing compilers without testing everything.
It sure can.
Do you port the code to the new compiler, or do you just hope?
On 4/6/2012 6:53 PM, Arved Sandstrom wrote:
On 12-04-05 11:41 PM, Eric Sosman wrote:
On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
On 4/5/2012 2:42 PM, Lew wrote:
[...] "They developed it
for Java 1.4 eight years ago" is not even a pitiful excuse. Java
5 is
already obsolete, and Java 6 is not far behind. Move forward or die.
It is not technical debt.
Technical debt is when the code was not good when written.
Here something externally changed.
So the debt is incurred by Java itself, not by the code written
in Java? Okay, then: It's not a technical debt, it's a technical tax.
And getting funding to lift ones code to a newer version of
platform without providing any new value is typical very
difficult.
True, and rightly so. Any rewrite, even one that's 95%
mechanical,
is guaranteed to introduce new errors that will need to be found and
fixed and patched and apologized for. To disturb the (mature, tested,
trusted) code, you need a better reason than "Fashions have changed."
Well, it's not just "fashions have changed", nor in answer to Arne's
point is it the case that there is no new value. The new value that I'd
expect to get from a newer version of Java, and the message I'd want to
push to business, is that the maintainability and adaptability of the
codebase has now improved.
That is a classic argument.
But does it hold water?
Let us say that you have 100 Java developers maintaining
a code base in Java 1.4 - how many people would you reduce that to
if you got it lifted to 1.6? 90? 80? 70? 60?
That depends on the nature of the work. But let me give you an example:
let's say that the 1.4 codebase is loaded with low-level concurrency
constructs. Modules that use this kind of code may be "hands-off, it
sort of works except when it doesn't. I've worked with plenty of Java
apps that have this kind of older concurrency code.
I think there is/was a compelling case to move to 1.5 or 1.6 or 1.7
simply to avail oneself of the java.util.concurrent stuff. I have
reworked several subsystems for clients in this manner and I know for a
fact that it has freed up significant inhouse developer time for more
useful work. Not only that, but having 1.5 or 1.6 or 1.7 be the new
organizational standard for a client means that new systems will
inexorably use java.util.concurrent APIs for concurrency work.
Developers lead and follow by example: keep 1.4 low-level thread code
around in apps and it tends to be copied.
That's just one example.
And certainly one of the better examples.
juc can certainly reduce maintenance cost.
But if we look at other Java 5 new features: generics, enums,
new for loop, auto boxing/unboxing, static import, varargs -
then I do not see the same benefits.
Arne
Arne said:Are you claiming that it is poor software architecture/development
to write code that does not have a single flaw at time of being written
but 5 or 10 years later give warnings or errors with a new Java
version?
I don't know if he is, but I am.
The point was made upthread that when you introduce a new Java version, you must regression-test it like any other system component. If that regression introduces new warnings or errors, and you leave them alone, that's poor development. Period.
Arne said:I think you should read it once more.
I don't think you really consider programmers not able to predict the
future to be poor programmers.
Nobody is denying that.
We are discussing whether the code comes with technical debt or not.
It does not.
Unless one require developers to be able to predict the future.
Which I do not.
It does, once the compiler has been changed and the concomitant warnings ignored.
The question isn't whether it was technical debt in 1993 but whether it's technical debt today. Your argument only presents a case that it wasn't technical debt in 1993.
At no point do I require anyone to predict the future, only observe the present. You're the one attempting to reframe the discussion to one of prognostication. It is not a valid restatement of the issue to do so.
At the point when the OP's project converted to Java 5 or later, and ignored the generics warnings, those warnings became technical debt. No crystal ball needed; this is historic.
I have to say I must agree with Lew's use of the term here. To my ear,
it doesn't make sense to exclude issues arising from the datedness of
the codebase from the concept "technical debt."
Issues such as workarounds for old bugs in compilers or libraries, the
use of outmoded software idioms, failure to adhere to today's best
practices, roll-your-own implementations of functionality that has
since been covered by mature, widely adopted libraries -- once you
bring the code back out into the open and blow the dust off it, these
all affect the software development in the same way as "ordinary"
technical debt.
I don't agree with Lew's view that it's necessarily bad software
development to let sleeping dogs lie. It comes down to a cost /
benefit calculation -- the cost of up-to-dateing a non-trivial
software project can be significant and the benefits might not be. It
depends on the size and age of the project and on why you're dragging
it back into the light.
(For particularly large projects, it might not going to be _possible_
to keep the entire project up-to-date with current best-practices and
idioms. It'll be like painting a major bridge -- by the time you've
painted your way to the far side, it'll be time to start on the near
side again.)
Are you claiming that it is poor software architecture/development
to write code that does not have a single flaw at time of being written
but 5 or 10 years later give warnings or errors with a new Java
version?
Are you claiming that it is poor software architecture/development
to write code that does not have a single flaw at time of being written
but 5 or 10 years later give warnings or errors with a new Java
version?
[snip]
Are you claiming that it is poor software architecture/development
to write code that does not have a single flaw at time of being written
but 5 or 10 years later give warnings or errors with a new Java
version?
No, I am stating that if one switches compilers, all bets are
off, and you had better test to make sure that the program still
works.
I have to say I must agree with Lew's use of the term here. To my ear,
it doesn't make sense to exclude issues arising from the datedness of
the codebase from the concept "technical debt."
[snip]
Are you claiming that it is poor software architecture/development
to write code that does not have a single flaw at time of being written
but 5 or 10 years later give warnings or errors with a new Java
version?
I have seen code that worked with one version of a compiler fail
on the next version, because the parsing had been tightened up. Code
that had worked for years would suddenly compile with errors. This
was between different versions of Microsoft Visual FoxPro.
On 12-04-12 09:33 PM, Arne Vajhøj wrote:
On 4/6/2012 6:53 PM, Arved Sandstrom wrote:
On 12-04-05 11:41 PM, Eric Sosman wrote:
On 4/5/2012 7:46 PM, Arne Vajhøj wrote:
On 4/5/2012 2:42 PM, Lew wrote:
[...] "They developed it
for Java 1.4 eight years ago" is not even a pitiful excuse. Java
5 is
already obsolete, and Java 6 is not far behind. Move forward or die.
It is not technical debt.
Technical debt is when the code was not good when written.
Here something externally changed.
So the debt is incurred by Java itself, not by the code written
in Java? Okay, then: It's not a technical debt, it's a technical tax.
And getting funding to lift ones code to a newer version of
platform without providing any new value is typical very
difficult.
True, and rightly so. Any rewrite, even one that's 95%
mechanical,
is guaranteed to introduce new errors that will need to be found and
fixed and patched and apologized for. To disturb the (mature, tested,
trusted) code, you need a better reason than "Fashions have changed."
Well, it's not just "fashions have changed", nor in answer to Arne's
point is it the case that there is no new value. The new value that I'd
expect to get from a newer version of Java, and the message I'd want to
push to business, is that the maintainability and adaptability of the
codebase has now improved.
That is a classic argument.
But does it hold water?
Let us say that you have 100 Java developers maintaining
a code base in Java 1.4 - how many people would you reduce that to
if you got it lifted to 1.6? 90? 80? 70? 60?
That depends on the nature of the work. But let me give you an example:
let's say that the 1.4 codebase is loaded with low-level concurrency
constructs. Modules that use this kind of code may be "hands-off, it
sort of works except when it doesn't. I've worked with plenty of Java
apps that have this kind of older concurrency code.
I think there is/was a compelling case to move to 1.5 or 1.6 or 1.7
simply to avail oneself of the java.util.concurrent stuff. I have
reworked several subsystems for clients in this manner and I know for a
fact that it has freed up significant inhouse developer time for more
useful work. Not only that, but having 1.5 or 1.6 or 1.7 be the new
organizational standard for a client means that new systems will
inexorably use java.util.concurrent APIs for concurrency work.
Developers lead and follow by example: keep 1.4 low-level thread code
around in apps and it tends to be copied.
That's just one example.
And certainly one of the better examples.
juc can certainly reduce maintenance cost.
But if we look at other Java 5 new features: generics, enums,
new for loop, auto boxing/unboxing, static import, varargs -
then I do not see the same benefits.
Nor do I, mostly. I picked java.util.concurrent because it stands out.
Similarly collections enhancements in 1.6. There are other API additions
and enhancements that may be or greater or lesser significance depending
on your interests.
Overall I find that library/API additions and improvements are a much
bigger deal for me than language enhancements. Just from the list above
that you provided, I don't use static import, very rarely use varargs,
use "foreach" because it exists but could easily live without it.
Autoboxing/unboxing: some value in improving readability, provided that
you are aware of the pitfalls. Enums: nice enough but I wouldn't say
they were earthshaking.
Generics: moderate utility. IMO. Same readability problems as what it
replaced, more or less, moved checking to an earlier stage which is
good. But I've written enough code in dynamically-typed languages to
know that I don't typically get hammered by all sorts of runtime errors
anyway, so sometimes the Java approach feels like it solved a problem I
didn't really have. But one's mileage will definitely vary. Don't get me
wrong, I don't think generics are bad, but they are probably by
themselves not a compelling reason to bump up from 1.4 to 1.5 or later.
[snip]
Are you claiming that it is poor software architecture/development
to write code that does not have a single flaw at time of being written
but 5 or 10 years later give warnings or errors with a new Java
version?
No, I am stating that if one switches compilers, all bets are
off, and you had better test to make sure that the program still
works.
That is rather irrelevant.
The discussion is whether it is technical debt that code
does not compile with future versions of compiler/library.
[snip]
Are you claiming that it is poor software architecture/development
to write code that does not have a single flaw at time of being written
but 5 or 10 years later give warnings or errors with a new Java
version?
I have seen code that worked with one version of a compiler fail
on the next version, because the parsing had been tightened up. Code
that had worked for years would suddenly compile with errors. This
was between different versions of Microsoft Visual FoxPro.
That can happen.
But it is not what is happening here.
OP's code was perfectly valid pre-1.5 Java that gives
warnings due to raw types in 1.5+.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.